看懂 Clash 執行日誌：常見錯誤訊息的含義與問題定位思路

日誌為什麼是排障的第一手資料

遇到「打不開網頁」「訂閱用不了」「某個應用程式連不上」這類問題時，很多人第一反應是換節點、重啟用戶端，試幾次不行就放棄。其實這類問題的答案，往往已經寫在日誌裡了。Clash 核心（無論是原版 Clash 還是現在更常用的 Clash Meta / mihomo 核心）在處理每一條連線時都會記錄一行日誌：這條流量從哪來、走了哪條規則、最終試圖連向哪裡、連線是成功還是失敗、失敗的具體原因是什麼。

換句話說，日誌把「網路不通」這個籠統的現象拆成了具體的環節：是本機沒發出請求，是 DNS 解析沒成功，還是握手時被目標或節點拒絕了。學會讀日誌之後，排障就從「盲試」變成了「按線索定位」，效率會明顯提升。

日誌等級與開啟方式

Clash 的日誌分為幾個等級，等級從低到高大致是 debug、info、warning、error、silent。等級越低，記錄的內容越詳細：

• debug：幾乎所有內部動作都會記錄，包括每一次 DNS 查詢、每一次連線嘗試，排查疑難問題時最有用，但輸出量很大。
• info：日常使用推薦的等級，會記錄連線建立、規則比對、連線關閉等關鍵節點，不至於刷屏。
• warning / error：只記錄出現異常的連線，日常安靜，排障時資訊量偏少。

大多數圖形化用戶端把日誌面板放在主介面的側邊欄或底部標籤，標題通常寫作「日誌」或「Logs」，介面上一般能直接切換等級。排查具體問題時，建議暫時切到 debug 等級，重現一次問題後再切回 info，避免長期產生過多日誌檔案。

常見日誌項目逐條對照

日誌的格式因核心版本略有差異，但核心資訊大同小異：時間、等級、協議類型、來源位址、目標位址、比對到的規則與策略、以及成敗結果。下面按錯誤類型逐一說明。

連線類錯誤：connection refused / timeout

[TCP] 192.168.1.5:51234 --> example.com:443 match RuleSet(proxy) using 節點A
dial tcp 203.0.113.10:443: connect: connection refused

connection refused 表示三次握手請求被目標端明確拒絕了，通常意味著對端埠沒有監聽服務、節點伺服端已下線，或者是節點本身出現故障。i/o timeout（逾時）則不同，它表示請求發出去後既沒有被拒絕也沒有回應，常見於線路壅塞、目標伺服器無回應，或者節點所在網路被限速甚至封鎖。二者的差異很關鍵：被拒絕通常該換節點，逾時則要先懷疑線路品質。

DNS 解析錯誤：no such host

dial tcp: lookup example.com: no such host

這行日誌出現在建立連線之前，說明域名解析這一步就沒有成功，根本沒走到連線節點那一步。常見原因是 DNS 伺服器不可用、設定檔裡的 nameserver 寫錯、或者啟用了某些需要特定 DNS 模式配合的分流規則卻沒配套開啟 fake-ip 或 enhanced-mode。如果絕大多數域名都報這個錯，先檢查 DNS 設定本身；如果只是個別域名報錯，更可能是該域名在部分 DNS 伺服器上確實解析異常。

規則比對記錄：確認流量走向

[TCP] 10.0.0.8:60021 --> api.example.com:443 match DomainSuffix(example.com) using DIRECT

這類日誌不是錯誤，而是「流量走向說明書」。match 後面寫的是命中的具體規則，using 後面寫的是最終使用的策略（DIRECT 直連、某個節點或策略群組）。如果存取明明該走代理的網站卻發現日誌裡 using DIRECT，說明規則沒有生效或者順序排在了直連規則後面；反過來，如果本該直連的台灣本地位址走了代理，也能在這裡第一時間發現。規則命中記錄是判斷「設定是否按預期運作」最直接的證據。

TLS 與握手類錯誤

remote error: tls: handshake failure
EOF

握手失敗或連線中途收到 EOF（對端主動關閉連線），常見於節點的傳輸協議設定與伺服端不一致（比如 TLS 參數、SNI 偽裝域名對不上），或者節點伺服端本身在做流量清洗時誤判了連線。這類問題通常不是本機設定問題，建議先在訂閱或節點清單裡換一個節點驗證，如果多個節點都出現同類錯誤，再回頭檢查本機設定檔裡對應協議欄位的寫法。

按時間軸定位問題：從發起請求到資料返回

拿到一段日誌後，建議按下面的時間順序去看，而不是一眼掃過去找紅色字樣：

1. 請求是否被本機捕獲。確認日誌裡出現了這條連線的記錄，如果完全沒有記錄，問題可能出在系統代理沒生效或 TUN 模式沒有正確接管流量，而不是節點問題。
2. DNS 解析是否成功。看是否出現 no such host 一類記錄，解析失敗的話，後面的連線環節根本不會發生。
3. 規則比對是否符合預期。確認 match 和 using 欄位指向的策略是不是你想要的，走錯策略群組比走錯節點更容易被忽略。
4. 連線是否建立成功。看是否出現 connection refused、timeout 或 TLS 相關錯誤，這一步的錯誤基本能對應到「換節點」還是「查線路」。
5. 連線建立後是否正常關閉。正常存取結束後應該有連線關閉的記錄，如果連線長時間掛起沒有關閉記錄，可能是目標服務回應慢，而不是網路層面的問題。

把這五步在腦子裡過一遍，基本能把「連不上」這個模糊的說法，精確到某一個具體環節。

常見情境與對照速查表

排查時的幾個建議

把日誌當作證據鏈去看，而不是當作「哪裡標紅了就是哪裡壞了」的信號燈。多個節點同時出現同一類錯誤，通常指向本機設定或 DNS；只有個別節點出問題，通常是節點本身的狀態。養成先看日誌再動手改設定的習慣，能省掉大量來回試錯的時間。

如果日誌裡的錯誤反覆出現同一種類型，且已經排除了本機設定和網路環境的問題，也可以對照官方的快速上手說明重新走一遍基礎設定，確認訂閱、DNS 模式與規則設定都處在建議的預設狀態。