Clash 執行日誌怎麼看：常見錯誤訊息與問題定位方法

先確認查看的是哪一種日誌

Clash 客戶端通常同時包含圖形介面與代理核心。介面負責匯入設定、切換節點和修改設定，Clash Meta（mihomo）等核心則負責監聽連接埠、解析 DNS、比對規則並建立連線。排查網路問題時，真正有參考價值的通常是核心執行日誌，而不是安裝記錄或介面當機報告。

一筆典型日誌會提供時間、層級、連線來源、目標位址、命中的規則和最終出口。不同客戶端的排版略有差異，但資訊含義基本一致。例如：

2026-06-02 14:32:18 INFO [TCP] 127.0.0.1:51842
--> api.example.com:443
match DomainSuffix(example.com) using Proxy[Node-A]

這筆記錄表示：本機連接埠 51842 發起了 TCP 連線，目標是 api.example.com:443，設定中的 DOMAIN-SUFFIX,example.com 規則命中，連線最後交由名為 Proxy 的策略群組處理，群組內實際使用的是 Node-A。這能證明流量已進入 Clash，也能說明規則與出口選擇結果，但無法單獨證明目標網站已回傳正常內容。

介面日誌與核心日誌的差異

• 核心日誌：包含 TCP、UDP、DNS、規則比對、代理握手和 TUN 入站資訊，是排查連線問題的主要依據。
• 介面日誌：記錄設定儲存、系統匣操作、視窗載入、更新檢查等事件，適合排查客戶端無法啟動或按鈕沒有反應。
• 服務日誌：部分 Windows 客戶端會安裝系統服務，用於接管 TUN 或提升權限。服務啟動失敗時，應一併查看服務日誌。
• 訂閱更新記錄：用於判斷遠端設定請求是否回傳 200、401、403、404 或逾時，不等同於日常代理連線日誌。

怎麼選擇日誌層級

Clash 設定中的 log-level 控制核心輸出的資訊量。mihomo 1.19.x 常用層級包括 silent、error、warning、info 和 debug。部分圖形客戶端會將 warning 簡寫為 Warn，或將層級放在「核心設定」中。

多數問題先使用 Info 即可。Debug 的記錄量可能在幾分鐘內增加到數千行，瀏覽器背景連線還會掩蓋真正失敗的請求。建議只在重現前開啟，完成一次測試後立即恢復為 Info。

直接編輯 YAML 時，可在頂層設定：

log-level: info

以 Clash Verge Rev 2.3.x 為例，可先開啟「設定」→「Clash 設定」→「日誌層級」，選擇 Info；查看記錄時進入「日誌」。不同小版本可能將入口標示為「核心日誌」或「執行日誌」。如果介面修改後沒有生效，請檢查目前設定是否由訂閱管理，以及客戶端是否在切換設定後覆蓋了本機參數。

從一筆記錄拆解連線路徑

閱讀日誌時不要只搜尋紅色的 Error。許多網頁無法開啟的問題會以一般 Info 記錄出現，因為核心已成功接收請求，只是在後續撥號階段逾時。更有效的方法是依序閱讀「入站、目標、規則、策略、結果」五項。

1. 入站來源：確認請求來自 HTTP、SOCKS、Mixed 或 TUN。常見的本機監聽位址是 127.0.0.1，Mixed 連接埠通常設為 7890。
2. 目標位址：查看目標是網域名稱還是 IP，以及連接埠是否為 80、443、53 或應用程式自訂的連接埠。
3. 規則命中：辨識 Domain、DomainSuffix、GeoIP、IPCIDR、RuleSet 或最後的 Match。
4. 策略出口：確認流量是走 DIRECT、REJECT，還是進入某個代理群組及指定節點。
5. 連線結果：繼續查看同一時間附近是否出現 timeout、refused、TLS、DNS 或 EOF。

如何判斷系統代理沒有接管流量

清除日誌後造訪一個之前未開啟過的網站。如果日誌完全沒有新增 TCP 或 UDP 連線，問題通常發生在請求進入核心之前。先檢查系統代理是否已開啟，再確認應用程式是否繞過系統代理。Windows 可在「設定」→「網路和 Internet」→「代理」中查看手動代理狀態；常見 HTTP 代理位址為 127.0.0.1:7890，實際連接埠以客戶端顯示為準。

如果瀏覽器使用獨立的代理擴充功能，擴充功能中的連接埠也必須與 Clash 目前監聽的連接埠一致。日誌沒有內容時反覆更換節點通常沒有意義，因為節點根本沒有收到請求。使用 TUN 模式時，還應確認日誌中能看到 TUN 入站啟動記錄，並檢查虛擬網卡是否已建立。

如何判斷規則命中錯誤

