Clash 日誌怎麼看？dial tcp、i/o timeout 等常見錯誤解析

1. 先重現一次問題，再查看同一時間的日誌

網頁無法開啟時，別急著同時修改 DNS、節點、TUN 和規則。先開啟用戶端的「日誌」頁面，記下目前時間，只重新整理一次出問題的網頁。優先查看該時間點前後幾秒的紀錄，而不是從整片紅字中挑一條看似最嚴重的錯誤。

日誌顏色只代表紀錄層級，不等於故障範圍。背景測速失敗可能會產生警告，但瀏覽器目前的連線仍可能正常；反過來說，套用錯誤的直連規則也可能只留下普通連線紀錄，沒有醒目的錯誤提示。

1. 記下用戶端名稱、版本、核心名稱，以及目前使用的是「規則」、「全域」還是「直連」模式。
2. 記下失敗的網域、操作時間與狀況，例如首頁能開啟，但圖片載入失敗。
3. 清空日誌檢視畫面或依時間篩選，再執行一次相同操作。清空畫面不一定會刪除磁碟上的日誌檔案。
4. 保留失敗請求前後的紀錄，尤其是目標位址、命中規則、出站策略與錯誤原因。

2. 如何調整日誌層級：先用 info，必要時短暫啟用 debug

Clash 系列用戶端通常會在側邊欄的「日誌」頁面顯示執行紀錄。如果頁面提供層級篩選，先確認它只是篩選已顯示的紀錄，還是會修改核心的日誌層級。只把篩選器切換到 Debug，不一定會讓核心開始輸出除錯資訊。

核心設定中用來控制日誌詳細程度的欄位是 log-level。原版 Clash 和 mihomo 都使用這個欄位。若用戶端提供「日誌層級」設定，建議優先從介面修改；如果介面沒有此選項，再使用用戶端支援的設定覆寫或合併功能。不要直接修改訂閱產生的檔案後，就以為設定會永久保留；訂閱更新時可能會覆蓋變更。

# 放在設定頂層，不要縮排到 dns 或 rules 下面
log-level: info

需要除錯時，暫時將此欄位改為 debug，依用戶端要求重新載入設定或重新啟動核心，重現一次後再改回 info。設定欄位使用 warning，但日誌行中的層級標籤可能顯示為 WARN 或 warning，請勿混淆。

分享紀錄前，請先檢查是否包含訂閱連結、存取權杖、節點密碼、伺服器位址和本機路徑。保留錯誤原文與連接埠結構即可，公開求助時不必提供整份訂閱設定。

3. 查看單筆連線日誌的四個重點：目標、規則、出站與錯誤

[info] [TCP] 127.0.0.1:53142 --> www.example.com:443
match DomainSuffix(example.com) using Proxy[節點-A]

這筆簡化紀錄表示：本機某個程式從臨時連接埠 53142 發出 TCP 請求，目標是 www.example.com:443，並命中網域後綴規則，最後透過策略組 Proxy 選中的節點-A 出站。左側的臨時連接埠不是用戶端的代理監聽連接埠，不需要依此修改設定。

• 目標：確認是否為故障網頁的網域，或是更新檢查、測速位址、廣告資源等背景請求。
• 規則：查看實際命中的規則。在規則模式下，通常會由上而下比對，命中後便使用對應策略。
• 出站：DIRECT 代表直連，REJECT 代表拒絕；策略組名稱後面也可能顯示最後選用的節點。
• 錯誤：繼續查看相同時間、相同目標的失敗原因，不能只看到 using Proxy 就認定代理連線成功。

看到 MATCH 通常表示套用到兜底規則，並不代表規則引擎失效。如果原本應使用指定策略的網站落入兜底規則，請檢查前面的規則是否涵蓋該網域、規則集是否已載入，以及目前是否確實使用預期的設定。

4. dial tcp：正在建立 TCP 連線，原因要看後續訊息

dial tcp 描述的是連線動作，本身並不是故障結論。後面通常會附上位址和底層錯誤。以下兩筆紀錄都包含這個詞組，但處理方向不同：

dial tcp 203.0.113.10:443: i/o timeout
dial tcp 127.0.0.1:7897: connect: connection refused

遠端位址連線失敗：先確認它指的是哪裡

第一筆中的遠端位址可能是代理伺服器，也可能是直連的目標網站，必須搭配出站欄位和設定判斷。如果位址與目前節點的伺服器位址相同，應先檢查本機到節點之間的連線；如果是透過 DIRECT 存取的網站位址，則應檢查本機網路、路由和網站本身。

