Clash 日誌看不懂？常見錯誤訊息與問題定位方法

先判斷日誌來自哪個環節

Clash、Clash Meta 與 mihomo 的日誌看起來相似，但同一頁面可能混有客戶端日誌、核心日誌與設定更新紀錄。定位問題前，先確認錯誤是由誰產生。客戶端負責下載訂閱、寫入設定並啟動核心；核心負責 DNS、規則比對、代理連線與 TUN 流量處理。訂閱下載失敗時，修改代理規則通常沒有作用；核心根本沒有啟動時，測試節點延遲也不會得到有效結果。

三類紀錄的關注重點

• 客戶端紀錄：常見內容包括訂閱 URL 請求、設定檔儲存、核心程序啟動與系統代理切換。出現 HTTP 401、403、404 或設定寫入失敗時，先檢查訂閱與檔案權限。
• 核心啟動紀錄：會顯示設定載入、DNS 模組、監聽連接埠、規則集與 TUN 初始化狀態。這裡的錯誤通常會導致核心停止，或讓某項功能無法使用。
• 連線紀錄：包含 TCP、UDP、來源位址、目標網域、命中規則與最終策略群組。網頁無法開啟、應用程式繞過代理或節點逾時時，主要查看這一類。

不同客戶端的選單名稱可能略有差異。一般可從「設定」→「日誌」或「核心」→「日誌」開啟即時紀錄；部分桌面客戶端則將入口放在「首頁」→「日誌」。mihomo 圖形客戶端通常還能在「設定」→「參數設定」中調整日誌層級。重現問題時保持日誌頁面開啟，清除舊紀錄後只執行一次失敗操作，取得的樣本最容易閱讀。

讀懂層級、連線方向與規則結果

常見日誌層級包括 debug、info、warning 與 error。info 記錄正常連線，不代表發生故障；warning 表示操作失敗、回退或暫時異常，但核心通常仍在執行；error 更值得優先檢查。排查規則時可暫時使用 debug，完成後改回 info，避免大量 DNS 與連線細節持續寫入日誌。

[INFO] [TCP] 127.0.0.1:53142 --> example.com:443
match DomainSuffix(example.com) using Proxy[HK-01]

[WARNING] [TCP] dial Proxy (match DomainSuffix/example.com)
127.0.0.1:53142 --> example.com:443 error: i/o timeout

第一行表示本機程序從暫時連接埠 53142 發起 TCP 連線，目標為 example.com:443。接著命中 DOMAIN-SUFFIX 規則，並交由名為 Proxy 的策略群組處理；方括號中的 HK-01 是該群組實際選用的節點。第二段表示連線已進入代理鏈路，但未在規定時間內完成。因此可先排除「規則未命中」，將注意力轉向節點、上游網路或目標網站。

查看日誌時依此順序拆解

1. 確認通訊協定是 TCP 還是 UDP。HTTPS 網頁多數使用 TCP 443，也可能透過 QUIC 使用 UDP 443。
2. 確認來源位址。127.0.0.1 通常代表系統代理或本機應用程式；啟用 TUN 接管時可能會顯示虛擬網卡位址。
3. 確認目標是網域還是 IP。只有 IP 時，部分網域規則無法參與比對。
4. 查看 match 後的規則類型與規則內容。
5. 查看 using 後的策略群組與實際節點，判斷連線最後前往何處。
6. 最後閱讀 error 內容，區分連線逾時、遭拒、解析失敗或驗證失敗。

dial tcp timeout：連線未能在期限內建立

dial tcp 表示核心正在建立 TCP 連線。後面的 i/o timeout、connect: operation timed out 或 context deadline exceeded 都表示「等待超過期限」，但逾時位置不一定相同。可能是連不上代理伺服器，也可能是代理伺服器無法連線至目標網站。需結合錯誤前方的節點名稱、目標位址與連續失敗範圍判斷。

只有一個節點逾時

若同一策略群組中的 HK-01 連續逾時，而 SG-02 能正常開啟相同網站，問題集中在節點或節點線路。先在客戶端執行一次延遲測試，再用實際網頁驗證。延遲測試 URL 回傳 200 只能表示測試鏈路可達，不代表所有目標都能存取。連續 3 次出現超過 5 秒的逾時，比單次 800 毫秒更能說明連線不穩定。

所有節點同時逾時

