故障排除 預計閱讀 13 分鐘

Clash 執行日誌怎麼看：從 DNS 錯誤到連線逾時的排查思路

如何調整日誌層級、每行欄位代表什麼，以及 dial tcp timeout 與 dns resolve failed 分別指向哪些問題。整理常見錯誤訊息與排查順序，讓日誌真正協助你縮小故障範圍。

先確認日誌來自介面、核心還是作業系統

Clash 客戶端出現「連線失敗」時，介面通知通常只會顯示結果，真正能用來定位問題的是核心執行日誌。Clash Meta（現名 Mihomo）負責 DNS、規則比對、節點連線與 TUN 資料轉送；桌面客戶端則負責啟動核心、修改系統代理並顯示日誌。兩層元件可能各自回報錯誤，因此第一步不是搜尋某一行英文，而是確認錯誤發生在哪一層。

日誌來源 常見內容 優先檢查項目
客戶端介面日誌 核心啟動失敗、設定儲存失敗、服務模式安裝結果 客戶端權限、核心路徑、設定檔
Mihomo 核心執行日誌 DNS 查詢、規則命中、代理撥號、連線逾時 訂閱設定、節點、DNS 與網路出口
作業系統日誌 TUN 網卡建立失敗、連接埠被占用、權限遭拒 管理員權限、防火牆、既有程序

多數桌面客戶端都能直接從側欄的「日誌」頁面查看核心輸出。以常見的 Mihomo 桌面客戶端為例，可進入「設定」→「Clash 設定」→「日誌層級」，將層級從 info 暫時調整為 debug，再回到「日誌」頁面重現問題。不同客戶端的選單名稱略有差異，但設定檔中的標準欄位通常都是 log-level。

log-level: debug

重現問題時要保留完整時間線

不要只截取最後一則紅色錯誤訊息。一次連線通常會依序經過網域解析、規則比對、策略群組選擇、節點撥號與 TLS 交握，最後一行只代表流程停止的位置。建議先清除目前日誌，記下系統時間，再執行一次失敗操作，並保留錯誤前後至少 10 秒的內容。

  1. 關閉持續連網中的影片播放、同步與下載程式，減少無關日誌。
  2. 清除客戶端日誌，確認目前設定已成功載入。
  3. 只連線一個用於測試的網址，例如 https://example.com。
  4. 記錄存取時間、所選策略群組與節點名稱。
  5. 匯出或複製從 DNS 查詢開始到連線結束的完整片段。

一行 Clash 日誌應拆成哪些欄位

Mihomo 不同版本及客戶端封裝後的顯示格式可能有所差異，但核心資訊大致相同：時間、層級、網路類型、來源位址、目標位址、命中的規則，以及最後使用的出站策略。以下是一筆典型的 TCP 連線紀錄。

time="2026-07-27T14:32:18.412+08:00" level=info msg="[TCP] 127.0.0.1:53124 --> example.com:443 match DomainSuffix(example.com) using PROXY[HK-01]"

如果日誌顯示 using DIRECT，表示該連線被規則判定為直連；如果顯示 using REJECT，則表示設定主動拒絕請求。此時切換節點通常不會改變結果，應先檢查規則順序、規則集內容與目前執行模式。規則會由上而下比對，前面已命中的連線不會繼續檢查後面的規則。

info、warning、error 與 debug 怎麼看

層級 用途 是否一定代表故障
info 設定載入、建立連線、規則命中 否，主要用於還原流程
warning 重試、相容性回退、規則集更新異常 不一定，要看功能是否受到影響
error 撥號失敗、解析失敗、設定無法載入 通常需要處理
debug 更詳細的 DNS、連線與協定狀態 否，資訊量較大

DNS 錯誤：先區分上游失敗與本機監聽失敗

dns resolve failed、lookup failed 或 exchange failed 都表示網域解析鏈路未正常回傳結果，但原因可能完全不同。常見流程是：應用程式將查詢交給系統或 Mihomo，Mihomo 再存取設定中的 nameserver，取得結果後依 fake-ip 或 redir-host 模式處理。任何一段中斷，介面都可能只顯示「DNS 失敗」。

看到 timeout 時檢查上游 DNS

