Clash 日誌怎麼看？常見錯誤訊息與排查方法

先確認日誌來源與請求時間

Clash 日誌記錄的是核心處理連線的過程，不是瀏覽器頁面的完整診斷報告。網頁無法開啟，可能是應用程式未使用代理、規則選擇、網域解析、節點連線或遠端服務回應等不同環節出了問題。先找出故障發生在哪一層，再修改對應設定，比看到紅字就重新安裝用戶端更有效。

Clash 是核心與相關用戶端的常見名稱；Clash Meta 後續以 mihomo 之名持續發展。不同核心、桌面用戶端與介面版本，日誌欄位和選單名稱可能有所不同。本文的日誌行僅為結構示例，並非實際網路測試結果，也不能以示例連接埠取代本機設定。

1. 在用戶端側邊欄開啟「日誌」或「Logs」。若用戶端沒有日誌頁面，請到「設定」尋找日誌目錄或核心日誌入口。
2. 記下目前時間、使用的設定檔名稱、運作模式、策略組中實際選用的節點，以及系統代理和 TUN 的開啟狀態。
3. 清除介面中的舊日誌，接著只開啟一個有問題的網頁。等待約 10 秒後，暫停捲動或匯出這一小段記錄。
4. 依目標網域、目標連接埠和時間篩選。自動更新、連線測試與網頁請求會混在同一個視窗中，不能只看最後一筆錯誤。

如何設定日誌層級：先用 info，短暫切換至 debug

常見日誌層級包括 silent、error、warning、info 和 debug。日常排查先使用 info，通常就能看到連線與規則比對資訊。只有需要確認解析、撥號或核心細節時，才短暫啟用 debug。

設定位置與設定覆寫

若介面提供「設定」→「日誌層級」，請優先從介面調整。直接管理核心設定時，可在目前生效的 YAML 頂層設定以下欄位；它不是 dns 或 tun 的子項目。

log-level: info

儲存後，依用戶端支援的方式重新載入設定檔，再次查看日誌。部分用戶端會透過設定覆寫、合併設定或執行時參數控制日誌層級；訂閱更新也可能覆蓋直接編輯的檔案。不要只憑磁碟上的檔案內容判斷設定是否生效，還要確認介面與實際日誌輸出。排查完成後，請恢復為 info，避免長期累積大量請求記錄。

如何看懂一筆連線日誌：目標、規則、出口與錯誤鏈

建議固定依序查看：先看時間，再看請求目標，接著確認規則與實際出口，最後讀取錯誤鏈。以下是簡化的結構示例；實際日誌的欄位順序或換行格式可能不同。

[warning] [TCP] 127.0.0.1:53124 --> www.example.com:443
match DomainSuffix(example.com) using Proxy[節點A]
error: dial tcp 192.0.2.10:443: i/o timeout

• 127.0.0.1:53124 表示核心看到的連線來源。53124 是臨時來源連接埠，不是要填入系統代理的監聽連接埠。
• www.example.com:443 是請求目標。443 常用於 HTTPS，但光看連接埠無法判斷網站憑證是否正常。
• match 後面的內容可用來確認命中哪一條規則。規則模式通常會依序比對，較早命中的規則會影響後續流向。
• using Proxy[節點A] 表示這次使用的策略與節點。策略組名稱不是節點伺服器位址，還要確認實際選取的成員。
• dial tcp 後面的位址是本次撥號的目標。使用直連時可能是網站位址，使用代理時可能是節點位址，需依整段錯誤鏈判斷。

示例中的 192.0.2.10 是文件示例位址，不應填入設定檔。若看到 DIRECT，但原本預期透過節點連線，請先檢查規則與模式；若看到 REJECT，請先檢查封鎖規則，不要把它當成節點離線。

dial timeout 與 i/o timeout：確認連線在哪個環節逾時

dial timeout、connect: connection timed out 通常表示未能在期限內建立連線。i/o timeout 涵蓋範圍較廣，也可能出現在連線建立後的讀取或寫入階段。這些訊息表示等待逾時，不代表「節點失效」或「DNS 遭污染」。

依故障範圍縮小排查方向

1. 只有一個網站無法連線：使用相同節點開啟另一個已知可連線的網站，確認故障網域是否命中不同規則，或流量是否走了直連。
2. 同一節點下多個網站都無法連線：在同一策略組中切換另一個節點，再重試相同請求。若只有原節點失敗，請優先確認原節點的位址、連接埠與服務狀態。
3. 所有節點都無法連線：先確認本機網路正常，再檢查節點網域解析、防火牆、上游網路限制，以及訂閱是否已過期。
4. 只有 TUN 模式無法連線：保留相同設定與節點，改用系統代理進行比對。若明確指定代理時正常、TUN 異常，請優先檢查路由、DNS 接管與其他 VPN 衝突。

在 Windows 的 PowerShell 中可執行 Test-NetConnection -ComputerName 節點網域 -Port 節點連接埠，但必須將兩個中文參數值替換成目前設定中的實際值。這類 TCP 測試只適用於使用 TCP 的端點，不能據此判斷 UDP 協定是否正常；連接埠可連通，也不代表驗證、TLS 或應用程式請求一定成功。

不要一開始就延長逾時時間。等得更久也無法修正錯誤位址、失效服務或不通的網路路徑。應先確認日誌中逾時的端點，再決定是否需要調整逾時參數。

connection refused：區分本機與遠端連接埠

