Clash 執行日誌怎麼看:常見錯誤含義與問題定位方法

為什麼先看日誌,而不是先換節點

遇到網頁打不開、連線卡頓這類問題時,很多人第一反應是切換訂閱或換一個節點,試幾次不行就懷疑用戶端本身有問題。這條路徑效率很低,因為代理鏈路涉及本機設定、節點可用性、跨境線路品質、目標網站回應等多個環節,盲目更換節點只能排除其中一小部分可能性。更快的辦法是打開日誌頁,看用戶端在處理這次連線請求時到底記錄了什麼——錯誤資訊通常會直接指出問題出在哪一層。

Clash 系用戶端的日誌本質上是核心(Clash Meta / mihomo)執行過程的即時輸出,用戶端介面只是把這些文字渲染出來並做了上色和篩選。理解日誌結構和常見欄位的含義,是排查連線問題最基礎也最有效的技能。

日誌級別與欄位結構

打開用戶端的日誌頁(通常在側邊欄標示為 Logs 或「日誌」),會看到類似下面這樣的一行記錄:

[Info] [TCP] 192.168.1.5:51234 --> example.com:443 match Rule(DOMAIN-SUFFIX,example.com) using Proxy-HK

這行記錄包含四個關鍵部分:

• 日誌級別:方括號裡的 Info、Warning、Error 等,表示記錄的嚴重程度。
• 協定與連線方向:TCP 或 UDP,以及本機埠指向目標網域/埠。
• 符合的規則:說明這條連線命中了設定檔裡哪一條分流規則。
• 使用的代理節點:實際轉發這條連線的節點或策略群組名稱。

日誌級別通常分為四檔,用戶端設定裡一般可以調整顯示的最低級別:

1. Debug:最詳細,包含規則比對的完整過程,平時不需要開啟,排查疑難問題時才打開。
2. Info:預設級別,記錄正常的連線建立、規則比對、節點切換等資訊。
3. Warning:非致命異常,比如某次 DNS 查詢走了備用解析器、某個節點探測逾時但還有備選。
4. Error:連線失敗、設定載入出錯等需要留意的問題,通常伴隨具體錯誤文字。

排查問題時,建議先把級別調到 Info 或 Debug,重現一次問題操作(比如打開某個打不開的網頁),再回頭看日誌裡 Error 和 Warning 級別的記錄,精確對應到出問題的那次請求。

connection refused 類錯誤

這是最常見的錯誤之一,完整資訊通常類似:

[Error] [TCP] dial tcp 203.0.113.10:443: connect: connection refused

它的含義是:本機已經把連線請求送出,但對端(可能是節點伺服器,也可能是目標網站)主動拒絕了這次 TCP 連線,常見原因分三類:

• 節點伺服器不可用:節點已下線、埠被服務商暫時關閉,或者節點本身設定有誤(埠號、加密方式與伺服端不一致)。這種情況下換一個同訂閱裡的其他節點通常能立刻驗證。
• 本機防火牆或安全軟體阻擋:部分安全軟體會阻擋用戶端建立的出站連線,尤其是在開啟 TUN 模式後更容易觸發。可以暫時關閉安全軟體的即時防護做對比測試。
• 目標網站拒絕了當前節點的 IP:少數網站會針對特定 IP 段做存取限制,這種情況即便節點本身正常,存取該網站也會持續報錯,換節點是唯一的處理辦法。

區分這三種情況的簡單方法是:同一個節點存取多個不同網站,如果全部報 connection refused,大機率是節點或本機環境問題;如果只有個別網站報錯,而其他網站正常,則更可能是目標網站對該節點 IP 的限制。

DNS 逾時與解析失敗

DNS 相關的錯誤通常帶有明確的關鍵詞,例如:

[Warning] [DNS] resolve example.com failed: context deadline exceeded
[Error] [DNS] all DNS servers failed to resolve example.com

第一條表示某一次網域解析請求逾時(超過了設定裡設定的逾時時間),如果只是偶發,通常不影響使用,核心會自動重試或切換到下一個 DNS 伺服器。第二條則表示設定檔裡列出的所有 DNS 伺服器都解析失敗,這時網頁會直接打不開。

DNS 解析失敗常見的排查方向:

1. 檢查設定檔裡的 DNS 段落:確認 nameserver 清單裡的位址本身是可用的,如果用了海外 DNS(如 8.8.8.8、1.1.1.1),要確認這些位址的查詢請求本身也是走代理轉發的,否則在網路環境不允許直連的情況下同樣會逾時。
2. 確認是否開啟了 Fake-IP 模式:Fake-IP 會給網域配置一個虛擬 IP,交由核心在建立連線時再做真實解析,如果這一層設定有誤(比如 fake-ip-range 與本機網段衝突),會表現為網域能被「解析」但實際連不上。
3. 排查本機 Hosts 檔案或其他代理軟體干擾:如果本機同時執行了其他網路工具,或者 Hosts 檔案裡有舊的網域對應記錄,也會導致 DNS 層出現異常結果。

