Clash 運行日誌怎麼看:常見報錯含義與排查思路

用戶端連不上的時候,反覆切換系統代理開關、閉著眼睛逐個點節點,是最常見的第一反應。其實核心日誌裡已經把失敗原因寫得相當具體,只是格式緊湊、英文報錯居多,很多人瞥一眼就關掉了。本文按報錯關鍵字把常見日誌條目分成五類,逐條說明它發生在哪個環節、通常是什麼原因、下一步該查什麼。

先讀懂一行日誌的結構

Clash 核心(包括 Clash Meta / mihomo)的連線日誌格式基本固定。以一條典型的 TCP 記錄為例:

[TCP] 127.0.0.1:52310 --> www.google.com:443 match DomainSuffix(google.com) using 節點選擇[香港 01]

拆開看是五個欄位:

• [TCP] / [UDP]:這條連線走的傳輸協定。網頁瀏覽絕大多數是 TCP;QUIC、部分遊戲與語音通話會走 UDP。
• 127.0.0.1:52310:本機哪個來源發起的連線。系統代理模式下通常是 127.0.0.1;TUN 模式下能看到更具體的內網來源位址。
• --> www.google.com:443:目標位址與埠。這裡如果顯示的是 IP 而不是網域,說明程式直接用 IP 發起連線,規則裡的網域比對對它是無效的。
• match DomainSuffix(google.com):命中的規則。顯示 match Match() 說明一路漏到了最後一條兜底規則,前面的規則集全都沒比對到。
• using 節點選擇[香港 01]:實際出口。顯示 DIRECT 表示這條流量沒走代理——目標本該走代理卻顯示 DIRECT,問題出在規則而不在節點。

日誌詳細程度由設定裡的 log-level 控制,可選 silent、error、warning、info、debug,多數用戶端預設 info。排查問題時先調到 debug,能看到 DNS 查詢、規則比對細節與交握過程:

log-level: debug

圖形化用戶端(Clash Verge Rev、Clash for Windows 等)都內建日誌頁面,可以直接切換等級;純核心部署時日誌走標準輸出,設定 external-controller 後也能透過控制器的 /logs 介面即時拉取。

節點連線階段的報錯

日誌裡出現 dial 字樣,說明 Clash 正在向節點伺服器發起連線,問題發生在本機到節點之間的鏈路上。

[TCP] dial 香港 01 --> www.google.com:443 error: dial tcp 198.51.100.7:443: connect: connection refused

• connect: connection refused:伺服器拒絕了連線,節點埠上沒有服務在監聽。常見於節點已下線、埠被更改、訂閱資訊過期。先換同訂閱裡的其他節點,全部失敗就更新一次訂閱。
• i/o timeout / context deadline exceeded:連線超時,請求發出去沒有任何回應。相比 refused,這更像鏈路被阻斷或伺服器當機。把本機從 Wi-Fi 切到手機熱點再測,能快速區分是本地電信業者的問題還是節點的問題。
• connection reset by peer:連線建立之後被對方中途切斷。偶發一次可以忽略;持續出現說明節點負載過高,或傳輸過程受到了干擾。

這一階段與本地代理設定無關——只要日誌裡已經出現 dial 節點的記錄,說明流量已經成功進入 Clash,不必再回頭折騰系統代理開關。

TLS 與協定交握階段的報錯

連上了伺服器但交握失敗,報錯關鍵字會變成 tls、x509、EOF 一類。

