故障排除 閱讀時間約 10 分鐘

Clash 執行記錄怎麼看？常見錯誤訊息與排查步驟

說明記錄等級與每筆記錄的結構，解析 dial tcp 逾時、DNS 解析失敗、規則未命中等常見錯誤，並整理從記錄追查設定的流程。

先確認問題發生在哪個環節，再調整設定。看到紅色記錄就換節點，往往會走冤枉路：本機連接埠未啟動、網域名稱無法解析、規則選錯出口、遠端交握失敗，表面上都可能是「網頁無法開啟」，但處理方式完全不同。

本文適用於 Clash 及 Clash Meta（現名 mihomo）核心。不同用戶端可能會重新排版記錄，同一種錯誤的前綴也可能不同。以下記錄僅供說明結構，並非特定裝置的實測結果；排查時請以自己的時間、目標位址和實際出口為準。

一、先取得一筆完整的失敗記錄

開啟用戶端的「記錄」或「Logs」頁面，先清除介面上的搜尋條件。若介面同時提供等級篩選和核心記錄等級設定，請分清兩者：篩選只會隱藏既有記錄，無法讓核心補上先前未輸出的除錯資訊。平時使用 info；問題不易重現時，再暫時切換至 debug。

  1. 記下用戶端名稱與版本、核心名稱與版本。介面版本不等於核心版本。
  2. 確認目前的設定名稱、執行模式、系統代理和 TUN 的開關狀態，再記下本機時間。
  3. 保留既有記錄，清除介面上的顯示內容或記下起始位置，然後只造訪一次出問題的網址。
  4. 複製失敗那一行及前後約 10 行。若同時有多筆連線，請用目標網域、連接埠和來源連接埠區分，不要只憑相鄰位置推斷彼此相關。

二、如何判讀記錄等級與連線欄位

等級常見內容排查用途
debug解析、連線等較詳細的過程資訊短暫重現問題，完成後恢復
info啟動狀態、規則比對與出口選擇確認請求是否進入核心，以及採用哪個策略
warning連線失敗或可復原的異常根據目標位址判斷是否影響目前使用的服務
error較嚴重的執行或載入問題優先檢查設定載入、監聽和資源初始化
silent抑制一般記錄輸出不適合在重現問題時使用

以下是常見的核心記錄等級。用戶端可能會將 warning 顯示為 WARN，或使用中文標籤。等級反映記錄的重要程度，不代表故障一定發生在本機；網站後端請求逾時也可能被記為警告。

time="2026-09-11T10:20:30+08:00" level=info msg="[TCP] 127.0.0.1:53124 --> example.com:443 match DomainSuffix(example.com) using PROXY[節點A]"
  • time：記錄時間。請對照系統時區，避免把舊錯誤當成本次請求。
  • [TCP]：連線使用的傳輸協定；UDP 請求會有相應標示。
  • 127.0.0.1:53124：本次連線的來源，不是核心的代理監聽連接埠。
  • example.com:443：請求目標。443 通常用於 HTTPS，但單憑連接埠無法確認應用程式協定。
  • match：實際命中的規則，不是設定中預期會命中的規則。
  • using：策略群組及選定的出口。群組名稱是 PROXY，不代表群組目前選用的項目一定是代理節點。

這筆記錄表示核心已為連線比對規則並選擇出口，不代表網頁已成功載入。後續連線、TLS 交握或應用程式回應仍可能失敗。請一併查看同一次造訪所產生的失敗記錄。

三、dial tcp 逾時：先確認連線目標

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

第一行表示 TCP 撥號未能在期限內完成。範例中的 203.0.113.10 是文件範例位址，不能拿來測試。實際記錄中的這個位置可能是網站 IP，也可能是代理伺服器 IP；必須搭配錯誤前綴和出口判斷。使用代理時，「撥號失敗」不一定代表網站伺服器出了問題。