level=error msg="dns resolve failed: lookup example.com: i/o timeout"
level=warning msg="[DNS] exchange failed: context deadline exceeded"

i/o timeout 或 context deadline exceeded 表示請求在截止時間前未取得有效回應。先檢查設定中的 DNS 位址是否能從目前網路存取。若使用 DoH，還要確認其網域本身能由 default-nameserver 解析，否則可能形成「必須先解析 DoH 網域，但可用解析器正是該 DoH」的循環依賴。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

這段範例讓本機 DNS 在 127.0.0.1:1053 監聽，並為 DoH 網域準備基礎解析器。實際使用時應依所在網路調整上游位址；某個上游在另一個網路可連線，不代表在目前的 Wi-Fi、公司網路或行動熱點中也能穩定存取。

確認本機 DNS 連接埠是否確實在監聽

如果日誌出現 bind: address already in use，表示設定要求的監聽連接埠已被其他程序占用。連接埠 53 常由系統 DNS 服務使用，普通使用者程序在部分系統上也沒有繫結低號連接埠的權限。桌面環境可改用 1053，再由客戶端或 TUN 的 DNS 劫持功能接管查詢。

dig @127.0.0.1 -p 1053 example.com

nslookup example.com 127.0.0.1

dig 指令明確指定了 1053 連接埠，適用於已安裝相應工具的 macOS 或 Linux。Windows 內建的 nslookup 不便直接指定非 53 連接埠，因此更適合先檢查預設監聽；若設定使用 1053，可從客戶端日誌確認監聽成功，或使用連接埠檢測工具驗證。

dial tcp timeout：節點、網路還是目標網站

dial tcp timeout 表示 TCP 撥號階段未能在限定時間內完成。重點是查看它正要連線到哪裡：如果目標是代理伺服器的 IP 與連接埠，問題多半位於本機到節點之間；如果已經透過代理連線目標網站，則可能是節點出口、目標網站或規則選擇的問題。

level=error msg="dial tcp 203.0.113.20:443: i/o timeout"
level=error msg="connect failed: dial tcp: lookup node.example.net: i/o timeout"
level=error msg="dial tcp 127.0.0.1:7890: connect: connection refused"

使用本機代理連接埠進行一組可重複測試

假設設定中的 mixed-port 是 7890，可先確認連接埠，再讓命令列請求明確經過 Clash。以下請求將連線逾時設為 5 秒，總時限設為 15 秒，方便區分「立即拒絕」與「持續等待後逾時」。

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 5 \
  --max-time 15 \
  -I https://example.com

若指令在不到 1 秒內回傳 Connection refused，優先檢查核心程序與本機連接埠。若等待約 5 秒後出現連線逾時，本機連接埠通常已接收請求，故障更可能發生在節點撥號階段。若回傳 HTTP/2 200 或 HTTP/1.1 200 OK，表示該測試網址能透過目前代理建立連線，原應用程式的問題可能來自代理設定覆寫、QUIC、憑證或獨立 DNS。

Windows PowerShell 可先執行以下指令，檢查本機連接埠是否可連線：

Test-NetConnection 127.0.0.1 -Port 7890

看到 TcpTestSucceeded : True 只代表本機能連到 Clash 的監聽連接埠，不代表遠端節點可用。接下來仍需結合核心日誌中的策略群組、節點名稱與遠端錯誤繼續判斷。

connection refused 與 network unreachable 的差異

錯誤訊息 直接含義 優先處理方式
connection refused 目標主機明確拒絕連線，或本機沒有程序監聽 核對 IP、連接埠、核心程序與節點服務狀態
i/o timeout 在截止時間內未完成讀寫 測試網路出口，切換節點並比較耗時
network is unreachable 系統沒有可用路由前往目標網路 檢查網卡、IPv4/IPv6 路由與 TUN 狀態
TLS handshake timeout TCP 之後的 TLS 交握未能按時完成 檢查連線品質、時間、協定參數與中間網路
EOF 對端提前關閉連線 查看是否持續發生，並與其他節點比較

如何判斷 TUN 模式相關日誌