訂閱解析失敗

更新訂閱時如果出現下面這類錯誤,說明問題發生在拉取或解析設定檔這一步,和代理節點本身沒有關係:

[Error] update subscription failed: Get "https://sub.example.com/link": context deadline exceeded
[Error] parse config failed: yaml: line 42: did not find expected key

第一條是網路層面的失敗:用戶端沒能在逾時時間內從訂閱服務商的伺服器取得內容,常見原因包括本機此時沒有可用的代理去存取訂閱連結、訂閱服務商的伺服器暫時無法連線,或者訂閱連結本身已經失效。第二條是內容層面的失敗:訂閱內容成功下載,但 YAML 格式解析出錯,通常是訂閱服務商暫時回傳了錯誤頁面(比如維護公告的 HTML),而不是正常的設定內容。

處理訂閱解析失敗,可以按下面的順序排查:

• 先確認訂閱連結是否能在瀏覽器裡正常打開並看到文字內容,如果打開的是錯誤頁面或空白頁,說明問題在服務商一側,需要聯繫訂閱提供方或等待恢復。
• 檢查更新訂閱時使用的網路環境:部分用戶端在更新訂閱時會走「直連」而不是目前啟用的代理,如果直連環境無法存取訂閱網域,更新自然會逾時。
• 確認訂閱連結裡是否包含特殊字元或者被截斷,複製貼上時多一個空格或少一個字元都會導致連結失效。

策略群組測速與節點切換類日誌

如果設定檔裡使用了自動測速的策略群組(比如 url-test 或 fallback 類型),日誌裡會持續出現類似記錄:

[Info] Proxy-HK check health: 156ms
[Warning] Proxy-SG check health failed: dial tcp: i/o timeout

這類日誌屬於核心的健康檢查機制,每隔一段時間會對策略群組內的節點發起一次測速請求,記錄延遲或標記為不可用。看到某個節點持續 check health failed,說明該節點目前確實存在問題,策略群組會自動跳過它選擇延遲較低的備選節點,這也是為什麼有時候明明設定沒變,存取速度卻時快時慢——背後是策略群組在節點間動態切換。

如果整組節點都測速失敗,通常指向兩種情況:一是訂閱本身品質不佳,節點大批量不可用;二是本機網路環境異常,導致所有出站連線都無法建立,這時候需要先排除本機網路問題,而不是急著更換訂閱。

TUN 模式相關錯誤

開啟 TUN 模式(系統級代理,接管全域流量)後,如果啟動失敗,日誌裡通常會給出比較直接的提示:

[Error] start TUN device failed: operation not permitted
[Error] start TUN device failed: address already in use

第一條基本可以確定是權限問題:TUN 模式需要建立虛擬網卡,這個操作要求用戶端以系統管理員權限執行,如果之前是以一般權限啟動的,重新以系統管理員身分打開用戶端通常就能解決。第二條表示虛擬網卡使用的位址段和本機現有網路設定衝突,常見於同時執行了其他基於虛擬網卡的工具(如某些 VPN 用戶端),需要先關閉衝突的軟體,或者在設定裡調整 TUN 使用的位址段。

依錯誤類型定位問題的實用方法

把上面幾類錯誤串起來,可以整理出一條相對通用的排查順序:

1. 先確認問題發生的層次:是完全連不上網(可能是 TUN 或系統代理設定問題),還是特定網站打不開(更可能是節點或規則問題),還是所有網站都慢(更可能是節點品質或跨境線路問題)。
2. 打開日誌頁,重現一次操作:把日誌級別調整到 Info,重新觸發一次失敗的存取,記下當次產生的錯誤文字。
3. 按關鍵詞分類:dial tcp/connection refused 指向節點或目標站點連線問題;DNS 相關指向網域解析層;update subscription/parse config 指向訂閱拉取與格式問題;TUN 相關指向系統級代理權限或網路裝置衝突。
4. 逐層排除:先排除本機環境(權限、防火牆、其他代理軟體衝突),再排除訂閱與節點本身,最後才考慮是目標網站的個別限制。

堅持這個順序,大多數錯誤都能在幾分鐘內定位到大致方向,不需要反覆試錯式地更換設定或節點。

小結

日誌不是給開發者看的黑箱輸出,而是用戶端主動告訴你「這次連線卡在哪一步」的說明文字。花幾分鐘熟悉常見錯誤的關鍵詞和對應含義,遇到問題時先看日誌再動手調整設定,通常比反覆重啟用戶端或盲目更換節點更節省時間,也更容易找到真正的問題根源。