如何看懂 Clash 執行日誌：常見錯誤訊息與逐步排查方法

網頁無法開啟時，先別急著不斷更換連接埠、DNS 和代理節點。Clash 日誌最適合用來釐清三件事：請求是否進入核心、規則將請求交給誰，以及連線在哪個步驟失敗。依序檢查，通常比搜尋整行錯誤訊息更容易縮小問題範圍。

本文適用於 Clash 系列用戶端及 Clash Meta（現名 mihomo）的常見排查流程。不同核心、版本和圖形介面的日誌格式可能有所差異；以下日誌皆為去識別化的說明範例，網域和位址不代表可用服務。不能只憑某個英文關鍵字就判定節點失效。

1. 開啟核心日誌，先保留一次完整的失敗紀錄

用戶端可能同時有「應用程式日誌」、「核心日誌」和「連線」頁面。應用程式日誌主要記錄介面啟動、設定檔下載和服務管理；核心日誌則會記錄規則比對、DNS 查詢及代理連線。連線頁面可查看仍在活動中的連線及其代理鏈。這三處資訊彼此補充，並非同一份紀錄。

以最少操作重現一次問題

進入用戶端的「日誌」或「核心日誌」頁面，記下目前時間、啟用中的設定檔和代理模式。選單名稱請以目前使用的用戶端為準。
確認核心日誌層級設為 info。如果缺少關鍵細節，可暫時調整為 debug，套用設定後再重現問題。
關閉其他持續連網的應用程式，只開啟一個無法載入的頁面。記下點擊時間，例如 14:32:08，並查看接下來約 10 秒的日誌。
保留錯誤行及其前後各 5～10 行。排查完成後恢復為 info，避免除錯資訊長時間大量累積。

# 合併至目前設定的頂層，不要重複新增同名欄位
log-level: info

透過訂閱管理設定時，直接修改下載後的檔案，可能會在下次更新時遭到覆寫。建議優先使用用戶端提供的覆寫或合併功能；若只能編輯檔案，請先備份，再確認重新載入是否成功。設定解析失敗時，新設定不一定已經生效。

2. 如何讀懂日誌層級與單行欄位

日誌層級代表紀錄的重要程度，不是網路品質評分。背景應用程式重試所產生的 warning，不一定與目前網頁的故障有關；反過來說，只有 info 也不能證明頁面內容已成功載入。

層級	常見內容	排查用途
`debug`	更詳細的 DNS、連線和內部處理資訊	短時間重現複雜問題，請留意去識別化
`info`	一般執行狀態、連線與規則紀錄	日常排查的起點
`warning`	連線失敗、查詢異常等警告	搭配時間和目標判斷是否相關
`error`	較嚴重的執行或設定問題	先檢查是否影響核心啟動或監聽
`silent`	抑制日誌輸出	不適合用來收集故障線索

將一筆紀錄拆成五個部分

time="2026-09-15T14:32:08+08:00" level=info msg="[TCP] 127.0.0.1:53124 --> www.example.com:443 match DomainSuffix(example.com) using 網頁代理[節點A]"

時間：14:32:08+08:00 可用來對照剛才的操作；跨裝置比對時，也要留意時區。
協定：[TCP] 表示這筆連線使用 TCP，不能據此推斷 UDP 也正常。
來源：127.0.0.1:53124 是本機來源位址和臨時連接埠，53124 不是要填入代理設定的監聽連接埠。
目標：www.example.com:443 是存取目標及目標連接埠，不一定是錯誤訊息中最後撥號連線的節點位址。
比對規則與出口：DomainSuffix(example.com) 是命中的規則，網頁代理[節點A] 表示策略群組與所選節點。

這類資訊行主要說明核心如何處理連線，不代表 TLS 交握、登入和頁面資源都已完成。若後面緊接著出現逾時或交握錯誤，請繼續往下查看，不能只看到「已命中代理」這一行就停止。

3. dial tcp timeout：先確認逾時發生在哪一段

level=warning msg="[TCP] dial 網頁代理 (match DomainSuffix/example.com) 127.0.0.1:53124 --> www.example.com:443 error: dial tcp 203.0.113.20:443: i/o timeout"

dial tcp 表示正在建立 TCP 連線；i/o timeout 表示某個步驟等待時間超過期限。有些紀錄會顯示 connect: connection timed out，或在較上層包裝成 context deadline exceeded。這些訊息表示等待失敗，但不能單憑此判定原因是 DNS、遠端服務還是本機防火牆。

先看最後一個 IP 位址和連接埠