系統代理只會影響主動讀取代理設定的應用程式；TUN 模式則透過虛擬網卡接管更廣泛的流量。瀏覽器正常、遊戲或終端機失敗時，日誌中是否出現對應程序的連線紀錄非常關鍵：完全沒有紀錄，通常表示流量尚未進入 Mihomo；有規則命中但隨後撥號失敗，才屬於代理鏈路內部問題。

TUN 啟動階段常見錯誤包括 operation not permitted、failed to create tun device 與路由寫入失敗。它們通常指向權限、服務模式或虛擬網卡狀態。在 Windows 客戶端中可檢查「設定」→「服務模式」是否正常，再重新啟用 TUN；macOS 與 Linux 則需確認客戶端或核心具備建立虛擬介面與修改路由的權限。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-detect-interface 會讓 Mihomo 識別目前的預設出口。頻繁切換 Wi-Fi、有線網路、VPN 或行動熱點後，如果日誌仍顯示舊介面，可先關閉 TUN，等待系統路由穩定後再重新開啟。不要同時讓兩個網路工具寫入預設路由與 DNS 劫持規則，否則日誌可能交替出現介面無法連線與 DNS 逾時。

日誌沒有目標連線代表什麼

設定與訂閱錯誤應在啟動階段處理

如果核心未完成設定載入，後續 DNS 與節點測試都沒有意義。YAML 對縮排很敏感，列表項目、冒號與字串格式錯誤都可能導致啟動失敗。日誌中的 parse config error、yaml: line 42 或 mapping values are not allowed 通常會指出接近錯誤的位置，但真正問題也可能位於上一行。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Auto
      - DIRECT

同一層級要保持一致的空格，不要混用定位字元。名稱包含冒號、井號或其他 YAML 特殊字元時，請用引號包住。訂閱更新後若出現 provider not found、策略群組引用不存在或規則集載入失敗，應核對引用名稱是否與 proxy-providers、rule-providers 中的鍵完全一致，包括大小寫與空格。

HTTP 狀態碼有助於縮小訂閱更新問題範圍

一套從現象到結論的排查順序

日誌的價值不在於列出所有錯誤，而在於找出第一個偏離正常流程的位置。一次失敗可能同時產生 DNS 逾時、節點測速失敗與規則集更新失敗；如果本機已經斷網，三類錯誤只是同一根因的不同表現。依固定順序檢查，可以減少在無關設定之間反覆切換。

  1. 確認基礎網路：關閉系統代理與 TUN 後，測試目前網路能否存取允許直連的本機網站。
  2. 確認設定載入：查看啟動階段是否出現 YAML 解析、連接埠占用或 provider 引用錯誤。
  3. 確認本機監聽：核對 mixed-port: 7890 等實際連接埠，並測試本機是否能連線。
  4. 確認 DNS：觀察節點網域與目標網域能否解析，區分本機監聽失敗與上游逾時。
  5. 確認規則命中：檢查目標究竟走 DIRECT、REJECT，還是預期的策略群組。
  6. 確認節點撥號：比較兩個不同地區節點的錯誤與耗時，判斷是否為單一節點故障。
  7. 確認應用程式接管：日誌沒有目標紀錄時，回頭檢查系統代理、環境變數、TUN 路由與應用程式內的代理設定。
  8. 恢復常用設定：測試結束後將日誌層級改回 info，並清除臨時代理環境變數。

例如，瀏覽器提示無法連線，日誌先出現 lookup node.example.net: i/o timeout，隨後多個節點全部測速失敗。此時共同故障點是節點網域解析，不應逐一修改節點協定。另一個例子是日誌明確顯示 match MATCH using PROXY[US-02]，接著只有 US-02 出現 connection refused，切換至 HK-01 後立即成功，那麼範圍已縮小至單一節點或其連接埠。

最終紀錄至少應包含客戶端版本、Mihomo 核心版本、作業系統、網路類型、目前模式、日誌層級、重現時間與完整錯誤片段。版本資訊有助於判斷設定欄位是否受支援，網路類型則能協助分析 IPv6、公司網路限制或熱點切換問題。只要釐清「流量是否進入 Clash、DNS 是否完成、命中了哪條規則、撥向哪個出口」四個問題，多數執行故障都能從模糊的「代理無法使用」縮小到一個可驗證的環節。

下載Clash