• x509: certificate has expired or is not yet valid:憑證時間校驗失敗。先查本機系統時間是否準確,時間偏差過大時幾乎所有 TLS 類協定都會失敗;系統時間正常,再去懷疑節點憑證設定。
• tls: first record does not look like a TLS handshake:對端埠上跑的不是 TLS 服務。通常是訂閱裡的埠或協定類型填錯,例如把 Trojan 節點指到了非 TLS 埠上。
• EOF / tls: handshake failure:交握進行到一半連線被掐斷。SNI、ALPN 與伺服器不符時常見,檢查節點設定裡的 servername / sni 欄位是否被更改。
• Shadowsocks 報 cipher: message authentication failed:AEAD 校驗失敗,密碼或加密方式與伺服器不一致,回訂閱來源核對這兩項。
• VMess 節點設定看著沒錯卻認證失敗:核對系統時間。VMess 按時間戳記做校驗,本機時間與伺服器偏差超過允許範圍就會被拒絕。
• WebSocket 類節點報 websocket: bad handshake:路徑(path)或 Host 與伺服器不符,CDN 回源設定變更之後尤其常見。

交握階段的報錯基本與本地網路品質無關,集中在兩件事上:節點參數是否被改、訂閱資訊是否過期。

設定與訂閱載入階段的報錯

這類報錯出現在啟動核心或更新訂閱時,日誌裡帶 yaml、unmarshal、proxy provider 等詞。

• yaml: line X: ... / unmarshal errors:設定檔第 X 行附近語法錯誤。YAML 不允許用 Tab 縮排,冒號後面必須有空格,含特殊字元的值要加引號。按行號回去檢查即可。
• proxy [xxx] not found:策略組引用了不存在的節點。改名或刪節點之後忘了同步修改策略組,把引用名稱對齊就能解決。
• rules[X] ... error:第 X 條規則解析失敗。常見原因是規則類型寫錯,或參數數量不對,例如漏寫了最後的去向策略。
• proxy provider ... error、更新訂閱回傳 404 或超時:訂閱連結失效,或者訂閱位址本身在目前網路下無法連上。用戶端一般帶「透過代理更新訂閱」的開關,訂閱位址需要代理才能存取時,打開它再更新。

設定載入失敗時核心往往直接退出或拒絕啟動,所以這類報錯其實是最好定位的:報錯資訊裡行號、欄位名都給得很具體,照著改就行。

DNS、埠佔用與 TUN 的報錯

• dns resolve failed、DNS 查詢超時:Clash 內建 DNS 沒設定好,或上游伺服器無法連上。確認設定裡 dns.enable: true,nameserver 清單裡有可連上的上游;開 fake-ip 模式出現異常時,先切回 redir-host 驗證是不是 fake-ip 快取的問題。

dns:
  enable: true
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

• bind: address already in use、監聽 7890 失敗:混合埠被佔用。多數情況是有另一個核心程序或同類軟體還在執行,結束舊程序即可;也可以改 mixed-port 換埠,但系統代理設定裡的埠要同步改。
• TUN 模式啟動失敗(permission denied、找不到 utun / wintun 裝置):TUN 需要系統管理員權限,Windows 還依賴 wintun 驅動程式。用系統管理員身分執行用戶端;仍然報錯時,把 tun.stack 在 system 與 gVisor 之間切換試試,個別協定堆疊與特定系統版本不相容。
• 系統代理設定失敗:macOS 需要授權才能修改網路設定;Windows 下檢查是否有安全軟體攔截了代理開關的寫入。

一套固定的排查順序

1. 把日誌等級調到 debug,完整重現一次故障,讓報錯新鮮地出現在日誌末尾。
2. 從下往上找第一條 error 或 warning,不要盯著最後一條——後面刷屏的內容往往只是第一條錯誤的連鎖反應。
3. 按關鍵字把第一條報錯歸類到五個環節之一:設定載入、訂閱更新、DNS 解析、節點連線、協定交握,再對照前面幾節處理。
4. 交叉驗證。繞過系統代理,直接走 Clash 埠測一次:

curl -x http://127.0.0.1:7890 https://www.google.com -I

1. 能通,說明核心與節點正常,問題在系統代理或瀏覽器;不通,問題在核心到節點之間。每次只改一處再測,一次改三處就永遠不知道是哪一處起的作用。

報錯關鍵字速查表

日誌是 Clash 給出的第一手證詞。先讀日誌、再動手改,排查順序固定下來之後,大多數連線問題都能在幾分鐘內定位到具體環節。