Clash 執行日誌怎麼看：常見錯誤含義與排查步驟

先判斷日誌記錄的是哪一段連線

Clash、Clash Meta（mihomo）及其圖形化客戶端通常會同時處理系統代理、DNS、規則比對、節點連線、TUN 轉發與訂閱更新。日誌出現 error，不代表整個客戶端已停止運作；一條連線失敗，也不代表目前節點完全無法使用。排查時應先確認錯誤屬於哪一層，再處理相應設定。

一筆常見的連線日誌通常包含時間、日誌層級、入站類型、目標位址、比對規則、策略群組、實際節點與錯誤文字。不同客戶端的排列方式略有差異，但核心資訊相同。例如：

20:14:08 INF [TCP] 127.0.0.1:53142
--> api.example.com:443
match DomainSuffix(example.com)
using Proxy[HK-01]

20:14:13 ERR dial HK-01
198.51.100.20:443
dial tcp 198.51.100.20:443: i/o timeout

這筆記錄表示：本機程式從 127.0.0.1 發起 TCP 請求，目標是 api.example.com:443；網域符合一條後綴規則，策略群組選用了 HK-01；之後 Clash 連線至節點伺服器 198.51.100.20:443 時逾時。問題發生在「本機到節點伺服器」這一段，而不是目標網站主動拒絕存取。

閱讀日誌時固定擷取五項資訊

1. 時間點：錯誤是否與剛才的操作相符。先重現一次，再查看同一分鐘內的記錄。
2. 協定與入站：TCP、UDP、HTTP、SOCKS 或 TUN。部分問題只會影響 UDP，網頁仍可能正常開啟。
3. 目標位址：確認日誌中的網域或 IP 是節點伺服器、訂閱位址、DNS 伺服器，還是最終網站。
4. 規則與策略：檢查連線符合哪一條規則，以及策略群組最後選擇的是 DIRECT、REJECT 還是特定節點。
5. 錯誤結尾：Go 網路錯誤通常會在最後列出最具體的原因，例如 i/o timeout、connection refused 或 no such host。

info、warning、error 分別代表什麼

日誌層級描述的是事件嚴重程度，不等同於處理優先順序。背景健康檢查產生的 error 可能只影響一個備用節點；一筆 info 層級的規則記錄，卻可能直接表示目前網站遭 REJECT 規則攔截。應將層級與目標位址、策略結果一併閱讀。

正常日誌中也可能出現失敗記錄

瀏覽器可能同時嘗試 IPv4、IPv6、HTTP/3 與一般 HTTPS。某一路連線失敗後，瀏覽器可能立即切換至另一條路徑，因此頁面仍能開啟。節點健康檢查也會定期存取測試位址；某個節點逾時只表示該次檢查未完成，不代表目前使用的節點中斷。

要判斷是否需要處理，可以觀察三個訊號：相同錯誤是否持續出現；錯誤對應的目標是否正是無法存取的服務；切換節點或關閉某項功能後，錯誤是否立即消失。只出現一次且沒有明顯影響的背景錯誤，可以先記錄，不必同時修改多個設定項目。

dial tcp timeout：連線未能在指定時間內完成

dial tcp ...: i/o timeout 表示 TCP 連線未能在逾時時間內建立。若錯誤中的位址是節點伺服器 IP，優先檢查本機到節點的網路；若位址是最終網站，則檢查代理節點到目標網站的路徑。逾時與「明確拒絕連接埠」不同：遠端未在指定時間內回傳可用回應。

常見原因

• 節點伺服器暫時離線，或節點連接埠已變更。
• 目前的 Wi-Fi、行動網路或上游路由無法連至該伺服器。
• 防火牆捨棄了特定連接埠的流量。
• IPv6 路由無法使用，但節點網域優先解析至 AAAA 記錄。
• TUN 介面路由形成迴圈，節點連線又被送回 Clash。
• 節點可以連線，但 TLS 交握或後續傳輸持續逾時。

依序執行四次對照測試

1. 在客戶端節點清單中切換至另一個節點，再重複相同請求。若新節點正常，問題集中在原節點或原節點線路。
2. 切換網路，例如從家用 Wi-Fi 改用手機熱點。若同一節點恢復正常，請檢查路由器、防火牆與目前電信商線路。
3. 暫時關閉 TUN，只保留系統代理，再存取相同位址。若系統代理正常而 TUN 逾時，應重點檢查路由、DNS 劫持與介面選擇。
4. 查看逾時位址。節點 IP 逾時與目標網域逾時是兩條不同路徑，不要只根據網頁名稱判斷。

