Clash 運行日誌怎麼看:日誌級別、常見報錯含義與定位方法

日誌級別與閱讀順序

基於 mihomo 核心的用戶端在啟動與運行期間會持續輸出日誌,日誌級別通常分為 silent、error、warning、info、debug 五檔,由設定檔中的 log-level 欄位控制。級別之間是包含關係:選擇 info 會同時輸出 info、warning、error 三類內容,選擇 debug 則包含全部資訊,資料量最大也最詳細。

排查問題時不建議一開始就翻 debug 日誌,資訊密度過高反而拖慢定位速度。合理的順序是:先看啟動階段是否有 error 級別的紅色報錯,確認核心能否正常拉起;再看連線請求時的 warning,判斷是網路層問題還是規則層問題;最後如果前兩步都看不出線索,才切到 debug 級別重現一次具體請求,逐行核對域名解析、節點選擇與規則命中的順序是否符合預期。

常見報錯逐條解讀

以下幾類報錯在日誌中出現頻率最高,理解它們的觸發條件比死記文案更有用。

DNS 解析失敗

日誌中出現類似「resolve host failed」或「dns resolve error」的內容,通常意味著設定裡的 nameserver 無法正常回應,或者目標域名本身不在解析範圍內。這類問題常見於三種情境:自訂 DNS 伺服器無法連線、DNS over HTTPS 位址寫錯,以及規則裡對某個域名設定了 no-resolve 卻仍需要連外解析。核對方式是先用系統自帶的網路工具單獨測試 nameserver 清單中的位址是否可用,再確認規則集裡涉及的域名比對類型是否正確。

握手逾時

「handshake timeout」或「dial tcp timeout」類報錯,指的是用戶端與代理節點之間的連線建立階段逾時,還沒進入真正的資料傳輸。常見原因包括節點伺服端已下線、訂閱連結裡的通訊埠資訊過期、本機網路對特定通訊埠有限制,以及節點所在地區的網路連線本身不穩定。遇到這類報錯先切換到訂閱內的其他節點測試,如果多個節點都逾時,問題大概率出在本機網路環境而不是訂閱本身。

規則未命中與兜底策略

日誌裡如果頻繁出現某個域名最終落到 MATCH 或 FINAL 規則對應的策略群組,說明前面所有規則都沒有命中,這不一定是錯誤,但如果這個域名本應走某條特定規則,就說明規則順序或比對類型寫錯了。mihomo 的規則比對是自上而下的順序比對,一旦某條規則命中就不再繼續往下比對,所以範圍更寬的規則應當放在範圍更窄的規則之後,否則窄規則永遠沒有機會生效。

連線被拒絕與通訊埠占用

「connection refused」多半是目標通訊埠沒有服務在監聽,或者本機代理通訊埠與其他程式衝突。啟動階段如果日誌提示通訊埠已被占用,先檢查是否有多個用戶端實例同時運行,或者系統裡其他工具占用了同一個混合通訊埠。

從日誌反推設定問題的定位路徑

日誌報錯本身只是現象,真正需要做的是把現象和設定檔裡的具體欄位對應起來。一條可行的排查路徑是:

1. 確認報錯發生的階段——是核心啟動時就報錯,還是發起某次連線請求時才報錯,兩者對應的排查範圍完全不同。
2. 記錄報錯涉及的域名或 IP,回到設定檔裡搜尋這個域名可能比對到的規則條目,核對比對類型是否符合預期。
3. 如果懷疑是節點問題,單獨在策略群組裡切換到唯一一個節點做測試,排除策略群組內多節點輪詢帶來的干擾。
4. 如果日誌顯示的是 DNS 層報錯,單獨驗證 dns 設定區塊中的 nameserver、fallback 欄位,必要時暫時換成公共 DNS 位址做對比測試。
5. 問題定位後,每次只改一處設定再重啟驗證,避免同時改多處導致無法判斷到底是哪個改動解決了問題。

提升日誌可讀性的設定建議

日常使用建議將 log-level 保持在 info,這個級別既能看到關鍵的連線狀態,又不會被大量除錯細節淹沒。如果用戶端支援在介面內直接查看運行日誌,優先使用介面內的即時日誌面板,它通常會按時間順序滾動顯示,比手動開啟日誌檔案更直觀。遇到間歇性問題時,可以先固定重現步驟,記錄重現前後的時間戳記,再回頭在日誌裡按時間段篩選,能大幅縮短翻找範圍。

另外,規則集與訂閱內容更新後,建議重新觀察一輪日誌,確認新規則是否按預期順序生效,而不是等到實際使用中偶然發現分流結果不對再回頭排查。把日誌檢查作為設定變更後的固定一步,能提前發現大部分因為規則順序或欄位拼寫導致的問題。