一、先分辨節點測速失敗與實際連線失敗

Clash 中的 Timeout 只表示某次操作未能在指定時間內完成，不能直接視為節點已失效。節點延遲測試通常會透過節點向測試 URL 發出請求，測量的是整條請求路徑，而不只是到伺服器的網路延遲。測試網站無法連線、網域解析失敗或 TLS 交握異常，都可能造成逾時。

本文以 Clash Verge Rev 搭配 mihomo 核心為例。先開啟「代理」頁面，記下目前的運作模式、目標策略群組和所選節點；再開啟「連線」與「日誌」頁面，保留故障發生時的紀錄。介面名稱可能因版本略有不同，連接埠與設定請以實際運作值為準。

  • 只有一個節點失敗：優先確認該節點的位址、連接埠、協定參數及服務狀態。
  • 所有節點都失敗：優先檢查本機入口、訂閱帳戶、DNS 和目前的網路，不要立刻批次修改節點。
  • 測速失敗但網頁可用：檢查測試 URL 與逾時門檻，不要只因測速顏色就刪除節點。
  • 測速正常但網頁無法開啟：檢查應用程式是否已由核心接管、規則比對結果及實際使用的策略鏈。

二、檢查系統代理、監聽連接埠與本機入口

確認應用程式是否將請求交給核心處理

先在「設定」中查看「系統代理」狀態與目前的代理連接埠，再到系統網路設定中確認實際寫入的位址。以 Windows 11 為例，路徑是「設定」→「網路和網際網路」→「Proxy」→「手動 Proxy 設定」。本機代理位址通常是 127.0.0.1，連接埠必須與用戶端的監聽值一致。

不要預設連接埠一定是 7890 或 7897。以下以目前設定的 mixed-port: 7897 為例；mixed-port 是同時接受 HTTP 和 SOCKS 請求的混合代理入口。Windows PowerShell 可執行：

Get-NetTCPConnection -LocalPort 7897 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

curl.exe --noproxy "" --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com/

macOS 或 Linux 可使用以下指令檢查相同入口；若設定的連接埠不同，請先修改指令中的數字。

lsof -nP -iTCP:7897 -sTCP:LISTEN
curl --noproxy "" --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com/
  • 連線本機連接埠時立即失敗：核心可能尚未啟動，或實際使用的連接埠不同。先排除本機監聽問題，不必繼續檢查遠端節點。
  • 日誌出現 address already in use：連接埠已被其他程序占用。確認程序名稱，關閉重複執行的代理用戶端，或在用戶端中更換連接埠並重新同步系統代理。
  • 指令可用，瀏覽器無法使用：檢查瀏覽器代理擴充功能、獨立代理設定及快取的舊連線；關閉舊連線後再試一次。

這個 curl 指令只會確認請求能否進入本機代理，不保證規則最後選中了遠端節點。請求仍可能命中 DIRECT，必須搭配「連線」頁面確認。收到 HTTP 回應也不代表目標服務可正常使用，但可證明請求已進入回應階段。

分開測試 TUN 與系統代理

系統代理只會影響遵循系統設定的應用程式；TUN 則透過虛擬網卡和路由接管流量。若問題只在啟用 TUN 時發生，先記錄原本設定，再關閉 TUN，使用系統代理和上方的明確代理指令建立基準。若基準正常，再檢查 TUN 的服務權限、路由，以及是否與其他 VPN 衝突。

修改前請備份設定。不要以長期關閉系統防火牆代替問題排查，也不要在不清楚用途時刪除虛擬網卡。企業裝置上的路由和安全政策，請先向管理員確認。

三、檢查訂閱更新、帳戶狀態與目前設定

開啟「設定檔」頁面，確認使用的是預期訂閱，而非舊的本機設定。更新一次該訂閱並查看結果。訂閱下載成功只代表設定檔已成功取得，不代表帳戶仍有流量、所有節點都在線，也不代表新設定已成為目前使用的設定。

  1. 檢查服務商帳戶的到期日、剩餘流量和連線數限制；若流量資訊未顯示，請以帳戶頁面為準。
  2. 比較更新前後的節點數量與名稱，確認服務商是否變更節點入口或協定。
  3. 確認設定已啟用，接著在「代理」頁面重新檢查策略群組的選項。
  4. 若更新失敗，請區分訂閱請求的 HTTP 錯誤、下載逾時與設定解析錯誤，不要一概稱為節點逾時。

HTTP 401 或 403 可能與憑證失效、存取限制或帳戶狀態有關，請參照服務商說明判斷；YAML 解析錯誤通常發生在核心載入設定之前。此時應修復訂閱內容或相容性，而不是反覆測速。

四、檢查 DNS：是節點網域還是目標網域解析失敗

代理連線至少可能涉及兩種解析：一種是節點伺服器網域，另一種是要造訪的網站網域。前者解析失敗時，核心甚至無法取得遠端伺服器位址；後者解析失敗時，節點本身可能正常，但特定網站仍無法開啟。日誌中記錄的具體網域，比一句「DNS 有問題」更有助於判斷。

先檢查系統解析，再檢查核心解析

Windows 可執行 Resolve-DnsName example.com，macOS 或 Linux 可執行 nslookup example.com，確認系統解析是否有回傳結果。檢查實際節點時，應使用訂閱中伺服器欄位所列的網域，不要把含有憑證的訂閱連結當成節點網域。