Clash 常見的本機代理連接埠包括 HTTP 連接埠 7890、SOCKS 連接埠 7891，也可以統一使用 mixed-port: 7890。這些數字都可以修改。排查前應在客戶端「設定」→「連接埠設定」或「設定」→「參數設定」中確認實際值，並核對系統代理是否使用相同連接埠。

connection refused：位址可達，但連接埠拒絕連線

connect: connection refused 或 dial tcp ...: connect: connection refused 通常表示資料已抵達目標主機，但指定連接埠沒有服務監聽，或防火牆主動回傳拒絕。它通常會比 timeout 更快出現。

ERR dial tcp 127.0.0.1:7890:
connect: connection refused

ERR dial tcp 203.0.113.8:443:
connect: connection refused

第一條指向 127.0.0.1:7890，表示本機應用程式嘗試連線至本地代理連接埠，但該連接埠沒有可用的監聽服務。可能是 Clash 核心尚未啟動、連接埠已改成其他數值，或客戶端只啟用了 SOCKS 連接埠。第二條指向遠端 IP，通常是節點連接埠設定錯誤、節點服務停止，或伺服器防火牆主動拒絕。

本地連接埠拒絕時檢查這些位置

• 確認客戶端狀態頁顯示核心正在執行，而不是停留在啟動失敗狀態。
• 進入「設定」→「連接埠設定」，核對 HTTP、SOCKS 與 Mixed Port 的實際數值。
• 在瀏覽器或應用程式的手動代理設定中，將位址設為 127.0.0.1，連接埠與 Clash 目前的監聽值保持一致。
• 如果設定使用 mixed-port: 7890，HTTP 與 SOCKS 客戶端都能連線至該連接埠；不要再假定 7891 一定已啟用。
• 檢查日誌前段是否出現 bind: address already in use。這表示連接埠已被其他程序佔用，核心無法進行監聽。

遠端連接埠拒絕時怎麼處理

先更新訂閱，再確認節點伺服器位址與連接埠是否變更。若只有一個節點報錯，直接切換節點並記錄故障項目；若同一訂閱中的所有節點都遭拒絕，應檢查訂閱是否已過期、設定是否仍指向舊伺服器，以及網路是否經由透明閘道改寫連線。

DNS 解析失敗：先區分網域問題與連線問題

常見 DNS 錯誤包括 no such host、DNS request failed、server misbehaving、context deadline exceeded。DNS 失敗發生在將網域轉換為 IP 的階段。若日誌已顯示正在連線至明確的 IP，例如 198.51.100.20:443，後續的 timeout 通常不是該次連線的網域解析失敗。

三類 DNS 故障要分開處理

mihomo 的 DNS 設定可以區分用於解析節點網域的預設伺服器，以及處理一般查詢的 nameserver。以下是用來理解結構的精簡範例，實際位址應依目前網路環境調整：

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query

default-nameserver 使用 IP 位址，主要用於解析 DoH 伺服器或代理節點本身的網域，避免「解析 DNS 伺服器前還要先解析 DNS 伺服器」的依賴循環。listen: 0.0.0.0:1053 是 Clash 的 DNS 監聽位址，不代表系統會自動將所有查詢傳送至該連接埠；TUN 模式通常還需要 DNS 劫持設定。

Fake-IP 模式下的特殊現象

Fake-IP 會向應用程式回傳對應位址，並在 Clash 內部保留原始網域，以便進行規則比對。日誌中看到 198.18.0.0/16 範圍的位址，通常是對應結果，不應將其視為真實網站伺服器。若某個區域網路裝置、遊戲或企業應用程式不相容於 Fake-IP，可以針對網域設定過濾，或對照測試 redir-host 模式；不要只因出現對應位址就判定 DNS 損壞。

TLS、EOF 與 context deadline exceeded 怎麼看

TLS handshake timeout