依位址類型逐項檢查

  1. 位址是代理伺服器：保持測試網址不變，只切換一個節點。如果只有某個節點持續逾時，優先檢查該節點的位址、連接埠及服務狀態，不要先改整套 DNS 設定。
  2. 位址是目標網站：檢查連線是否實際使用 DIRECT。如果中國大陸與海外的規則設定顛倒，原本應透過代理存取的目標可能會直接連線。
  3. 位址是本機迴路位址：確認本機代理是否正在該連接埠監聽。7890 只是常見的設定值，實際值請以目前的設定和用戶端介面為準。

connection refused 通常表示連線遭到明確拒絕，常見原因是沒有程序正在監聽，或防火牆主動拒絕；i/o timeout 則表示等待逾時。兩者不可混為一談，也不能只憑一次逾時就判定節點永久失效。

透過一次明確指定代理的請求縮小問題範圍

確認混合代理連接埠確實是 7890 後，即可執行以下命令。Windows 建議使用 curl.exe，避免受舊版 PowerShell 中 curl 別名影響。

curl --noproxy "" -v --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

這裡的 10 秒是連線階段的上限，20 秒是整個請求的上限，不是網速測試結果。命令會明確指定本機代理，方便與瀏覽器的結果比較。如果命令可以連線但瀏覽器失敗，接著檢查瀏覽器代理擴充功能、系統代理和應用程式本身的網路設定；若記錄完全沒有對應連線，先確認命令使用的連接埠和記錄篩選條件。

四、DNS 解析失敗：區分三種網域

DNS 出錯時，先確認失敗的是目標網站網域、代理伺服器網域，還是 DNS 上游本身的網域？這三種失敗發生在不同階段。代理伺服器的網域無法解析時，換網站通常沒有幫助，因為連線出口尚未就緒。

lookup example.com: no such host
lookup example.com: i/o timeout

no such host 通常與網域不存在或解析器回傳否定結果有關；i/o timeout 則較可能是查詢未能及時取得回應。還需查看錯誤中指出的解析伺服器及相關情境。若出現 all DNS requests failed，代表本次查詢嘗試的上游都未成功，不能因此直接推斷「所有節點都壞了」。

  • 先確認網域拼寫，再檢查目前設定中的 dns.enable、nameserver 等欄位。
  • 檢查 DNS 上游是否可連線。使用加密 DNS 時，還需確認上游位址解析、連線和憑證驗證是否正常，不只是檢查 UDP 53 連接埠。
  • 若 mihomo 設定使用 proxy-server-nameserver，也要確認負責解析代理節點網域的設定能正常運作，避免依賴尚未建立的代理出口。
  • 一次只更換一個上游，並記錄修改前後查詢同一網域的結果。不要同時修改 DNS、節點和規則。

使用 fake-ip 模式時，看到 198.18.0.0/16 範圍內的合成位址，不應立即判定為 DNS 污染。請繼續檢查 fake-ip 對應、流量是否回到核心，以及網域資訊能否用於規則比對。

五、規則未命中：從實際出口回查規則順序

「規則未命中」很多時候不是明確的錯誤訊息，而是連線記錄顯示命中了非預期的規則。先確認目前使用 Rule／規則模式。Global／全域模式和 Direct／直連模式不會以相同方式套用分流規則，因此修改規則檔可能看不到預期變化。

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

以下內容僅用來說明規則順序，假設設定中已定義名為 PROXY 的策略群組。規則通常會由上而下比對，命中第一條規則後就採用相應策略；MATCH 應放在最後作為兜底。若把 MATCH 寫在網域規則之前，後面的規則就不會有機會處理連線。

命中 MATCH 不一定代表錯誤