本機位址連線失敗：先檢查監聽連接埠

第二筆指向本機 127.0.0.1:7897。如果這是瀏覽器或命令列使用的代理入口，連線遭拒通常表示該位址沒有對應的服務在監聽，或服務未能成功啟動。7897 只是範例，並非所有用戶端的預設值。

在用戶端查看實際的「混合連接埠」或 HTTP/SOCKS 連接埠。如果啟用了混合連接埠，對應的設定欄位是 mixed-port。Windows 可先執行以下命令，確認範例連接埠是否正在監聽：

netstat -ano | findstr :7897

檢查輸出中的本機位址與 LISTENING 狀態，再核對處理程序 PID。只有包含該數字的遠端連線行，無法證明本機正在監聽。如果用戶端根本沒有成功啟動，請先處理啟動錯誤，不要急著更換節點。

5. i/o timeout：等待逾時，不代表節點一定失效

i/o timeout 表示某次網路讀寫未能在期限內完成。它可能發生在建立 TCP 連線、DNS 查詢、代理交握，或連線建立後的讀取階段。單看這兩個詞，無法判斷是電信業者網路路徑、遠端服務、UDP 封包遺失，還是本機防火牆造成的問題。

1. 先確認失敗的對象。節點伺服器逾時和 DNS 伺服器逾時發生在不同環節。請保留 read udp、dial tcp 等前綴。
2. 在同一個網路切換節點。只切換策略組中的節點選擇，保持規則、DNS 和 TUN 設定不變，再造訪相同目標。
3. 使用同一節點切換網路。例如從 Wi-Fi 切換到手機熱點，觀察同類型的逾時是否消失。
4. 分辨是所有網站還是單一網站出問題。如果只有一個網域失敗，也要檢查目標網站的狀態及其規則走向。

如果多個目標都只在同一個節點下失敗，應優先檢查該節點或連往該節點的網路路徑。如果只有一次背景測速逾時，但網頁請求正常，不必因此重設整套設定。測速檢查使用的 URL、通訊協定和實際服務不一定相同。

6. connection refused：連線遭拒，應與逾時分開處理

connection refused 通常表示連線請求收到明確的拒絕回應，而不是一直沒有回應。常見原因是目標連接埠沒有服務在監聽，或裝置上的策略主動拒絕該連線。這不代表密碼錯誤；密碼或通訊協定不符通常發生在連線建立後的驗證或交握階段。

• 本機連接埠拒絕連線：確認系統代理、瀏覽器代理擴充功能和終端機環境變數是否仍指向舊連接埠，並確認核心正在執行。
• 節點連接埠拒絕連線：確認訂閱中的伺服器和連接埠，更新訂閱後再試；不要自行把所有節點的連接埠都改成 443。
• 區域網路位址拒絕連線：確認服務是否只綁定在迴圈位址，並檢查區域網路存取權限和防火牆設定。

如果日誌顯示 address already in use，意思就不同了：用戶端嘗試監聽連接埠時，發現該連接埠已被占用。先找出占用中的處理程序，再決定要關閉舊執行個體或更改連接埠。更改連接埠後，手動設定代理的應用程式也要一併修改。

7. DNS 錯誤：分辨節點網域和網站網域

no such host 通常表示網域查詢沒有取得可用結果，可能是網域不存在、拼字錯誤或解析路徑異常；server misbehaving 通常表示解析器回傳異常狀態。看到這些訊息時，先找出正在解析的名稱，不要直接替換整份 DNS 設定。

lookup www.example.com: no such host
read udp 192.168.1.20:53000->192.168.1.1:53: i/o timeout

第二筆表示對 192.168.1.1:53 的 UDP 讀取逾時，應關注 DNS 查詢路徑。如果設定使用 DoH，也可能看到連往解析服務 443 連接埠的連線錯誤或 TLS 錯誤，排查時不能只看傳統 UDP 53 連接埠。

節點伺服器的網域解析失敗

節點本身的網域無法解析時，後續代理交握根本無法開始。mihomo 的 proxy-server-nameserver 可用來指定代理伺服器網域的解析器，但此欄位有版本和設定語意上的要求，不能直接複製到不支援它的舊版核心。請先確認實際使用的核心，再檢查目前的解析器能否在代理尚未建立時連線。

只有目標網站的網域解析失敗