目標出現在日誌中，但出口與預期不同時，應將注意力放在 match 後面的規則上。例如目標本應走代理，卻顯示：

INFO [TCP] 198.18.0.1:42116 --> service.example.com:443
match GeoIP(CN) using DIRECT

198.18.0.1 可能是 Fake-IP 對映位址，不代表真實伺服器位於該位址。重點是最後命中了 GeoIP 並走 DIRECT。如果網域規則應優先命中，請檢查規則順序、規則集是否成功載入，以及網域是否過早解析成 IP。Clash 會按照由上到下的順序比對規則，命中第一條後不會繼續檢查後續規則。

常見錯誤分別代表什麼

i/o timeout 與 context deadline exceeded

這兩類訊息都指向逾時，但發生逾時的位置可能不同。連線至節點位址逾時，常見原因是節點離線、連接埠無法連通、網路遭封鎖或 UDP 不通；連線至目標網站逾時，則可能是節點到目標之間的鏈路異常。先查看錯誤中的位址：如果是節點伺服器 IP 和節點連接埠，應切換至另一個已通過延遲測試的節點；如果是目標網域的 443 連接埠，應比較 DIRECT 與代理出口。

延遲測試顯示 80 ms，不代表節點一定可用。部分測試只會存取固定 URL，實際網站還涉及 DNS、TLS 和目標伺服器策略。可連續測試三次；如果結果在 80 ms、450 ms 和逾時之間劇烈波動，代表節點鏈路本身不穩定。

connection refused

connect: connection refused 表示目標主機明確拒絕連線，通常會比逾時更快回應。如果被拒絕的是 127.0.0.1:7890，表示應用程式正在連線至本機代理連接埠，但該連接埠沒有程序監聽，可能是核心尚未啟動或連接埠已變更。如果被拒絕的是遠端節點連接埠，常見情況是伺服器程序停止、連接埠變更或訂閱中的節點資訊已過期。

Windows 可執行 netstat -ano | findstr 7890 查看連接埠；macOS 或 Linux 可執行 lsof -i :7890。如果沒有 LISTEN 記錄，請先恢復核心運作，不必繼續檢查規則。

no such host、server misbehaving 與 DNS 逾時

no such host 通常表示網域名稱沒有取得可用的解析結果。原因可能是網域拼寫錯誤、上游 DNS 回傳 NXDOMAIN，或 Clash 無法存取設定中的 nameserver。server misbehaving 常見於 DNS 上游回傳異常或請求流程中斷。如果日誌同時出現 lookup、exchange failed、deadline exceeded，應優先排查 DNS，而不是節點或規則。

可先確認設定中的 DNS 開關和監聽位址，例如：

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

這裡的 1053 是 Clash DNS 的監聽連接埠，不是瀏覽器代理連接埠。如果系統或其他程式需要向該連接埠傳送 DNS 請求，還要確保連接埠未被占用。使用 DoH 時，也應考慮 DoH 網域本身的首次解析問題；必要時透過 default-nameserver 提供可直接存取的 IP 型 DNS。

TLS handshake timeout 與憑證相關訊息

TLS handshake timeout 表示 TCP 連線可能已建立，但 TLS 握手未能在限定時間內完成。原因可能是節點品質、目標網站回應緩慢、中間網路丟包或系統時間異常。先核對系統日期、時區和自動校時，再更換節點重測。如果只有一個網域失敗，問題更可能集中在目標網站或該網域的路由。

x509、certificate signed by unknown authority 或網域不相符，都屬於憑證驗證失敗。不要直接關閉憑證驗證作為長期處理方式。應檢查系統時間、本機封包擷取軟體、企業網路憑證和節點回傳內容，確認連線是否被重新導向至錯誤伺服器。

EOF、connection reset by peer 與 broken pipe

EOF 表示資料流提前結束，單獨出現一次不一定代表故障，瀏覽器取消請求也可能產生 EOF。connection reset by peer 表示遠端主動重設連線；broken pipe 表示本機繼續寫入時，對端連線已經關閉。如果這些記錄只在關閉頁面時出現，可以忽略；如果每次造訪都在 1 至 2 秒內重複出現，應更換節點、關閉 QUIC 後重試，並檢查目標是否限制目前的出口 IP。

按現象定位節點、規則與 DNS

節點延遲正常，但網頁無法開啟

1. 將日誌層級設為 Info，清除現有記錄。
2. 只造訪一個 HTTPS 網站，記下目標網域和操作時間。
3. 確認日誌出現目標網域，並查看實際使用的策略群組和節點。
4. 搜尋同一分鐘內的 timeout、TLS、reset 和 EOF。
5. 固定使用同一條規則，改用另一個節點重測，避免同時修改多個變數。
6. 如果所有節點都失敗，再切換至 DIRECT 比較，並檢查 DNS 解析結果。

