先確認記錄來源與故障時間

Clash 記錄不只是錯誤訊息清單，也會記下設定載入、連接埠監聽、DNS 請求、規則比對與對外連線。排查時先釐清三件事：請求有沒有進入核心、套用了哪項策略，以及連線在哪個環節失敗。只看到一則紅色提示就更換所有節點，容易把連接埠、名稱解析與遠端服務故障混為一談。

本文適用於使用 Clash 或 Clash Meta（現稱 mihomo）核心的用戶端。不同用戶端與核心版本的記錄格式、選單名稱可能有所不同；請先在用戶端的「關於」頁面記下用戶端與核心版本，再開啟「記錄」或「執行記錄」。訂閱更新記錄、用戶端介面記錄與核心執行記錄來自不同來源，請勿混為一談。

  1. 記下故障發生的當地時間，精確到秒，例如 14:32:10。
  2. 暫停下載、影片及其他持續連網的工作，清除介面中的舊記錄，再只觸發一次目標請求。
  3. 保留觸發前後約 10 秒的記錄，並在「連線」頁面核對目標網域、目標連接埠、規則與實際出站。
  4. 記下目前使用的是規則、全域還是直連模式，以及是否啟用系統代理、TUN；每輪測試只變更一項。

調整 log-level：先用 info，再短暫切換 debug

日常排查先使用 info，通常就能看到連線目標、符合的規則及採用的策略。只有在解析過程、策略提供器或連線細節不明時，才暫時切換至 debug。silent 會關閉記錄，不適合排查；error 或 warning 可能省略成功連線與規則資訊。

核對設定與生效狀態

在用戶端設定中尋找「記錄層級」；若介面沒有此選項，請透過用戶端支援的設定編輯或覆寫功能修改頂層欄位。以下使用的是核心設定值，警告層級應寫成 warning，不要根據介面上的縮寫推測設定格式。

# 頂層設定；排查完成後恢復 info
log-level: debug
mode: rule
  • 儲存後使用用戶端提供的設定重新載入功能；如果提示需要重新啟動核心，請依照指示操作，並確認啟動時沒有錯誤。
  • 遠端訂閱可能在更新時覆蓋直接編輯的內容，建議優先使用用戶端支援的持久化覆寫方式。
  • 重現一次後匯出相關時段的記錄即可，不必讓 debug 持續執行數小時；完成後請恢復 info。

除錯記錄可能包含造訪的網域、本機位址、節點名稱與設定路徑。對外提供前，請刪除訂閱權杖、驗證資訊、控制介面金鑰及個人目錄資訊；同時保留錯誤類型、連接埠與策略關係，避免遮蔽資訊後失去排查線索。

逐一查看連線的目標、規則與出站

從目標網域或連接埠著手搜尋，不要從整頁記錄的第一行開始猜。一個網頁可能同時請求主站、圖片、介面與統計網域，因此一筆失敗記錄不代表主頁連線失敗。以下是簡化的 TCP 連線示意：

[TCP] 127.0.0.1:52144 --> www.example.com:443
match DomainSuffix(example.com) using Proxy[Node-A]
欄位核對內容
TCP / UDP用來區分傳輸協定；瀏覽器可能使用以 UDP 為基礎的 HTTP/3。
127.0.0.1:52144此例是本機來源與臨時來源連接埠，不是用戶端的代理監聽連接埠。
www.example.com:443目標主機與服務連接埠；確認確實與這次故障操作相關。
DomainSuffix符合的規則類型；接著核對規則中的策略名稱。
Proxy[Node-A]示意中的策略群組與最終節點；實際記錄可能顯示多層策略鏈。

出現 using DIRECT 時，請先確認是否符合預期，而不是立刻判定規則失效。連線記錄顯示的是路由選擇，不代表遠端請求已成功；還需要搭配後續錯誤、連線流量與應用程式結果一起判斷。

dial tcp timeout：分辨連線到哪裡逾時

搜尋 dial tcp、i/o timeout 或 context deadline exceeded，通常是在排查連線或操作等待逾時。其中 dial tcp 指向 TCP 建立連線階段，但其他逾時訊息也可能出現在 DNS 查詢、TLS 交握或代理協定交涉階段。請一併查看前後的目標位址與操作說明。

