看懂 Clash 執行日誌:info/warning/error 等級與常見錯誤訊息速查

日誌等級是什麼,先設對再看

Clash 核心(無論是原版 Clash 還是 Mihomo,即 Clash Meta)都採用統一的日誌等級體系,從詳細到簡略依序是 debug、info、warning、error、silent。設定檔裡對應的欄位是 log-level,大多數客戶端在設定介面也有同名開關。日常排查建議先切到 info 觀察連線是否正常建立,遇到具體問題再暫時切到 debug 看更細的交握過程,處理完記得切回去,debug 等級日誌量非常大,長期開著會佔用磁碟空間並影響閱讀效率。

log-level: info
# 排查連線問題時暫時改為
log-level: debug

四個等級的含義並非隨意劃分,理解清楚能幫你快速判斷一條日誌是否值得留意:

debug:最細粒度,包含 DNS 解析細節、交握過程、連線池狀態等,正常運作時噪音很大。
info:記錄每條連線的規則比對結果、使用的節點、目標位址,日常觀察用這個等級最合適。
warning:表示出現異常但核心仍在嘗試自行處理,例如某個節點健康檢查失敗但還有其他節點可用。
error:明確的失敗結果,連線沒有建立成功,通常需要人工介入。

客戶端圖形介面裡的日誌面板一般會用顏色區分等級,warning 常顯示為黃色、error 顯示為紅色,這與設計系統裡語意色的用法思路一致:顏色只是提示優先程度,具體原因還得看文字內容。

連線類錯誤逐條解讀

這一類日誌出現在核心嘗試與目標伺服器或代理節點建立 TCP/UDP 連線的階段,是排查「連不連得上」問題時最先要看的內容。

dial tcp timeout

表示核心發起連線後,在逾時時間內沒有收到任何回應。常見原因有三種:目標伺服器本身回應慢或已離線;所選代理節點到目標伺服器的線路存在丟包;本機到代理伺服器之間的網路本身就不通(例如節點伺服器已過期或被封鎖)。建議的排查順序是先換代理群組內的其他節點測試同一個目標位址,如果換節點後立刻恢復,說明問題出在那個節點,不是本機設定;如果換哪個節點都逾時,再檢查本機到代理伺服器出口的基礎連通性。

connection refused

這條和 timeout 不同,它表示對方明確拒絕了連線請求,說明網路線路是通的,只是目標埠沒有服務在監聽,或被防火牆主動拒絕(而不是丟棄)。如果日誌裡這條錯誤指向的是 127.0.0.1 加某個本機埠,通常是核心自身沒有正常啟動監聽,或者混合埠設定被更改後客戶端介面沒有同步刷新,值得檢查一下 mixed-port 的設定值以及行程是否真的在監聽該埠。

no route to host

這是網路層面的錯誤,系統路由表裡沒有到達目標 IP 的路徑。開啟 TUN 模式後,如果路由表被寫壞或與系統原有路由衝突,很容易出現這條日誌,重啟一次 TUN 服務,或檢查是否有其他網路工具同時接管了預設路由,通常能解決問題。

i/o timeout 與 EOF

i/o timeout 多出現在已經建立連線之後的讀寫階段,說明連線建立成功但資料傳輸中斷,常見於節點頻寬不足或長連線被中間設備強制斷開。EOF 則表示對端主動關閉了連線,如果只是偶爾出現一兩次通常不用理會,如果頻繁出現在同一個節點上,可以考慮把該節點從代理群組裡暫時剔除。

規則比對日誌怎麼讀

info 等級下,每一條新連線都會印出一行規則比對結果,格式大致是「比對到的規則類型加使用的策略」。這類日誌不是錯誤,但是排查「為什麼這個網站沒走代理」或「為什麼速度不對」的關鍵線索。

[TCP] example.org:443 match DomainSuffix(example.org) using PROXY
[TCP] cn.example.com:443 match GEOIP(CN) using DIRECT
[TCP] 10.0.0.5:8080 match Match() using REJECT

第一行說明這條連線命中了網域後綴規則,走的是 PROXY 策略群組;第二行說明目標 IP 被判定為中國大陸位址,依 GEOIP 規則直連;第三行說明沒有命中任何具體規則,落到了保底的 MATCH 規則上,而這條保底規則的策略是 REJECT,也就是直接拒絕。如果發現大量本該正常存取的連線都落到保底規則並被拒絕,通常是規則清單順序有問題,或者保底規則本該寫 DIRECT 卻誤寫成了 REJECT,回頭檢查設定檔裡 rules 的最後一行最容易發現問題。

注意

規則是依序由上到下比對的,一旦命中就不再往下看。如果一條本該走代理的網域卻被前面某條更寬泛的規則提前攔截為直連,日誌裡的 match 資訊會直接告訴你是哪條規則起了作用,不需要靠猜測。

節點與代理群組相關的警告

除了單條連線的錯誤,Clash 還會定期輸出代理群組健康檢查的結果,這類日誌等級通常是 warning,不代表連線徹底失敗,但值得留意。

health check failed / url-test 逾時:代理群組設定了自動測速(url-test 或 fallback 類型),某個節點沒能在設定時間內完成對測試位址的請求,核心會把它標記為不可用並暫時跳過,等下一輪檢測再重新嘗試。偶爾出現一兩次屬於正常波動。
all proxies unavailable / no proxy available:代理群組裡所有節點都被判定不可用,這時該群組下的所有連線都會失敗。原因可能是訂閱節點整體過期,也可能是測速位址本身在你的網路環境下不通,導致誤判所有節點都失敗。可以先手動切換到群組內某個節點直接測試,如果手動能連上,說明是測速邏輯誤判,可以調整測速位址或間隔時間。
proxy group has no selected proxy:策略群組下沒有任何可選節點,通常是訂閱解析後節點清單為空,回到訂閱管理裡檢查節點數量以及過濾規則是否把節點全部篩掉了。

DNS 相關日誌與排查思路

不少看起來像連線問題的錯誤,根源其實是 DNS 沒解析成功。日誌裡如果出現 could not resolve host 或解析結果異常緩慢,先確認設定檔裡 dns 欄位是否啟用,以及使用的上游 DNS 伺服器是否可達。開啟了 fake-ip 模式後,如果某些應用程式無法正確處理虛擬 IP,也會在日誌裡表現為連線目標位址異常,這種情況通常需要在 fake-ip-filter 裡把相關網域加入例外,讓這類流量走真實 IP 解析而不是虛擬位址。

整體排查思路可以歸納為三步:先看等級判斷嚴重程度,error 才需要立即處理;再看錯誤文字判斷是網路層問題(timeout、refused、no route)還是邏輯層問題(match、health check);最後結合上下文的目標位址與節點名稱,把問題精確定位到具體的節點、規則或本機網路環節,而不是籠統地懷疑「整個代理壞了」。