如果更換節點後立即恢復，問題集中在原節點或其上游線路。如果所有節點都在解析階段失敗，應優先檢查 DNS。如果日誌顯示 DIRECT，但預期是代理，則處理規則順序或策略群組選擇。

只有某個應用程式無法連線

瀏覽器正常而某個應用程式完全沒有產生日誌，通常表示該應用程式沒有使用系統代理。部分遊戲、命令列工具和商店應用程式會直接建立連線，此時可啟用 TUN 模式接管更多流量。啟用後應檢查 TUN 裝置是否啟動、路由是否寫入，以及是否出現權限錯誤。

如果應用程式能產生日誌但 UDP 持續失敗，請確認所選節點是否支援 UDP，並查看策略群組是否允許 UDP。TUN 的 MTU 也可能影響特定網路；預設值出現分片問題時，可依客戶端支援範圍從 1500 調整至 1400 進行一次比較測試，但沒有明確現象依據時，不應頻繁修改。

規則模式未生效，切換全域模式卻正常

這類情況通常與規則命中有關。全域模式會繞過大部分規則判斷，直接使用選定的代理群組，因此能證明節點至少具備基本連線能力。切回規則模式後，搜尋目標網域並查看命中項目。如果落到 MATCH,DIRECT，應檢查末尾規則；如果命中過期規則集，則查看規則提供者是否下載失敗。

規則集載入問題常伴隨 HTTP 404、403、逾時或 YAML 解析錯誤。修正遠端位址後，在客戶端執行「設定」→「更新」或對應的規則集更新操作，再確認日誌出現載入成功記錄。只修改策略群組名稱而不更新規則引用，會造成規則指向不存在的策略。

TUN 模式日誌還要額外看什麼

TUN 模式會在系統網路層接收流量，日誌中可能出現虛擬網卡、路由、DNS 劫持和介面選擇資訊。核心啟動後若沒有建立 TUN 裝置，常見原因包括權限不足、系統服務未執行、虛擬網卡衝突或其他 VPN 正在占用路由。

• 啟動時立即出現權限錯誤：檢查客戶端服務狀態，並依作業系統要求授予系統管理員權限。
• 啟動成功但整個網路中斷：檢查預設介面識別、DNS 劫持目標和路由寫入是否正常。
• 區域網路裝置無法存取：查看私有網段是否被錯誤送入代理，常見網段包括 192.168.0.0/16、10.0.0.0/8 和 172.16.0.0/12。
• 部分 UDP 應用程式異常：確認節點協定支援 UDP，並觀察是否出現逾時或網路無法連線。
• 退出後網路未恢復：先完全關閉核心，再檢查系統代理、DNS 和預設路由是否仍保留舊值。

整理一份可用的故障記錄

向設定提供者或客戶端專案回報時，完整螢幕截圖往往不如一段整理過的文字有效。建議保留核心版本、客戶端版本、作業系統、發生時間、代理模式、目標網域、命中策略和連續錯誤行。mihomo 核心版本可在客戶端的「關於」或「核心」頁面查看，例如 mihomo v1.19.x；客戶端版本也應精確到小版本。

提交前應刪除訂閱位址、驗證參數、節點伺服器憑證和區域網路裝置名稱。公開網路上的目標網域、錯誤類型和規則名稱通常需要保留，否則無法判斷請求在哪個步驟失敗。可依以下格式整理：

系統：Windows 11 24H2
客戶端：Clash Verge Rev 2.3.x
核心：mihomo 1.19.x
模式：Rule + TUN
發生時間：2026-06-02 14:32
現象：瀏覽器造訪目標網域持續逾時
命中：DomainSuffix → Proxy → Node-A
錯誤：dial tcp 203.0.113.10:443: i/o timeout
比較：切換 Node-B 後連線恢復

這份記錄已能將範圍縮小至 Node-A 或其鏈路，不需要附上數分鐘的全部背景連線。如果問題與 DNS 有關，再補充 nameserver 類型、Fake-IP 或 Redir-Host 模式，以及查詢失敗訊息即可。

日誌排查順序總結

穩定的排查順序是：先確認流量是否進入 Clash，再確認目標和連接埠，接著查看命中的規則、策略群組與實際節點，最後讀取緊接著出現的錯誤。日誌為空時檢查系統代理或 TUN 接管；出口錯誤時檢查規則；出現 lookup 或 no such host 時檢查 DNS；出現 timeout、refused、TLS 和 reset 時，再判斷節點或遠端鏈路。

Info 層級適合大多數情境，Debug 只在缺少關鍵細節時短時間開啟。完成重現後恢復原本設定，並保留一份精簡、附有時間和版本資訊的日誌。如此可避免憑感覺反覆更換設定，也能更快判斷問題位於客戶端、規則、DNS、節點還是目標網站。