Clash Verge Rev 流量與連線紀錄怎麼用：即時監控看板與排查入口分步說明

1. 本篇涵蓋範圍與不包含什麼

Clash Verge Rev把 mihomo 包成桌面用戶端：左側導覽通常會看到首頁／儀表、代理或設定檔、連線、日誌、設定等區塊（實際排版隨版本更新可能微調，建議以你安裝的版本為準）。本篇聚焦三件事：流量統計從哪裡讀、連線表怎麼當成「現場錄影」、日誌頁如何調整粒度並協助判讀。

下列主題刻意拆出去，以免搜尋意圖混在一起：第一次安裝與系統代理／TUN 授權、訂閱 URL 與 TLS handshake、企業網路攔截、以及 external-controller 與 Secret 曝露面。當你發現「連線表完全沒有新連線、日誌卻狂刷錯誤」時，先把問題分類：究竟是核心沒起來、還是起了但規則／DNS 讓你看起來像斷線，再跳去對應長文，會省非常多來回時間。

2. 即時流量與統計：看板要對齊什麼預期

大多數版本會在首頁或儀表區顯示上傳／下載即時速率，有些也會呈現當日累計或短時間圖表。請先把預期說清楚：這張看板顯示的是「經過核心統計的流量」，並不等於「全世界所有網路封包」——若某程式完全不走 Clash（例如部分讀取獨立 Proxy 設定格式的遊戲、或繞過系統設定的工具），畫面上可能安靜，但你的頻寬在別處仍可能被吃滿。

實務上建議用對照實驗校準感覺：選一個明確會產生下載的動作（開影片、跑套件更新、下載小檔），同時盯著速率曲線。若曲線幾乎不動，優先懷疑系統代理未套用、TUN 未啟用、或該行程根本沒把流量送進 Clash；若曲線有動但網頁仍破圖，則比較像規則把部分網域直連、DNS 與 fake-ip 路徑不一致、或單一站點被節點品質與封鎖拖累——下一步請改開連線表，而不是先改訂閱網址。

有些使用者會把系統匣選單或狀態列圖示當成「第二塊迷你儀表」：用來確認核心是否在跑、模式是否與預期一致。若你習慣長時間開著客戶端，偶爾發現統計「凍結」，可先嘗試重啟核心或重新載入設定檔（具體按鈕名稱依版本），再觀察是否為單次 UI 刷新問題；若重啟後仍無任何連線累積，才回頭檢查埠號占用或混用多個客戶端競爭同一組本機埠。

3. 連線清單：每一列在說什麼

連線／Connections頁是釐清「到底誰在連哪裡、走了哪條規則」的首選畫面。典型欄位會包含目標網域或 IP、埠、策略鏈、命中的規則或規則提供者、實際出站（DIRECT 或某個代理群組／節點）。你不必先成為 YAML 專家，只要會看兩件事：這條連線有沒有進代理鏈、以及出站名稱是不是你以为的那個策略組。

當你覺得「明明開著 Clash，某站還是顯示區域不對」，請在連線表搜尋該站相關網域後綴，觀察它是整條命中 DIRECT 還是已經掛上代理卻在節點側被降速或阻擋。前者是規則／DNS 規劃問題；後者是節點或對端偵測問題。若同一時間有大量短連線，列表刷新會很快，可用暫停或過濾功能（若版本提供）鎖定單一目標，避免被捲動洗版。

進階使用者可把連線表當成教學草圖：看到自己常用的程式名稱或連線類型後，回去對照設定檔裡的 PROCESS-NAME、DOMAIN-SUFFIX 與策略組順序。對一般使用者而言，只要記住：連線列是「結果」、規則頁與設定檔是「原因」；監控畫面負責把兩者黏起來，而不是取代其中一邊。

4. 日誌與紀錄層級：從噪音裡撈訊號

日誌頁讀的是 mihomo 核心輸出的文字紀錄，內容可能包含規則載入、DNS 查詢、錯誤重試、外部控制器請求等。多數用戶端會讓你選擇紀錄層級：平常用較低層級降低干擾；需要查為什麼某條規則沒命中、或 TLS／解析反覆失敗時，再暫時拉高到 debug 等更囉唆的模式。

實務上可以養成一個習慣：先複製「第一條真正看起來像錯誤」的行，再搜尋是否重複出現同一個網域或同一個錯誤碼。訂閱層的 TLS、憑證與 DNS 問題，往往在日誌裡會有可辨識的關鍵字；但請注意不要在公開場合貼上含個人訂閱 token 或完整節點資訊的片段。若你已依站內 訂閱排查文做完第一輪仍卡關，可把「連線表＋同期日誌」一起留給可信任的社群或管理員，敘述會完整很多。