這些指令預設檢查系統解析路徑，不能直接證明 mihomo 內部 DNS 正常。若設定啟用了 dns.enable，還要檢查實際設定中的 nameserver、proxy-server-nameserver 和相關策略。後者用來指定解析節點網域時使用的上游伺服器；使用 DoH 時，也要考慮 DoH 服務本身網域的初始解析。

  • 日誌顯示 lookup 或 no such host：確認網域拼寫及上游 DNS 是否可連線，並區分系統解析失敗與核心解析失敗。
  • 解析有回傳位址但仍然逾時：接著檢查該位址與連接埠的連線狀況，不要把所有逾時都歸咎於 DNS。
  • 出現 198.18.0.0/16 位址：在 Fake-IP 模式下可能是正常對應；應檢查請求是否由核心接管，不要只憑位址就判定解析錯誤。

不要一次加入大量公共 DNS 位址。先保留原有設定，確認目前網路能否連線至上游；若 DNS 請求必須經由代理，而節點啟動又依賴相同路徑解析，就可能形成循環依賴。DNS 與分流的基礎概念可參閱協定手冊。

五、依日誌階段找出連線中斷點

開啟「日誌」頁面，在重現問題前清除畫面或記下時間，接著只發出一次請求。若一般日誌資訊不足，可暫時將日誌層級調整為 debug；排查完成後恢復為 info，避免持續產生大量紀錄。日誌可能包含造訪網域與伺服器位址，分享前請先去除敏感資訊。

日誌線索可能階段下一步
connection refused連線遭明確拒絕確認錯誤中的位址；本機位址檢查監聽狀態，遠端位址檢查服務與連接埠。
i/o timeout某項網路操作逾時依上下文判斷問題發生在 DNS、TCP、TLS 或讀寫階段。
network is unreachable路由或位址系列檢查預設路由、IPv6 可連線性及 VPN 路由衝突。
x509 相關錯誤憑證驗證確認系統時間、憑證名稱、SNI 與伺服器端憑證設定。
EOF 或 connection reset連線提早中斷確認協定參數、伺服器端日誌及中間網路設備。

單一錯誤通常不足以判定問題出在哪一端。例如 EOF 可能是協定不符，也可能是遠端主動中斷連線。重點是找出最早出現的相關錯誤，而不是最後一筆「請求失敗」。如果所有請求都在載入設定時失敗，應先修正設定錯誤，再分析網路問題。

六、確認節點協定參數與遠端連接埠

若本機入口、訂閱和 DNS 都正常，再檢查節點的 server、port 與協定類型。TCP 連接埠探測只能確認能否建立連線，不能證明驗證、加密或代理轉送成功。Windows 的 Test-NetConnection 可在指定實際伺服器與連接埠後測試 TCP；UDP 協定不能依相同結果下結論。

  • Shadowsocks：確認加密方式、密碼及外掛程式需求；加密方式名稱必須與伺服器端一致。
  • VMess / VLESS：確認 UUID、傳輸方式與 TLS 相關設定。VLESS 的 flow 等欄位必須符合伺服器端設定。
  • TLS / WebSocket：確認 SNI、Host 和路徑。伺服器連線位址、TLS 名稱和 HTTP Host 可能各不相同，不要一律改成同一個 IP。
  • REALITY：確認服務商提供的公鑰、short-id、server-name 等參數，不要只複製伺服器位址。
  • Hysteria2 / TUIC：通常依賴 UDP。若同一網路中的 TCP 節點可用，但這些節點失敗，請檢查網路是否限制 UDP，以及本機安全政策是否封鎖連線。

遇到憑證錯誤時，先同步系統日期、時間和時區，再確認伺服器端憑證及名稱是否相符。不建議長期略過憑證驗證作為修復方式。若設定包含核心不支援的欄位，請記錄用戶端與核心的實際版本，再依服務商要求判斷相容性；不要只根據介面顯示的用戶端版本號推斷所有協定功能。

七、以規則比對與交叉測試完成排查

最後回到「連線」頁面，重新開啟目標網站，查看比對到的規則、策略群組與最終節點。Rule 模式下，部分請求命中 DIRECT 原本就是預期結果；REJECT 則表示規則拒絕請求，並非節點逾時。策略群組也可能包含巢狀的自動選擇群組，因此在外層選取一個群組，不代表已固定使用某個節點。

保留最小對照組，避免擴大修改範圍

  1. 固定同一個節點與目標，比較系統代理和明確指定代理的請求，確認是否為應用程式未接管流量。
  2. 在符合規範且允許的網路環境中，比較目前網路與手機熱點；若只有某個網路失敗，優先檢查該網路的 DNS、連接埠或 UDP 限制。
  3. 保持網路不變，改用另一個已知可用的節點；若只有單一節點失敗，請向服務商提供節點資訊與故障時間。
  4. 如需暫時使用 Global 模式排除規則影響，測試後請恢復原本模式，並再次確認連線路徑。

聯絡支援人員時，請提供作業系統版本、用戶端版本、核心版本、故障時間與時區、節點協定、是否使用 TUN、去識別化的日誌，以及兩組對照測試結果。不要只傳送一張測速結果全紅的截圖，因為其中看不出請求在哪個階段失敗。