檢查該網域是否受 nameserver-policy 等設定影響，以及用戶端是否確實接管應用程式的 DNS。瀏覽器內建的安全 DNS、應用程式內建解析器、系統快取和 TUN 的 DNS 劫持設定，都可能使查詢經過不同路徑。

使用 Fake-IP 時，在日誌中看到 198.18.0.0/16 等設定範圍內的對應位址，不代表解析一定遭到污染。請繼續查看網域對應和出站結果。系統中的 nslookup 只能說明該次查詢經過的解析路徑，無法單獨證明瀏覽器或核心使用相同的解析器。

8. 其他常見訊息：TLS、EOF 與啟動失敗

原版 Clash、Clash Meta 和後續的 mihomo，支援的設定功能並不完全相同。如果訂閱包含目前核心不支援的通訊協定或欄位，問題會在載入設定時出現，換節點通常無法修復。請先確認設定是否成功載入、代理群組是否已建立，再排查連線逾時。

TUN 啟動失敗也可能與權限、虛擬網卡或路由建立有關。此時系統代理和 TUN 路徑的表現可能不同。不要因為瀏覽器透過系統代理可以連線，就認定 TUN 已正常運作；也不要一看到 TUN 錯誤就刪除系統網路元件。

9. 完整示範：從一筆 timeout 紀錄逐步鎖定節點連線

假設瀏覽器無法連上 www.example.com，日誌在同一時間出現以下簡化紀錄：

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

1. 確認是這次請求。目標網域和操作時間相符，可排除背景測速紀錄。
2. 確認規則符合預期。日誌顯示流量經由 Proxy。如果原本就希望透過代理存取，先不要調整規則。
3. 核對失敗位址。假設目前節點的伺服器位址確實是 203.0.113.10:443，現有證據便指向連往節點的連線逾時，而不是網頁回傳 HTTP 錯誤。
4. 只切換節點。選擇節點-B，保持模式和目標不變。如果請求恢復，應優先檢查節點-A 或通往該節點的路徑。
5. 必要時切換網路再次確認。如果節點-A 在手機熱點下可用，卻在原本的網路下持續逾時，問題可能與原網路路徑有關，但還不能確定是哪一台設備阻擋了連線。

反過來說，如果原始紀錄顯示 using DIRECT，就不能沿用上述節點判斷。先確認為什麼採用直連，再透過用戶端的「連線」頁面核對目前請求使用的規則和出站策略。暫時切換到全域模式可作為對照，但測試結束後應恢復原模式並修正規則，不要把全域模式當成所有問題的長期解法。

10. 沒有日誌時先檢查流量入口，求助時保留必要資訊

重新整理網頁後完全沒有對應紀錄，應優先懷疑流量沒有進入這個核心，或日誌檢視畫面篩掉了相關紀錄。請檢查應用程式是否使用系統代理、瀏覽器擴充功能是否覆蓋代理設定、是否連線到另一個 VPN，以及 TUN 是否確實啟動。單純開啟系統代理，無法保證所有應用程式或 UDP 流量都會經過 Clash。

也可以使用本機混合連接埠，明確測試流量入口。以下命令中的 7897 必須換成用戶端實際顯示的連接埠；在 Windows PowerShell 中使用 curl.exe，可避免舊版環境中同名別名造成的差異。

curl.exe -I --proxy http://127.0.0.1:7897 https://example.com

執行後立即查看日誌。如果命令顯示無法連線至本機連接埠，先檢查監聽狀態和核心狀態；如果已出現目標連線紀錄，再逐一分析規則、出站和錯誤。命令回傳的 HTTP 狀態只能說明這次請求的結果，無法取代對其他應用程式的檢查。

回報問題時請附上以下資訊

• 用戶端與核心版本、作業系統版本，以及系統代理或 TUN 的啟用狀態。
• 問題發生時間、目標網域、目前模式和最終出站策略，並註明是所有網站還是單一網站無法連線。
• 已去除敏感資訊的完整錯誤行及前後文，不要只截取 i/o timeout 這兩個詞。
• 同一網路切換節點、同一節點切換網路的測試結果，以及最近修改過的設定項目。

按照固定順序排查：先確認流量進入核心，再確認規則和出站策略，最後定位 DNS、連線或交握階段。每次只修改一個變數並記錄結果；恢復連線後，記得將除錯層級調回原設定。下次遇到相同錯誤時，就能依據現有線索繼續排查，不必重新測遍所有選項。