connection refused 表示連線嘗試遭到拒絕，常見原因是該位址與連接埠沒有服務監聽，或網路設備主動拒絕連線。這與靜待一段時間後逾時不同。第一步是確認遭拒的位址是 127.0.0.1 還是節點伺服器位址。

本機 127.0.0.1:7890 遭到拒絕

7890 只是常見的示例代理連接埠，並非所有用戶端都固定使用這個值。應用程式連線至本機 7890 遭拒時，請開啟用戶端「設定」中的連接埠或混合連接埠設定，確認核心是否已啟動，以及實際監聽連接埠是否已變更。也請檢查核心日誌中是否先出現連接埠繫結失敗。

# Windows：查看本機 7890 是否正在監聽
netstat -ano | findstr ":7890"

# macOS / Linux：查看 TCP 7890 的監聽程序
lsof -nP -iTCP:7890 -sTCP:LISTEN

判斷 Windows 的輸出時，應同時查看本機位址欄與 LISTENING 狀態，不能只因為看到「7890」就認定代理已啟動。若發現有程序占用，請先確認該程式的身分；不要直接結束不熟悉的系統程序。

遠端節點連接埠遭到拒絕

若拒絕來自節點位址，請確認訂閱中的伺服器位址與連接埠仍有效，並更新訂閱後再試。HTTP 代理憑證錯誤可能會以 407 Proxy Authentication Required 等回應呈現，不應將所有拒絕都歸因於密碼錯誤。節點連接埠可連線後，仍須另外確認協定與驗證。

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

no such host、lookup ... failed、DNS resolve failed 都指向解析環節，但解析失敗的網域可能是造訪的網站，也可能是節點伺服器。節點網域無法解析時，即使網站 DNS 設定正確，也無法先連上節點。

• 目標網站解析失敗：檢查目前生效設定檔中的 dns 區段、解析器是否可連線，以及直連與代理路徑使用的解析策略。
• 節點網域解析失敗：在 mihomo 中確認是否設定了 proxy-server-nameserver，以及節點尚未連線時，對應的解析器是否仍可使用。
• DoH 解析器本身無法連線：確認 DoH 位址、其主機名稱的引導解析，以及對外連線路徑，避免「連線到節點需要 DNS，DNS 又依賴尚未連線的節點」形成循環。
• 只有 TUN 模式下失敗：檢查 TUN 的 DNS 接管設定、系統現有 DNS，以及其他 VPN 是否同時修改網路設定。

系統查詢正常，不代表核心查詢也正常

執行 nslookup www.example.com 可檢查系統使用的解析器是否有回應，但查詢不一定經過 mihomo 內建 DNS。瀏覽器也可能啟用安全 DNS，改走另一條解析路徑。因此，「nslookup 有結果」只能做為比對依據，不能證明核心實際使用的解析器正常。

使用 fake-ip 模式時，出現設定的 Fake IP 位址範圍內的合成位址可能是正常情況，例如常見的 198.18.0.0/16。不要一看到這類位址就判定遭到劫持。請繼續確認該連線是否回到正確的核心路由，以及實際的上游解析或節點連線是否失敗。更完整的檢查位置請參閱手冊中的 DNS 排查。

憑證、連接埠繫結與 TUN 權限錯誤

TLS 發生錯誤時，先確認連線對象。核心回報的憑證錯誤可能發生在節點交握、訂閱下載或 DNS over HTTPS 請求中，不一定來自瀏覽器正在瀏覽的網站。一般代理轉送 HTTPS 時，網站憑證最後仍通常由瀏覽器驗證。

建立 TUN 或操作路由時若遇到權限錯誤，請開啟用戶端「設定」中的服務模式、權限或 TUN 相關頁面，依該用戶端的要求安裝服務或授予權限。Windows 桌面用戶端可能需要已安裝的背景服務；Linux 通常涉及 TUN 裝置與網路管理權限。實際做法因用戶端而異，不建議將長期以管理員身分執行當成所有錯誤的通用解法。

若修改了監聽連接埠，也要同步更新系統代理、終端機代理環境變數與瀏覽器擴充功能中的手動設定。核心成功啟動後，如果應用程式仍指向舊連接埠，本機連線仍會失敗。

固定複測順序與日誌去識別

每次只變更一個項目，並使用同一個網域、同一種連線方式複測。否則同時更新訂閱、切換節點、修改 DNS 又開啟 TUN，即使恢復連線，也無法確認真正原因。

1. 保留原始設定備份，並記錄問題發生時間與實際錯誤行。
2. 確認請求已進入核心，再確認規則是否選中預期的出口。
3. 依日誌分別檢查解析、撥號、驗證或 TLS，不要跨層猜測。
4. 每次只修改一項設定，重新載入後查看同一請求的新日誌，確認錯誤是否消失或有所變化。
5. 恢復日常使用的日誌層級，並測試瀏覽器與常用終端機程式，避免只修復其中一條代理路徑。

向維護者回報問題時，請提供用戶端名稱、用戶端與核心的實際版本、作業系統、運作模式、是否啟用 TUN、重現步驟，以及前後約 20 行相關日誌。版本資訊請從「關於」頁面或核心啟動記錄確認，不要把用戶端版本當成核心版本。

傳送前請移除訂閱連結、存取權杖、代理密碼、控制 API 金鑰，以及可能洩漏個人資訊的網域與 IP。去識別後仍應保留欄位結構、連接埠、錯誤類型與規則關係，方便判斷。請勿公開整份訂閱檔案，也不要透過關閉憑證驗證或長期停用防火牆來掩蓋原始故障。