• 檢查目前網路是否能直接連線至訂閱網站以外的一般網頁，排除本機斷網。
• 確認系統時間準確。時間相差數分鐘可能影響 TLS 交握與帶時間戳記的驗證協定。
• 檢查節點伺服器位址是否能解析。若日誌同時出現 lookup 或 DNS request failed，應先處理 DNS。
• 暫時關閉系統中的其他 VPN、代理軟體或網路過濾工具，避免路由彼此覆蓋。
• 若已啟用 TUN，先改用系統代理重新測試。系統代理可用而 TUN 不可用時，重點檢查虛擬網卡、路由與權限。

[WARNING] dial tcp 203.0.113.20:443: i/o timeout
[WARNING] dial tcp: lookup node.example.net: i/o timeout

這兩行不能用同一種方式處理。第一行已取得伺服器 IP，逾時發生在 TCP 連線階段；第二行仍停留在網域解析階段。前者檢查伺服器連接埠與網路路徑，後者檢查 DNS 伺服器、DNS 路由與本機網路。

connection refused：目標明確拒絕連線

connection refused 與逾時不同。逾時表示遲遲沒有收到有效回應；拒絕連線表示目標主機很快回傳拒絕結果。常見原因包括連接埠沒有服務監聽、服務已停止、連接埠填寫錯誤，或本機應用程式連線至尚未啟動的 Clash 監聽連接埠。

dial tcp 127.0.0.1:7890: connect: connection refused
dial tcp 198.51.100.8:8443: connect: connection refused

第一行目標是 127.0.0.1:7890，表示某個應用程式嘗試連線至本機代理連接埠，但該連接埠沒有程序監聽。檢查客戶端核心狀態，並確認應用程式代理位址與 Clash 設定一致。常見混合代理連接埠是 7890，但使用者設定可能改為 7897、7899 或其他值，不能只照預設值填寫。

第二行是遠端位址拒絕連線。若它對應節點伺服器，應核對節點連接埠、協定類型與訂閱更新時間。將 VMess 節點連接埠誤填至 Trojan 設定，或伺服器更換連接埠後仍使用舊訂閱，都可能立即遭拒。此時反覆切換規則模式沒有作用，因為錯誤發生在連線至代理伺服器的階段。

DNS 解析失敗：先確認請求由誰處理

DNS 問題常表現為網頁顯示找不到伺服器，日誌中出現 lookup、no such host、all DNS requests failed、could not resolve 或上游 DNS 逾時。排查重點是確認 DNS 請求是由作業系統、Clash DNS 模組，還是瀏覽器自己的安全 DNS 處理。三者並行時，修改其中一項不一定會影響實際請求。

檢查核心 DNS 設定

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
  fallback:
    - tls://1.1.1.1:853

這段設定讓核心在 1053 連接埠監聽 DNS，請求不會自動出現在系統的 53 連接埠上。圖形客戶端通常會在啟用 TUN 或 DNS 接管時加入相應路由。若只複製設定，卻沒有讓系統 DNS 指向核心，應用程式仍可能使用原本的解析器。相反地，若連接埠已被其他程式佔用，啟動日誌會出現 bind: address already in use。

依現象區分處理方向

• 所有網域都失敗，但直接存取 IP 有回應：優先檢查 DNS 監聽、上游 DNS 與防火牆。
• 中國大陸網域正常，特定網域失敗：檢查 nameserver-policy、fallback 與規則集是否將 DNS 請求送往無法連線的鏈路。
• 瀏覽器失敗，其他應用程式正常：檢查瀏覽器的安全 DNS 設定與代理擴充功能，確認它是否繞過系統 DNS。
• 出現 Fake-IP 位址但連線失敗：Fake-IP 回傳保留位址屬於正常流程，應繼續檢查後續網域還原、規則命中與代理連線，而不是將保留位址當成真實伺服器。
• 啟用 TUN 後才失敗：檢查 DNS 劫持設定、預設路由與虛擬網卡權限，避免 DNS 請求被循環送回核心。

修改 DNS 後，應清除舊快取再測試。Windows 可重新連線網路，或在終端機執行 ipconfig /flushdns；macOS 可關閉再重新開啟網路介面。瀏覽器也可能保留自己的 DNS 與連線快取，完全退出瀏覽器後重新測試會更可靠。

規則未命中：日誌可能沒有 error

規則分流錯誤通常不會產生紅色錯誤訊息。連線成功，但經由 DIRECT、錯誤節點或最終的 MATCH，使用者仍會覺得「規則失效」。Clash 與 mihomo 會依設定中的順序由上而下檢查，命中第一條後停止。範圍較大的規則放在前面，會遮蔽後方的精確規則。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN,api.example.com,Proxy
  - MATCH,Proxy