範例中的目標是 www.example.com:443，實際撥號位址卻是 203.0.113.20:443。如果後者對應節點的 server 和 port，請先檢查電腦到節點這一段；如果目前使用 DIRECT，則應檢查直連目標網站的路徑。使用鏈式代理時，也要依實際代理鏈檢查中間節點。

核對節點設定：檢查訂閱是否過期，以及節點網域、連接埠和協定是否與伺服器一致。不要把網頁的 443 直接當成節點連接埠。
一次只更換一個變數：維持規則和 DNS 不變，切換到另一個已知可用的節點，再存取相同目標。
比較不同網路：在允許的情況下切換至手機熱點。如果相同節點只在某個 Wi-Fi 下逾時，請優先排查該網路的出口限制。
檢查本機網路路徑：留意防火牆、其他 VPN、虛擬網卡和 TUN 路由衝突，不要一開始就關閉所有安全防護。

Windows 可在 PowerShell 中使用 Test-NetConnection 檢查 TCP 是否可連線。以下位址僅供文件示範；實際測試時應改用節點設定中的真實主機和連接埠，不要直接測試範例位址。

Test-NetConnection -ComputerName 203.0.113.20 -Port 443

TcpTestSucceeded 為真，只代表這次 TCP 連線成功建立，不能驗證代理協定、認證資訊或 UDP 轉送。節點延遲測試也一樣：某個測試網址連線成功，不代表所有服務網域都能存取。

4. connection refused：確認遭拒的是本機還是遠端連接埠

dial tcp 127.0.0.1:7890: connect: connection refused

connection refused 通常表示連線收到明確拒絕，常見原因是目標連接埠沒有服務在監聽，也可能是防火牆主動拒絕。這和逾時不同：逾時代表一直等不到預期結果；遭拒通常會更快收到回應。

位址是 127.0.0.1：檢查代理監聽

如果錯誤來自瀏覽器、命令列或其他應用程式，且位址是 127.0.0.1:7890，請先確認核心正在執行，而且實際監聽連接埠確實是 7890。用戶端可能已改用 7897，但系統代理仍保留舊值。不要用來源臨時連接埠取代這裡的連接埠。

# 目前設定的相關欄位範例；連接埠須與應用程式中的設定一致
mixed-port: 7890
allow-lan: false

mixed-port 可同時接收 HTTP 與 SOCKS5 代理連線。設定應用程式的代理時，仍須選對協定，不能因連接埠混合就任意填寫。Windows 可查看監聽狀態；macOS 和 Linux 可使用對應的連接埠檢查命令：

# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp 'sport = :7890'

位址是遠端節點：核對伺服器監聽狀態與訂閱

若遭拒的是節點 IP 位址與節點連接埠，請優先確認伺服器是否仍在監聽、連接埠是否已變更，以及訂閱是否已更新。反覆修改本機 mixed-port 無法修復遠端連接埠遭拒的問題。若啟動日誌出現 address already in use，表示本機連接埠已被占用：先找出占用的程序，再決定停止衝突服務或統一更換連接埠。

5. DNS 解析失敗：區分目標網域與節點網域

lookup www.example.com: no such host
dns resolve failed: all DNS requests failed
read udp 192.168.1.8:53012->192.168.1.1:53: i/o timeout

no such host 常見於系統解析器回報找不到網域名稱，但仍須核對網域拼寫、DNS 上游和回傳結果。all DNS requests failed 是彙總錯誤，請繼續查看前面的具體失敗原因；UDP 53 逾時則表示未能及時收到相應 DNS 服務的查詢回應。

從三個層面檢查解析路徑

解析失敗的是哪個網域：若是網頁網域，會影響該網站的存取；若是節點的 server 網域，代理通道可能根本無法建立。兩者的處理順序不同。
由誰負責解析：查看是否啟用核心 dns、應用程式是否使用自己的安全 DNS，以及系統 DNS 請求是否由 TUN 接管。
是否能連上上游：傳統 DNS、DoH 和 DoT 使用的網路路徑不同。DoH 使用 HTTPS，不代表目前的網路一定能連上。

系統命令 nslookup www.example.com 通常會查詢系統指定的 DNS。查詢成功只能表示該解析路徑可用，不能直接證明 Clash 核心 DNS 或瀏覽器內建 DoH 正常。進行對照測試時，務必記錄查詢所用的伺服器，而不只是確認有沒有回傳 IP 位址。

在 Fake-IP 模式下，應用程式取得 198.18.0.0/16 範圍內的映射位址可能是正常現象，實際範圍取決於 fake-ip-range。不能只因位址看起來不像公網 IP 就判定解析錯誤，也不應直接用這個映射位址判斷公網連線是否正常。

