Clash for Windows 流量統計與核心日誌怎麼用？排查卡頓、延遲與「未走代理」必備
安裝與訂閱類文章只能帶您到「能連線」；日常真正消耗時間的，多半是網頁轉圈、影片卡頓／掉幀、特定程式連不上，以及心裡那句「到底有沒有走代理」。本篇聚焦 Connections（連線）與 Logs／核心日誌：教您如何在對的時間軸上讀懂規則命中、策略鏈與錯誤訊號，並把它們接到可行的下一步（換節點、調規則、開 TUN、對齊 DNS）。
為什麼「會連線」不等於「問題已排除」
Clash for Windows（CFW）把複雜的 YAML 規則包進圖形介面，但網路行為仍然是：應用程式發起連線 → 核心依規則決定 DIRECT／PROXY／REJECT → 再經過具體節點或本地網路出口。任何一步不一致，您都會在主觀感受上看到「卡」、「慢」、「忽快忽慢」，但 Proxies 頁面上的延遲測試卻可能仍然很漂亮——因為測速連線與您實際瀏覽的連線並不是同一條 TCP／UDP 會話。
Connections提供「現在這一刻有哪些會話正在被核心處理」的視窗；Logs則提供「核心怎麼解讀規則與握手結果」的文字線索。兩者合在一起，才能把問題從「感覺不快」推進到「是哪個域名／哪個進程／哪條規則／哪個出口」的可驗證敘述。對已經完成Windows 安裝與訂閱匯入的讀者來說，這通常是下一個最值得投資的技能點。
先把預設心智放好
您不是為了「看懂每一行日誌」而讀；您是為了在數十秒內回答三個問題：這條連線有沒有進核心？規則把它送去哪個策略組？錯誤發生在握手前還是握手後？接下來的所有技巧都圍繞這三件事。
Connections（連線）：流量統計與「連線級真相」
在 CFW 左側進入 Connections，您會看到即時更新的連線清單。每一列大致對應「某個來源進程對某個目的地開了一條（或多條）會話」。這裡最重要的價值不是好看的數字，而是把您肉眼看不到的連線行為具象化：同一個網頁可能同時拉出 DNS、HTTPS、CDN、分析腳本與第三方嵌入，任何一條阻塞都會讓整體體驗「像全部壞掉」。
您該優先盯的欄位
- 進程／來源資訊：對應是哪個程式（瀏覽器分頁常常共用同一個進程名稱；某些程式會有多個子進程）。若您明明開著軟體卻長期看不到對應連線，首先要懷疑流量根本沒進核心（見後文「未走代理」）。
- 目標地址與連接埠：分辨是域名還是 IP、連線類型為 TCP 或 UDP。語音／即時通訊類連線對 UDP 路徑更敏感；若您看到異常高的 UDP Drop，可能要往回檢查節點能力或規則。
- 規則鏈／策略／Policy（介面用詞依版本略有出入）：這一行告訴您「這條會話最終被送去哪個 proxy-group／是否 DIRECT／是否 REJECT」。當網頁卡頓時，第一件事應該是確認卡住的那個域名到底走了哪個策略組，而不是先換一批節點試手氣。
- 下載／上傳量與時間：協助您分辨「長時間低速」與「瞬間大量傳輸後卡住」。更新量大且長時間無進展時，多半是握手或線路吞吐問題；長時間微小流量抖動可能是連線反覆重建。
實務上建議您先養成一個習慣：問題發生時先點開 Connections，再回到瀏覽器做一次硬性重新載入或重現操作，讓清單「跟自己對齊」。這比盲開 Logs 更能避免被無關連線淹沒。
別把「連線很多」誤認為異常
現代網頁本質上是並行請求瀑布流；Connections 瞬間列出數十條並不代表中毒或被監控。排查時請鎖定與症狀同步出現的那一兩個目的地，並用它們當作 Logs 搜尋關鍵字。
Logs／核心日誌：規則命中與錯誤訊息怎麼讀
Logs頁記錄核心在運行過程中的事件流：規則評估、dial（撥號連線）、握手結果與錯誤返回。介面上通常可按級別過濾（info／warning／error 等），並提供搜尋框。對新手而言最容易忽略的關鍵是：日誌條目與 Connections 列要在時間軸上對得起來；離開對齊談「規則命中」，很容易變成玄學。
規則命中（rule hit）您最常想知道的答案
當您看到類似「某域名／某規則類型 → MATCH／經過 proxy-group／選擇某個 outbound」的描述時，代表的是核心當下對這個連線請求的決策結果。請記住：MATCH 只說明規則引擎做出了選擇，不保證後段線路一定順暢。若 MATCH 之後緊跟著連線逾時、dial error、TLS handshake timeout，問題多半已下沉到節點或對端網站回應，而不是規則是否「看得到」該域名。
另一種典型情境是：規則看似命中 DIRECT，但網站其實必須走代理才能穩定（例如境外 CDN、特定 API、或被區域網路策略干擾的路徑）。此時 Logs 會忠實地記錄 DIRECT 決策；您需要回頭調整規則順序、補域名規則或改用 RULE-SET／GEOIP 的更細拆分，而不是在心態上否定 Logs「不准」。
常見錯誤線索（不必背，會對照即可）
- 連線被拒絕（connection refused）：優先懷疑目標連接埠根本沒開、或被本地／對端防火牆中止；也可能是代理鏈路上的某一環回了 RST。
- i／o timeout、dial tcp timeout：多半是線路端到端握手過慢或掉封包嚴重；可換節點、換協定類型（視機場支援）、或避開離峰時段再試。
- TLS／certificate 類錯誤：可能是 MITM／嗅探設定與站點不相容，也可能是節點側異常；這類問題常在特定網站重現而非全域。
- DNS 解析失敗或無結果：請務必與 DNS／fake-ip 設定交叉閱讀；本站DNS 與 fake-ip 排查可作為下一跳。
用小流量場景練習
選一個小型純 HTTPS 網站（例如搜尋引擎首頁），在 Connections 找到對應域名，再在 Logs 用域名過濾；重複幾次後您會對「規則命中長什麼樣」建立視覺記憶，之後遇到複雜站點才不會慌。
實務排查流程：卡頓、延遲高、疑似未走代理
下面是一套刻意短路徑的流程，適合寫在便簽旁邊長期使用。它不是唯一真理，但能最大限度避免「一上來就換節點換到天亮」。
五步排查（濃縮版）
- 確認 Clash 正在運行，且代理模式落在預期的
Rule（除非您刻意要用 Global／Direct 做對照）。 - 開啟 Connections，重現問題，鎖定症狀域名／進程與策略鏈。
- 開啟 Logs，用同一域名過濾，看規則命中與錯誤是否在數秒內連續出現。
- 若策略鏈指向代理組：先在 Proxies 內對同一類出站換節點驗證；若換節點立刻改善，問題在線路而非規則。
- 若 Connections 長期見不到該程式：轉向系統代理邊界——終端環境變數、UWP、或 TUN／混合埠設計；可接力閱讀終端 HTTP／Git 代理（Windows／macOS／Linux）與UWP／Store 回環與 TUN。
其中第四步刻意強調「換節點」的時機：只有在 Logs 已經確認會話進入代理鏈之後，換節點才有判別意義；否則您只是把 DIRECT 問題或 DNS 問題包裝成「節點品質不佳」的假故事。
對於「延遲高」的主觀抱怨，請儘量把它翻譯成可量測語言：是TTFB（首封包時間）長，還是吞吐（傳輸速度）長期偏低？前者多半是路由／握手／對端伺服器排隊；後者可能與線路頻寬、QoS，或影片 CDN 調度有關。Connections 能看到會話是否在長時間維持少量資料抖動，這比單純 ping 更接近真實使用者體驗。
規則順序、GEOIP 與 DNS／fake-ip 的交界
許多人會把「規則命中」理解成一張靜態表，但實際運行時，規則引擎看到的是解析後的資訊集合：有時是域名，有時是 IP，有時是進程規則先行命中。若您的設定使用 fake-ip，表面上瀏覽器仍以域名連線，核心內部可能已經先行介入 DNS 流程；這會讓Logs 呈現與 Wireshark 直覺不完全一致，並不代表某一邊錯誤，而是代表您看見的是核心的決策視角。
當懷疑 DNS／fake-ip 造成「規則明明對但連線行為怪」時，請避免直接在 GUI 裡盲目勾選一堆選項；更正統的方法是：保留 Logs 截圖級別的三個資訊（時間、域名／IP、錯誤類型），再把 DNS 設定退回最小變更集合逐一驗證。這種作法較為枯燥，但能避免您把問題從線路問題錯調成全域設定災難。
短期對照請克制使用 Global
切到 Global可以把「規則問題」快速二分法判掉，但它也會把所有流量強制送入代理，掩蓋細粒度規則設計錯誤。請只在排查視窗短暫使用，確認無誤後回到 Rule，否則長期 Global 只會讓下一次 Logs 更難讀。
容易誤判的三種情境
第一種：把 Proxies 頁面的延遲測試當成網站體驗承諾。測速目標主機與影片 CDN、API 閘道往往不是同一個地理位置或同一條承載網路；Connections＋Logs 才能對齊真實會話。
第二種：看到 REJECT 就以為一定是廣告規則誤殺。有些追蹤域名被攔截後，網頁仍會嘗試長時間等待逾時；這時 Logs 會告訴您阻塞點在 REJECT，解法可以是細化規則或接受少量追蹤連線（視您的隱私策略而定）。
第三種：忽略「進程級分流」與「域名規則」的優先順序語意。不同核心／設定對 PROCESS／RULE 的優先順序不完全相同；當您引入複雜 mixin 後，最好在 Logs 直接確認命中鏈，而不是憑記憶推斷 YAML 順序。
常見問題（精簡）
規則命中正確，為什麼還是慢？
規則只負責「送去哪個出口」；出口之後仍有握手、對端伺服器回應與跨境路由變動。請先在 Logs 觀察是否存在握手逾時或連線重試；若錯誤集中在某一類域名或某一協定，才回到規則／DNS／節點能力拆分。
Logs 一片空白或總覺得對不上？
確認您看的不是「已被過濾到只剩 error」；並確認問題連線確實經過核心。對於不走系統代理的程式，請優先處理 TUN 或環境變數代理鏈路。
連線／日誌會不會記錄敏感資料？
Connections 與 Logs 的本質是本地診斷視窗；是否留存、是否完整取決於您的版本與設定。一般而言應避免把完整 Logs 公開張貼到論壇——其中可能包含您可辨識的域名存取序列；自用排查時可以先用域名級別截取。
總結：把「感覺」變成「可操作的結論」
Clash for Windows 的流量統計與核心日誌並不是進階玩家的玩具，而是把網路問題從玄學拉回工程語言的起點：Connections 回答「這條會話是否存在、走向哪個策略」；Logs 回答「規則為何這樣命中、握手在哪個階段失敗」。當您能在一分鐘內完成這兩個視窗的對齊，您已經超越大多數只會「換節點／重裝軟體」的急救流程。
若您尚未完成首次可用設定，請仍以前一篇安裝與訂閱匯入教學為基線；若連線成立但總覺「DNS 怪怪的」，再把DNS／fake-ip 專文接到這篇文章後面當延伸閱讀。掌握這條路徑後，無論您面對的是串流卡頓、開發工具鏈逾時，還是某個冷門程式不走代理，您都會有可複製的排查腳手架。
延伸閱讀
Windows 環境裡與本文強相關的主題還包括：Microsoft Store／UWP 與回環（解釋為何「瀏覽器能用、商店不能用」）、以及退出後系統代理重置（避免日誌排查時被殘留系統代理誤導）。這些文章與本篇同一套「先看連線真相」的方法是相容的。