另有應用程式自身的事件紀錄（與核心日誌分開）：例如更新檢查、覆寫套用失敗、或圖形殼與核心之間的溝通異常。當你懷疑「不是規則問題，而是客戶端沒把設定送進核心」時，這類訊息會比 mihomo 裡的 DNS 行更有用。若兩邊都空白，優先確認是否誤開了多份程式、或防護軟體阻擋本機 IPC。

5. 依介面做的簡易排查心智模型

建議把排查想成三層漏斗。第一層看核心是否在跑、模式是否已套用（狀態列或首頁最明顯）。第二層看連線表有沒有對應程式／網域：若完全沒有，偏向「流量沒進來」；若有卻全變 DIRECT，偏向「規則或 GEO／策略組選擇與你想的不一樣」。第三層才用日誌對細節：延遲暴增、握手失敗、規則提供者下載錯誤，都屬於這一層的訊號。

這個順序刻意把「直覺改訂閱網址」往後推：許多現象其實出在系統層（瀏覽器的安全 DNS、WinHTTP 與 WinINET 分裂、第二套 VPN 改寫路由）。當連線表顯示一切正常、只有特定應用程式仍脫鉤，可再對照站內終端與開發工具走代理的專文；若只有 UWP 或 Microsoft Store 行為怪異，則需要 Loopback 與 TUN 專題，而不是調整流量統計本身。

REM Optional: WinHTTP proxy may diverge from system UI (some stacks)
netsh winhttp show proxy

上述指令僅在部分 Windows 場景下有參考價值：當你看到「Clash 統計有動、但某後台服務永遠直連」，可快速排除是不是 WinHTTP 仍指向舊的閘道。macOS 使用者則可優先確認系統的「網路」代理頁是否與 Verge Rev 顯示的埠一致；版本更新後若出現短暫不同步，重載設定或重新套用系統代理往往比較快。

6. Windows 與 macOS 操作習慣差異

Windows使用者常把「工作管理員的網路行為」與「Clash 連線表」並看：前者告訴你是哪個行程在吃頻寬，後者告訴你同一個行程在 Clash 世界的規則結果。若兩邊對不起來，通常表示該行程沒走本機 Proxy 或沒被 TUN 收下。macOS則多了「系統延伸功能、網路權限與輔助相關提示」等脈絡；首次啟用 TUN 時日誌裡若出現權限相關詞彙，應回到首配文章完成授權，而不是在日誌頁反覆清除快取。

無論平台，請記得不要把「即時監控截圖」當成資安分享素材：連線目標與規則名稱可能暴露你造訪的服務類型。教學或求助時務必打碼，並避免外洩訂閱位址。若你同時啟用外部 Web 面板或把 API 綁在區網，監控資料可能出現在另一個端口上；這屬於曝露面治理，請改讀 external-controller 與 Secret 專文，本篇只提醒邊界存在。

7. 常見問題

流量統計全是零，第一件事該做什麼？

先確認核心是否顯示運行中，再隨手開一個會產生流量的網頁。若仍為零，檢查是否選錯設定檔、或系統代理／TUN 未套用。仍無連線列條目時，才考慮埠衝突或其他客戶端占用。

連線表刷新太快，怎麼跟上？

優先用搜尋或過濾鎖定網域關鍵字；必要時在重現問題的當下截圖，比盯著捲動有效。搭配較低頻寬的測試動作，也有助於觀察單一路徑。

日誌裡看到很多 DNS 行，算不算異常？

在高層級下 DNS 紀錄可能很吵。請先關心是否夾雜錯誤或反覆重試；若只是資訊級別，且連線與體驗正常，不一定需要處理。需要調整 fake-ip 或 redir-host 時，請延伸閱讀站內 DNS 模式對照。

和「Sniffer／SNI」題材差在哪？

Sniffer 相關題材處理的是 HTTPS 分流識別；本篇的連線與日誌是通用手法。若連線顯示的目標與預期策略不符，可把 Sniffer 與 SNI 日誌文當下一層讀物。

8. 延伸閱讀與安全邊界

把監控畫面用熟之後，維運成本會明顯下降：你會比較少「憑感覺改節點」，而是先看連線與日誌再決定要不要動規則。若你正在規劃多裝置或 LAN 內共享代理，可再接 allow-lan 與防火牆；若規則集經常更新失敗，則改 規則集與 GEOIP 日誌專文 對照路徑與權限。

需要合法、穩定取得各平台客戶端與延伸閱讀入口，請至：→ 立即免費下載 Clash，開啟流暢上網新體驗。