變更 DNS 後，應用程式、系統和核心可能各自保留快取。請依用戶端支援的方式清除相關快取，關閉舊連線後再測試；不要把舊快取命中的結果當成新設定已生效。

6. 從規則命中結果回查：為什麼請求走錯出口

規則模式通常會依序比對 rules，命中後採用相應策略。如果目前是全域模式，應優先檢查全域策略選擇；如果是直連模式，則不要期待一般代理規則像規則模式那樣接管請求。排查前先確認目前模式，避免一再修改未參與決策的設定。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,網頁代理
  - GEOIP,LAN,DIRECT
  - MATCH,網頁代理

這段範例要求現有的 proxy-groups 中確實有名為「網頁代理」的策略群組，而且核心支援使用的規則。這只是規則片段，並非完整設定。MATCH 是兜底規則，應放在需要優先比對的規則之後。

依序核對規則、策略群組和最終節點

規則是否命中：預期存取 example.com，卻顯示 MATCH 時，請檢查實際網域、子網域、規則順序和重新載入結果。
命中結果是否合理：顯示 DIRECT 時，先確認是否被更前面的直連規則攔截，不要直接判定為節點故障。
策略群組是否選對：同一個群組可能選擇 DIRECT、另一個群組或某個節點。自動測速與故障轉移群組也可能動態變更出口。
是否只有部分資源載入失敗：主頁、圖片和登入介面可能使用不同網域。只檢查網址列中的網域，可能會漏掉真正出錯的資源。

例如，主頁走「網頁代理」，但登入介面命中直連規則，可能會出現「頁面打得開，登入卻一直轉圈」的情況。請依登入操作時間尋找對應的目標網域；必要時搭配瀏覽器開發人員工具的「網路」面板，確認失敗請求後再查閱日誌。

暫時切換至全域模式可用於對照測試，但不是最終解法。如果全域模式正常、規則模式失敗，就應回頭檢查規則和 DNS 路徑。修改後請關閉舊連線再試：既有連線可能仍沿用原本的出口，不會因為規則變更就自動重新建立。

7. TLS、UDP 與設定錯誤的補充判斷

日誌關鍵字	優先檢查項目	避免的誤判
`x509: certificate`	系統時間、憑證有效期限、節點伺服器名稱與 TLS 設定	不要把略過憑證驗證當成一般解法
`TLS handshake timeout`	TCP 建立連線後的網路路徑、伺服器回應及 TLS 參數	不代表網域一定解析失敗
`EOF` / `connection reset by peer`	哪一端提前關閉連線、協定參數、伺服器日誌	僅憑一行無法判定是認證資訊錯誤還是網路干擾
`[UDP]` 相關逾時	節點是否支援 UDP、TUN 路由、出口網路限制	TCP 測速通過不代表 UDP 正常
`yaml: unmarshal errors`	錯誤行附近的縮排、欄位型別、重複鍵與核心相容性	設定未載入時，切換節點通常無濟於事

設定中的 udp: true 無法讓不支援 UDP 的伺服器憑空具備這項能力。遊戲或語音異常時，需核對用戶端入口、節點協定、伺服器及出口網路的整段連線路徑。同樣地，瀏覽器使用 QUIC 時可能出現 UDP 相關紀錄，不能只用 TCP 連線成功來解釋所有狀況。

如果憑證錯誤發生在節點交握，請優先檢查節點的伺服器名稱與協定參數；如果發生在更新訂閱時，則應檢查訂閱網站及系統信任鏈。兩種錯誤雖然都包含 x509，卻發生在不同的連線階段。

8. 提供排查資訊：保留前後文並隱藏敏感內容

有用的排查紀錄不必很長，但必須能將操作和連線對應起來。優先提供以下資訊，比只說「逾時了」更容易獲得準確判斷：

環境：作業系統版本、用戶端版本、核心名稱與完整版本號。請從「關於」頁面或啟動日誌複製，不要只寫「最新版」。
入口：系統代理或 TUN、目前模式、本機監聽連接埠，以及是只有一個應用程式失敗，還是所有應用程式都失敗。
重現方式：操作時間、失敗的功能、當時的策略群組與節點選擇，並說明是否剛更新訂閱或設定。
佐證資料：相關日誌的前後文、規則命中紀錄，以及更換節點或網路後的對照結果。

最後仍應依相同順序重新測試：確認請求進入核心、確認規則與出口符合預期，再確認 DNS、連線建立及應用程式層級的請求都已完成。每次只變更一項，並記錄結果。如此才能分辨問題是真正修復還是偶然恢復，也能在訂閱更新後更快找回有效設定。