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

為什麼日誌是排查問題的第一手資料

Clash 系用戶端(包括原版核心與 mihomo 核心)在執行時會持續輸出結構化文字日誌,記錄連線建立、規則匹配、DNS 查詢、代理選擇等每一步的執行結果。相比「能不能上網」這種模糊的現象描述,日誌給出的是具體到某一條連線、某一次查詢的失敗原因,這也是官方文件和社群排障流程裡反覆強調「先看日誌」的原因。

大多數用戶端(Clash Verge、Clash for Windows 系衍生版、mihomo party 等)在主介面都提供「日誌」或「Logs」標籤頁,部分還支援按級別篩選和按關鍵字搜尋。命令列執行核心時,日誌會直接輸出到終端標準輸出,也可以透過設定檔裡的 log-level 欄位控制輸出到指定檔案。無論用哪種用戶端,理解日誌格式和常見錯誤類型,都能把排查時間從「反覆重啟試運氣」壓縮到「定位具體環節」。

日誌級別怎麼設定,該看哪一級

Clash 設定檔中的 log-level 欄位決定了輸出的詳細程度,常見取值從粗到細依次為:

• silent:不輸出任何日誌,僅用於生產環境完全靜默執行,排查問題時不要用這一級。
• error:只記錄連線失敗、設定解析錯誤等嚴重問題,資訊量最少,容易漏掉中間過程。
• warning:在 error 基礎上增加潛在異常提示,例如規則集載入耗時過長、憑證即將過期等。
• info:預設建議級別,記錄代理選擇結果、DNS 查詢摘要、連線建立與關閉,資訊密度適中,日常排障夠用。
• debug:輸出最完整的執行細節,包括每條規則的匹配嘗試過程、協定握手的具體位元組互動摘要,排查疑難問題時臨時開啟,日常不建議長期使用(日誌量大、可能影響效能)。

設定方式是在 YAML 設定檔裡設定:

log-level: info

高頻錯誤逐條解析

DNS 解析失敗類

這類日誌通常包含 dns resolve failed、no such host 或類似字樣,表示用戶端嘗試將網域解析為 IP 位址時未成功。常見成因包括:

• 設定檔中 DNS 伺服器位址填寫錯誤或該伺服器已失效;
• 啟用了 fake-ip 模式但目標網域被錯誤地劃入了直連(direct)分組,導致真實 DNS 請求未經過代理通道;
• 使用 DoH/DoT 加密 DNS 時,上游加密 DNS 伺服器本身需要經過代理才能存取,形成「先有雞還是先有蛋」的死結;
• 網域本身不存在或已過期,這種情況屬於網域問題而非用戶端問題。

定位思路:先確認設定裡的 nameserver 欄位是否為有效位址,再檢查該網域對應的規則分組是否命中了預期節點。如果是加密 DNS 死結問題,可以給 DNS 伺服器位址單獨設定直連或指定一個穩定可用的落地節點。

握手逾時類

日誌中出現 handshake timeout、dial tcp: i/o timeout 或 context deadline exceeded,表示用戶端已經嘗試與代理節點建立連線,但在規定時間內未完成 TLS 握手或 TCP 連線建立。這類錯誤的成因分三個層面:

• 節點端:伺服器已下線、連接埠被臨時封鎖,或伺服器所在地區網路品質差;
• 協定參數端:用戶端與伺服器的加密方式、傳輸協定(如 WebSocket 路徑、gRPC 服務名稱)設定不一致,握手請求格式不被對端接受;
• 本地網路端:本地出口網路本身對目標連接埠做了限速或干擾,尤其常見於某些電信業者對特定連接埠的 QoS 策略。

定位思路:先用同一訂閱下的其他節點測試,如果全部節點都逾時,問題大概率在本地網路;如果只有個別節點逾時,優先懷疑該節點本身狀態或協定參數填寫有誤。

規則未命中類

日誌裡出現 match RuleSet(...) 或 final rule 但代理走向與預期不符,並非錯誤,而是規則匹配邏輯生效但結果不是使用者預想的分組。常見原因:

• 規則檔按從上到下順序匹配,前面某條更寬泛的規則先命中,導致後面精確的規則未被執行到;
• 規則集(rule-provider)未及時更新,仍在使用舊版本的網域/IP 清單;
• 最終兜底規則(MATCH)指向了非預期的分組,所有未命中前面規則的流量都會落到這裡。

定位思路:開啟 debug 級別日誌後,針對具體網域發起一次連線,在日誌中搜尋該網域,查看它實際匹配到了哪一條規則、落到了哪個代理分組,再對照規則檔逐條核對順序。

連線被拒絕與協定錯誤類

connection refused 表示目標連接埠沒有服務在監聽,通常是伺服器設定的連接埠與用戶端填寫的連接埠不一致,或服務端服務未啟動。invalid header、unexpected EOF 一類的協定層錯誤,多數指向用戶端與伺服器兩端的加密方式、混淆參數(如 obfs 類型)不匹配,需要逐項核對訂閱中的協定欄位。

按錯誤類型定位問題源頭的實用路徑

拿到一條錯誤日誌後,建議按下面的順序縮小排查範圍,而不是逐個嘗試所有可能原因:

1. 第一步,區分錯誤發生的階段。是在 DNS 解析階段、還是握手連線階段、還是規則匹配階段?日誌裡的關鍵字(resolve / dial / handshake / rule)通常已經標明了階段,先按階段分類能排除大半無關方向。
2. 第二步,判斷是否為單一節點問題。切換到同訂閱下的另一個節點重試,如果問題消失,說明是該節點的服務端狀態或參數問題;如果依舊存在,繼續第三步。
3. 第三步,判斷是否為本地網路問題。臨時關閉代理直接存取目標網站,或用手機熱點等不同網路環境測試,排除本地電信業者、路由器策略造成的干擾。
4. 第四步,核對設定檔本身。檢查 DNS 設定、規則順序、rule-provider 更新時間,以及訂閱是否為最新版本,很多「看似節點問題」最終定位為設定檔過期或欄位拼寫錯誤。
5. 第五步,升級日誌級別重現問題。如果前四步都沒定位到,把 log-level 臨時調整為 debug,完整重現一次故障,保存相關日誌片段用於進一步分析或提交社群求助。

日常查看日誌的幾個實用習慣

• 連線出問題時先看時間戳記,定位到故障發生的具體時刻,再回溯前後幾秒的日誌上下文,避免在長日誌裡漫無目的地翻找。
• 善用用戶端日誌頁的關鍵字過濾功能,直接搜尋出問題的網域或 IP,能快速定位相關的所有日誌行。
• 規則改動後,建議開一次 debug 級別驗證新規則確實按預期生效,再切回 info 級別長期執行。
• TUN 模式下的問題往往同時涉及系統網路堆疊和核心日誌兩部分,遇到 TUN 模式連不上的情況,除了看 Clash 自身日誌,也要留意用戶端是否有單獨的 TUN 狀態提示。
• 保留最近一次正常運作時的設定檔備份,遇到升級後突然錯誤增多的情況,可以直接比對設定差異定位改動點。