先分清節點位址與網站位址

  • 連線代理節點逾時：錯誤中的位址對應節點伺服器與節點連接埠。先核對節點網域解析、連接埠、網路可連線性及訂閱是否過期，再測試同一策略群組中的其他可用節點。
  • 直連網站逾時：連線記錄使用 DIRECT，目標是網站位址。請檢查直連網路、目標服務與規則選擇，不要只調整節點參數。
  • 經由節點連線後仍無法存取網站：節點本身能建立連線，但目標請求失敗。比較同一節點存取其他網站，以及其他節點存取同一網站的結果，縮小問題範圍至目標端或節點出口。

connection refused 與逾時不同：通常表示連線遭到主動拒絕，例如目標連接埠沒有服務監聽，也可能是中間設備拒絕連線。connection reset by peer 表示連線遭到重設，不能只憑這則訊息就認定是密碼錯誤或特定網路干擾。

DNS 解析失敗：分別檢查兩條解析路徑

DNS 錯誤至少要分清「代理節點網域解析失敗」與「目標網域解析失敗」。前者會讓代理連線尚未建立就中止；後者則與目前的 DNS 模式、目標解析路徑及上游解析器有關。記錄中的 lookup、no such host、DNS resolve failed 與查詢逾時，都應搭配後面的網域一起閱讀。

  1. 確認網域拼寫與用途。如果解析失敗的是節點伺服器網域，請先檢查節點設定，以及該網域是否仍有效。
  2. 分辨錯誤回應與逾時。no such host 常見於網域不存在或沒有可用解析記錄；查詢逾時則應檢查上游 DNS 是否可連線、傳輸方式與路由。
  3. 檢查解析器啟動所需的依賴。使用網域名稱形式的 DoH 上游時，也必須先解析解析器本身的網域。mihomo 的 default-nameserver、proxy-server-nameserver 等欄位各有不同用途，應依照目前版本的文件核對，不能任意互換位址。
  4. 重新載入後建立新連線。變更 DNS 設定後，請使用用戶端支援的方式清除快取或重新啟動核心，同時關閉應用程式中的舊連線，避免舊結果影響判斷。

Fake-IP 位址不代表解析異常

啟用 Fake-IP 後，用戶端可能會向應用程式回傳設定位址池中的虛擬位址，例如常見的 198.18.0.0/16 範圍。這些位址用於將後續連線對應回網域，不是網站的公網位址。看到這類位址不能直接判定 DNS 遭到污染；應檢查該連線是否由核心接管，以及網域對應是否仍有效。

系統終端機中的 nslookup 結果，也不一定等同於核心實際使用的結果。系統 DNS、瀏覽器安全 DNS、核心 DNS 與遠端代理解析可能走不同路徑。排查 TUN 時，也要確認 DNS 劫持設定與路由確實生效，而不只是確認設定中寫了 enable: true。

規則未命中：先檢查模式與第一個符合的規則

規則模式會依序比對，通常由第一個符合的規則決定出站方式。全域模式不會依照一般規則清單為每條連線選擇策略；直連模式則會直接連線。因此，「明明設定了網域規則，卻走錯節點」時，首先應確認用戶端目前是否處於 rule 模式。

# 示意：Proxy 必須是設定中已存在的策略名稱
rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - MATCH,DIRECT

在此例中，example.com 及其子網域應符合第一條規則；其他未符合規則的連線則會套用 MATCH,DIRECT。如果把涵蓋範圍較大的規則放在前面，後續更精確的規則可能永遠沒有機會符合。檢查時應查看用戶端實際生效的規則，而不只是訂閱來源檔案。

  • 記錄中只顯示 IP：檢查應用程式是否略過核心進行解析，以及該連線是否保留網域資訊。網域規則無法憑空判斷某個純 IP 位址屬於哪個網站。
  • 符合兜底規則：核對目標是否其實是 API 或 CDN 子網域，並檢查規則提供器是否成功載入、更新時是否發生錯誤。
  • 規則正確但節點不對：查看策略群組目前選取的項目；自動測速群組、故障轉移群組可能會依各自邏輯選擇成員。
  • 修改後仍使用舊策略：先結束相關的舊連線再重試。既有長連線不一定會在規則重新載入後立即改用新路由。