TLS handshake timeout 表示 TCP 可能已建立，但 TLS 交握未能在時限內完成。常見原因包括線路丟包、節點負載過高、中間設備干擾與 MTU 不合適。先切換節點與網路；若只在 TUN 下出現，可將 MTU 從常見的 1500 對照調整為 1400 或 1280，逐一測試。不要一次同時修改 MTU、DNS 與代理協定，否則無法判斷是哪項設定產生效果。

x509 certificate 錯誤

x509: certificate has expired 表示憑證已過期；x509: certificate is valid for ... 表示憑證網域與連線目標不相符；certificate signed by unknown authority 表示目前環境不信任該憑證鏈。首先確認系統日期、時間與時區正確，再檢查節點網域、SNI 或 server name 設定。任意關閉憑證驗證會掩蓋設定錯誤，不適合作為長期處理方式。

EOF 與 unexpected EOF

EOF 表示連線對端結束了資料流。單次 EOF 可能是服務正常中斷；如果每次請求都在同一階段出現，通常需要檢查協定參數、節點服務狀態或中間網路設備。unexpected EOF 更強調連線在預期完成資料讀取前中斷，切換節點是最快的對照方法。

context deadline exceeded

這是通用的操作逾時提示，單獨查看無法確定發生在 DNS、節點撥號、健康檢查還是訂閱下載。應查看同一行前面的操作名稱，以及前後 5 至 10 行日誌。如果它緊接在 proxy provider 後面，問題多半是訂閱或 provider 更新逾時；如果緊接在 DNS 請求後面，則檢查上游 DNS；如果出現在節點位址後面，則按連線逾時處理。

連接埠佔用、設定錯誤與核心啟動失敗

如果日誌視窗只有幾行，客戶端隨後停止執行，重點通常不是節點品質，而是核心未完成啟動。設定語法錯誤與監聽連接埠衝突是最常見的兩類原因。

address already in use

listen tcp 127.0.0.1:7890:
bind: address already in use

這表示已有程序佔用 7890。可能是另一個代理客戶端、上次未正常退出的核心程序，或本機開發服務。先完全退出其他代理程式，再重啟客戶端；若仍發生衝突，可在「設定」→「連接埠設定」中暫時將 Mixed Port 改為 7892，同時把系統代理連接埠改為相同數值。只修改 Clash 連接埠而不更新系統代理，會導致瀏覽器繼續存取舊連接埠並出現 connection refused。

設定解析錯誤

YAML 對縮排與資料類型十分敏感。日誌可能顯示具體行號，例如 yaml: line 42: did not find expected key。先檢查該行及上一行，確認縮排使用空格、冒號後有空格、列表項目以 - 開頭。策略群組引用的節點名稱也必須與實際名稱一致。

mixed-port: 7890
mode: rule

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - HK-01
      - DIRECT

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

如果更新訂閱後立即啟動失敗，先在客戶端「設定」→「設定檔」切換回上一份可用設定，再對新設定執行語法檢查。不要直接在有未知問題的設定上連續修改十幾處。每次只修改一項，儲存、重新載入並觀察第一筆 error。

TUN 模式日誌的排查重點

TUN 模式接管的流量範圍比系統代理更廣，因此會暴露 UDP、區域網路、系統服務，以及不遵循代理設定的應用程式連線。啟用 TUN 後日誌數量明顯增加屬於正常現象，真正需要關注的是持續重試、路由迴圈、介面建立失敗與 DNS 劫持異常。

常見 TUN 問題

• operation not permitted：建立介面或修改路由所需的權限不足。請檢查客戶端權限與 TUN 服務安裝狀態。
• network is unreachable：目前路由表中沒有通往目標的可用路徑，常見於失效的 IPv6 或錯誤的介面選擇。
• device or resource busy：TUN 裝置正被另一個執行個體或其他 VPN 使用。
• 連線迴圈：節點伺服器流量再次進入 TUN，日誌中同一目標快速重複出現。請檢查自動路由、介面偵測與節點位址排除邏輯。
• UDP timeout：可能只影響遊戲、語音或 QUIC，不一定會影響一般 TCP 網頁。

系統代理與 TUN 的二分測試

1. 記錄目前設定，並確認規則模式、節點與 DNS 設定維持不變。
2. 關閉 TUN，只啟用系統代理，測試瀏覽器與訂閱更新。
3. 重新啟用 TUN，關閉系統代理，再測試相同目標。
4. 若只有 TUN 失敗，請查看介面權限、自動路由、MTU、DNS 劫持與其他 VPN。
5. 若兩種模式都失敗，回到節點、DNS、規則與本地連接埠繼續排查。