沒有更具體的規則命中時，使用兜底規則是正常情況。如果某個網域原本應命中特定規則，請檢查實際載入的設定、規則拼寫、遠端規則集載入狀態，以及記錄中是否保留了網域資訊。若只有目標 IP，網域類規則可能無法如預期參與比對；嗅探也無法在所有連線中可靠還原網域。

  • DOMAIN 用於精確比對網域；DOMAIN-SUFFIX 用於比對網域及其子網域，不要填入完整 URL 或路徑。
  • RULE-SET 需要對應的 rule-providers 名稱，且必須相容於規則集的類型與內容格式。
  • 使用 GEOSITE 等功能前，應確認核心是否支援；不要假設所有舊版 Clash 核心都能直接使用 mihomo 設定。
  • 修改訂閱產生的設定前，先確認用戶端的覆寫機制。直接編輯暫存檔，下一次更新訂閱時可能會被覆蓋。

最後開啟策略群組，確認群組內實際選用的項目。即使記錄顯示命中 PROXY，如果該群組目前選的是 DIRECT，最終仍會直接連線。規則名稱、策略群組名稱和實際出口要分開判讀。

六、監聽、TLS 與 TUN 常見的誤判

記錄或現象優先檢查項目
address already in use確認具體衝突的監聽位址和連接埠，以及是否有第二個核心正在執行
certificate has expired or is not yet valid系統日期、時區，以及受驗證服務的憑證有效期限
TLS handshake timeoutTCP 建立連線後的交握流程、節點參數及網路中間設備
permission denied錯誤所涉及的檔案、監聽操作或虛擬網卡權限
啟用 TUN 後，沒有對應的連線記錄確認 TUN 是否成功建立、路由是否生效，以及應用程式是否繞過流量接管

遇到連接埠占用時，Windows 可執行 netstat -ano | findstr :7890 查看相關監聽項目及 PID；macOS 或 Linux 可使用 lsof -nP -iTCP:7890 -sTCP:LISTEN。確認程序身分後，再關閉重複執行的執行個體；不要直接結束不認識的系統程序。若要變更連接埠，也要同步修改系統代理和測試命令。

遇到憑證錯誤時，不要把停用憑證驗證當成通用解法。先校正系統時間，再確認錯誤來自訂閱下載、DNS 上游、代理伺服器還是目標網站。不同環節的憑證不能互相替代；改錯位置不但無效，還會降低連線驗證的安全性。

TUN 是接管流量的方式，不會自動修復無法連線的節點或已過期的憑證。可以先關閉 TUN，使用明確指定 HTTP 代理的命令驗證核心出口；若明確指定代理時成功、TUN 卻失敗，再集中檢查服務權限、虛擬網卡、路由及 DNS 接管。這種對照方式比同時重裝用戶端和修改所有規則更容易保留線索。

七、從記錄追查設定的固定流程

  1. 確認核心正在執行。檢查設定是否載入成功、代理連接埠是否正在監聽；啟動錯誤尚未排除前，先不要追查網站規則。
  2. 確認請求已進入核心。固定一個網址並只造訪一次，查看是否出現對應目標，排除因記錄篩選造成的「空白」。
  3. 確認模式與命中規則。記下目前使用 Rule、Global 或 Direct 模式，以及記錄中的命中項目。
  4. 確認實際出口。展開策略群組，查看最終選用的節點或 DIRECT，不要只看群組名稱。
  5. 確認失敗階段。區分網域解析、TCP 撥號、TLS 交握和應用程式回應，再追查相應的設定欄位。
  6. 一次只修改一處。保留原始設定，重新載入後建立新連線，使用相同請求比較結果；舊連線可能仍會使用原本的出口。
  7. 重新測試並恢復記錄等級。以相同請求連續測試數次，確認修復穩定後，再將 debug 改回 info，避免長期累積過於詳細的連線記錄。

需要查對欄位時，可參閱設定欄位說明。在社群發問時，請附上核心版本、已移除敏感資訊的設定片段、重現步驟及對應時段的記錄。比起只說「代理無法使用」，這些資料能更快將問題縮小到某個連接埠、規則或 DNS 上游。

下載用戶端