mihomo 的網域嗅探可在支援的協定與設定條件下補充網域資訊，但並非所有加密連線都能還原網域。不要把啟用嗅探當成解決所有規則問題的通用方法，也不要為了單一網站就讓所有流量永久切換至全域模式。

沒有連線記錄：檢查入口連接埠與流量接管方式

應用程式顯示錯誤，但核心沒有對應記錄時，請優先確認請求是否進入用戶端。系統代理只會影響遵循系統代理設定的應用程式；某些命令列工具、遊戲與內建代理設定的應用程式需要另外設定，或透過適當的 TUN 接管。啟用系統代理不代表所有 TCP、UDP 流量都已進入核心。

使用明確指定的代理入口進行對照

假設本機實際生效的設定中，混合連接埠為 7890，可使用下方的明確代理請求。這個連接埠僅為範例，務必改用用戶端目前顯示的監聽連接埠；若連接埠為 0 或未啟用，就不能直接照抄。

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

在 Windows PowerShell 中，可將命令開頭改為 curl.exe，避免部分環境的命令別名差異。執行時同步觀察記錄：若請求進入核心，但瀏覽器請求沒有進入，請優先檢查瀏覽器代理設定、擴充功能與連線重用；若立即顯示無法連線至 127.0.0.1:7890，請先檢查核心是否正在執行、連接埠是否正確，以及是否成功監聽。

  • address already in use：監聽位址或連接埠已被占用。檢查是否同時執行兩個代理用戶端；停止衝突的服務或更換監聽連接埠後，也要同步更新入口設定。
  • permission denied / operation not permitted：依據記錄上下文檢查 TUN、路由操作或檔案存取權限，並依照用戶端提示授予所需權限。
  • authentication failed：確認錯誤發生於本機入口驗證、代理節點驗證，還是訂閱下載驗證；不要混用這三處的憑證。
  • TUN 啟動失敗：查看建立虛擬網卡、安裝路由或檢查權限時出現的第一則錯誤。若其他 VPN 也在修改路由，請先避免同時測試。

這項 curl 測試主要用於驗證明確指定的 HTTP 代理入口與對應請求路徑，不能據此證明 TUN、UDP 或所有應用程式都正常。若用戶端啟用了 TUN 自動路由等設定，也應搭配實際路由一併判斷。

固定重現步驟並記錄排查結果

有效的故障記錄應讓其他維護人員能重複相同操作，而不只是提供一張包含數十則紅色訊息的截圖。建議依照下列順序完成一輪排查，確認一個環節後再檢查下一個環節。

  1. 核心啟動：確認設定載入成功、所需連接埠已成功監聽，且核心沒有持續重新啟動。
  2. 請求進入核心：透過明確指定代理的測試或應用程式連線記錄，確認核心能看到目標請求。
  3. 解析完成：分清節點網域與目標網域，確認故障不在 DNS 前置階段。
  4. 路由符合預期：記下符合的規則、策略群組與最終節點，必要時結束舊連線後重新測試。
  5. 出站對照：同一目標更換節點、同一節點更換目標；每次只變更一個條件。
  6. 還原設定：將 debug 恢復為 info，撤銷僅供診斷使用的臨時規則，並確認常用應用程式的連線狀態。

回報問題時請附上這些資訊

記錄作業系統版本、用戶端與核心的完整版本、使用的代理入口與連接埠、出站模式、TUN 狀態、故障時間，以及已遮蔽敏感資訊的相關記錄。描述「瀏覽器無法連線至某網域，但明確指定代理的 curl 測試成功」，比「網路突然壞掉」更容易排查；描述「只有一個節點失敗，同組另一個節點成功」，則能進一步縮小問題範圍至節點設定或節點網路路徑。

如果記錄已顯示連線建立成功，但應用程式仍出現憑證、登入或 HTTP 狀態錯誤，請繼續檢查應用程式層。系統時間錯誤、伺服器回傳 403、帳戶狀態與憑證信任，都無法只靠調整規則順序解決。排查的目標是確認故障所在層級，並以相同操作驗證修復結果，而不是讓記錄介面看起來完全沒有警告。