存取 api.example.com 時，第一條 DOMAIN-SUFFIX 已經命中，因此第二條精確網域規則不會執行。若希望 API 經由代理，應將 DOMAIN,api.example.com,Proxy 移到更前面。若日誌顯示 match DomainSuffix(example.com) using DIRECT，表示規則系統正常運作，問題在規則順序，而不是核心忽略設定。

日誌只顯示 IP 時如何排查

目標顯示為 142.250.0.1:443 這類 IP 時，DOMAIN 與 DOMAIN-SUFFIX 規則可能沒有可用網域。原因包括應用程式直接連線 IP、DNS 對映未與連線關聯，或流量沒有完整經過核心。可查看是否命中 IP-CIDR、GEOIP 或最終 MATCH。使用 no-resolve 的 IP 規則不會為了比對而額外解析網域，它並不是「跳過這條規則」。

規則集載入失敗

遠端規則集無法下載時，日誌可能出現 HTTP 404、context deadline exceeded 或 provider update failed。先檢查規則集 URL 與更新時間，再確認下載請求使用的策略。規則集首次載入失敗可能使依賴它的規則無法使用；已有快取時，核心可能繼續使用舊版本。排查時應記錄失敗發生在啟動階段還是定時更新階段。

訂閱、設定與核心啟動錯誤

如果日誌中完全沒有 TCP 或 UDP 連線紀錄，先確認核心是否成功載入設定。YAML 縮排錯誤、策略群組引用不存在的節點、連接埠衝突與設定欄位不相容，都可能讓核心在接管流量前退出。

HTTP 狀態碼對應的訂閱問題

YAML 與引用錯誤

yaml: line 42: did not find expected key
proxy group Proxy: proxy HK-01 not found
listen tcp 127.0.0.1:7890: bind: address already in use

• did not find expected key 通常與縮排、缺少冒號或引號未閉合有關。YAML 應使用空格縮排，不要混用定位字元。
• proxy not found 表示策略群組引用了不存在的節點或子策略群組。檢查名稱中的空格、大小寫，以及訂閱更新後節點是否更名。
• address already in use 表示監聽位址或連接埠已被佔用。退出舊核心程序，或在「設定」→「參數設定」中更換 mixed-port 後重新啟動。
• permission denied 出現在 TUN 初始化階段時，通常與虛擬網卡權限或系統服務狀態有關。系統代理可正常使用時，可先維持系統代理模式，再單獨處理 TUN。

Clash Premium、Clash Meta 與 mihomo 支援的設定欄位並不完全相同。設定由較新的 mihomo 產生，卻交由舊核心載入時，可能出現 unknown field 或解析失敗。先在客戶端的「關於」或「核心」頁面確認實際核心名稱與版本，再對照該核心支援的欄位，不要只看客戶端外殼版本。

一套可重現的日誌排查流程

1. 記錄現象：寫下失敗時間、應用程式名稱、目標網域，以及是否啟用系統代理或 TUN。
2. 確認核心狀態：檢查核心是否正在執行、mixed-port 是否監聽，以及啟動日誌是否有設定錯誤。
3. 清除日誌：將層級設為 info，清除歷史紀錄，避免舊錯誤干擾判斷。
4. 只重現一次：開啟一個失敗頁面、重新整理一次訂閱，或執行一次節點連線，不要同時操作多個應用程式。
5. 先找目標：搜尋網域、IP 或訂閱位址，再向前後查看 10 至 20 行上下文。
6. 劃分環節：訂閱 HTTP 錯誤歸入訂閱環節；YAML 與連接埠錯誤歸入啟動環節；lookup 歸入 DNS；match 歸入規則；dial 歸入連線。
7. 進行單一變因測試：一次只更換一個節點、一個 DNS 上游或一種接管模式。每次修改後重新清除日誌。
8. 恢復日誌層級：問題處理完成後，將 debug 改回 info，減少無關紀錄。

例如，某網站在 TUN 模式下 8 秒後失敗，但在系統代理模式下可於 1.2 秒內開啟。日誌顯示規則都命中同一節點，系統代理模式能完成 TCP 連線，TUN 模式卻沒有對應的目標紀錄。此時節點與規則已大致排除，檢查重點應轉向 TUN 路由、應用程式是否經由虛擬網卡、DNS 劫持與系統權限。這種對照測試比連續更換十個節點更有效。

向他人提供日誌前，可以保留時間、錯誤類型、目標連接埠、規則類型與策略群組名稱，同時遮蔽訂閱權杖、驗證欄位、完整節點位址與本機使用者名稱。不要只截取最後一行 error；至少保留錯誤前後的啟動資訊或連線上下文，否則很難判斷逾時發生在 DNS、節點還是目標網站。