Android 上還要確認系統 VPN 權限沒有被另一款 VPN 應用程式佔用，並在系統「設定」→「應用程式」→「Clash 客戶端」→「電池」中，允許符合使用需求的背景執行策略。Windows 上出現 TUN 介面建立失敗時，應檢查客戶端的服務模式或管理員權限；macOS 上則需確認系統設定中的網路擴充功能授權狀態。

規則比對正確，但網站仍無法存取

日誌中出現 match、using 或規則名稱，只表示 Clash 已作出策略選擇，不代表後續連線成功。需要繼續查看同一連線之後是否出現 dial、TLS 或 DNS 錯誤。

先核對策略結果

• 命中 DIRECT：連線繞過代理。若目標需要透過節點存取，應檢查規則順序與網域比對方式。
• 命中 REJECT：Clash 依規則主動阻止連線。請檢查廣告過濾或自訂規則是否誤比對。
• 命中策略群組：繼續確認策略群組實際選中的節點，而不只是查看群組名稱。
• 命中 MATCH：前面的具體規則都未比對成功，連線進入最終兜底策略。

Clash 規則會依由上至下的順序比對，通常在第一次比對成功後停止繼續檢查。具體網域規則應放在寬泛規則之前，MATCH 應作為末尾兜底。例如：

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

如果 MATCH,DIRECT 被放在清單前段，後面的網域規則就不會按預期執行。修改後應重新載入設定，並在日誌中確認新連線命中了目標規則。已建立的舊連線可能繼續使用原有策略，測試時應關閉對應應用程式或等待舊連線結束。

一套可重複執行的日誌排查流程

有效排查依賴對照測試，而不是同時更換設定、節點、DNS 與網路。以下流程適用於網頁無法開啟、訂閱更新失敗、節點測速逾時與 TUN 無網路等常見問題。

1. 記錄環境：寫下客戶端版本、核心類型、目前網路、代理模式、是否啟用 TUN，以及實際監聽連接埠。
2. 清除日誌：進入「日誌」或「設定」→「日誌」，將層級設為 info；需要更詳細資訊時，再暫時切換至 debug。
3. 只重現一次：執行一個明確操作，並記住準確時間。
4. 找到目標：按網域、IP、連接埠或策略群組名稱篩選記錄。
5. 定位層級：判斷失敗發生在本地連接埠、DNS、規則、節點撥號、TLS、目標服務還是 TUN 路由。
6. 進行一次對照：只切換一個變數，例如節點、網路、TUN 狀態或 DNS 上游。
7. 驗證結果：再次清除日誌並重現問題，確認原始錯誤消失，且沒有轉變成新的錯誤。

提交日誌前需要整理哪些資訊

向客戶端維護者、訂閱提供方或網路管理員回報時，完整的環境資訊比一張「連線失敗」截圖更有價值。建議附上客戶端名稱與版本、mihomo 核心版本、作業系統版本、代理模式、TUN 狀態、故障發生時間、重現步驟與相關日誌片段。

日誌可能包含存取網域、節點名稱、伺服器 IP、本機區域網路位址與設定路徑。分享前應隱藏訂閱 URL、驗證資訊、使用者名稱、密碼與存取權杖。不要刪除錯誤前後的完整上下文；保留目標連線前後各 10 至 20 行，通常足以判斷規則選擇與失敗階段。

適合回報的簡要格式

客戶端：名稱與版本
核心：mihomo 版本
系統：系統名稱與版本
模式：Rule / TUN 已啟用
連接埠：mixed-port 7890
現象：瀏覽器存取指定網域逾時
時間：20:14:08
對照：切換節點後恢復
錯誤：dial tcp ...: i/o timeout

日誌排查的核心是先辨識連線階段，再進行單一變數對照。timeout 表示未能及時完成，refused 表示連接埠明確拒絕，DNS 錯誤發生在網域解析階段，規則日誌只代表策略選擇，TUN 錯誤則需要額外檢查權限與路由。沿著「本地應用程式 → Clash 入站 → DNS 與規則 → 節點 → 目標服務」的路徑逐段驗證，通常可以將問題縮小至一個可操作的設定項目或網路環節。