1. 先分辨測速失敗還是實際連線失敗
Clash 用戶端的延遲測試，通常是讓核心透過指定節點向測試 URL 發出請求，再依請求耗時顯示結果。這不只是 ICMP ping，也不等於下載速度測試。清單中的節點全都顯示 timeout，只能表示測試未在限定時間內完成，不能直接推斷所有伺服器同時離線。
測試網址無法連線、節點網域解析失敗、TLS 交握失敗或驗證參數錯誤，都可能呈現類似結果。第一步應保留目前的設定，選定一個節點，查看該時段的核心記錄，再透過同一節點實際開啟網頁測試。
- 記下目前的訂閱名稱、選取的節點、測試時間，以及用戶端顯示的核心名稱與版本。
- 暫停自動切換，在可手動選擇的策略群組中暫時固定一個節點；並確認瀏覽器請求實際經過該節點。
- 只執行一次測速和一次網頁存取，並在連線記錄中核對規則、策略群組與出口路徑。
- 如果網頁可以正常瀏覽但測速失敗，優先檢查測試 URL、測試逾時設定，以及伺服器是否限制測試請求；不要一開始就重新安裝用戶端。
2. 確認訂閱期限、流量與目前設定
訂閱可以更新，不代表帳戶仍有可用流量；反過來說，訂閱更新失敗，也不表示本機快取的所有節點都已失效。訂閱下載與節點連線是兩條不同的路徑，應分別檢查。
依序檢查服務端與本機狀態
- 帳戶狀態：前往服務供應商的帳戶頁面，確認方案到期日、剩餘流量、裝置數或同時連線限制，以及維護公告。用戶端顯示的訂閱用量可能是上次更新時的快取資料。
- 更新結果：查看訂閱更新記錄與最後成功時間。HTTP
401或403表示驗證或存取受到限制；實際原因須參考服務供應商的說明，不能只憑狀態碼就斷定方案已到期。 - 回應內容：HTTP
200仍可能回傳登入頁面或錯誤訊息。只有設定檔解析成功、節點數量正常，而且設定確實已啟用，才能確認內容至少已進入核心載入流程。 - 設定來源：確認目前使用的不是舊版本機副本。若使用
proxy-providers，也要檢查對應的提供者是否更新成功，不能只查看主設定檔的更新時間。
如果服務供應商更換了伺服器位址、連接埠或驗證資訊，而用戶端仍保留舊快取，所有舊節點可能會同時失效。請先成功更新，再核對目前生效設定中的節點資訊；不要只看到訂閱清單顯示「更新完成」就結束檢查。
3. 校正系統時間，再判斷 TLS 與驗證錯誤
系統日期錯誤會影響憑證有效期的判斷。記錄中的 certificate has expired or is not yet valid，可能是伺服器憑證有問題，也可能是本機時鐘不準；部分需要時間驗證的認證流程也仰賴正確時鐘。先校正時間，避免把本機問題誤判為節點協定故障。
| 平台 | 檢查方式 | 確認事項 |
|---|---|---|
| Windows 11 | 「設定」→「時間與語言」→「日期與時間」→「立即同步」 | 開啟自動設定時間，確認同步是否成功 |
| macOS | 「系統設定」→「一般」→「日期與時間」 | 啟用自動設定日期與時間，並確認時間伺服器 |
| 使用 systemd 的 Linux | timedatectl status |
檢查系統時鐘同步狀態與 NTP 服務狀態 |
Windows 也可以執行下方的唯讀命令，查看時間服務狀態與同步來源。如果服務未執行，命令可能會回報錯誤；請回到系統設定處理，不要將命令錯誤當成節點故障。
w32tm /query /status時區會影響本地時間的顯示，TLS 則依據實際時間點進行判斷；只把時區改成其他地區，無法修正錯誤的系統時鐘。校時後重新測試連線。如果仍出現憑證錯誤，再檢查伺服器憑證、節點的 SNI，以及網路是否攔截憑證。
不建議將 skip-cert-verify 設為 true 來掩蓋問題。停用憑證驗證會失去伺服器身分驗證，也無法解決帳戶到期、密碼錯誤或傳輸協定不相容等問題。
4. 確認實際使用的核心，不只看用戶端名稱
用戶端負責介面、設定管理與系統代理，實際建立連線的是核心。原版 Clash 與 Clash Meta（現稱 mihomo）支援的協定範圍不同；同一款用戶端也可能允許切換或更新核心。因此，「設定可以匯入」不代表目前執行的核心支援其中每一種協定。
從載入記錄確認三項資訊
- 核心身分：在用戶端的核心資訊頁面或啟動記錄中，確認名稱與版本，並記下目前實際執行的核心，而非只記錄安裝套件版本。
- 節點類型：查看設定中的
type。例如 Hysteria2、TUIC、VLESS 與 REALITY 相關設定，必須使用支援相應功能的核心及版本，不能以舊版原版 Clash 的相容性作為判斷依據。 - 完整參數：核對伺服器位址、連接埠、密碼或 UUID、傳輸方式、TLS、SNI 及協定專用欄位。協定名稱相同，不代表所有擴充選項都能互換。
出現 unsupported proxy type、未知加密方式或設定解析錯誤時，應先處理相容性與設定問題。這類錯誤通常發生在節點真正開始連線之前，延長測速逾時時間也沒有幫助。記錄中的原始訊息會隨核心版本而異，判斷時應查看欄位與上下文，而非只搜尋某句固定錯誤訊息。
Shadowsocks 的 cipher 必須與伺服器設定一致；VMess 與 VLESS 的使用者識別碼不能互換；使用 WebSocket 的節點也要核對路徑與 Host。REALITY 節點則應確認服務供應商提供的公鑰、短 ID 與伺服器名稱等參數。轉換訂閱時若遺失這些欄位，變更節點名稱或重新測速都無法補回參數。
5. 從記錄分辨 DNS、連接埠與交握故障
確認訂閱、時間與相容性後，再查看請求卡在哪一層。不要同時變更 DNS、TUN、連接埠與規則，否則即使恢復正常，也很難找出原因。可以暫時提高記錄層級，重現一次問題後再還原原設定；不同用戶端可能透過設定覆寫控制此欄位，請確認最後生效的設定。
log-level: debug| 記錄線索 | 常見含義 | 下一步 |
|---|---|---|
no such host |
節點網域解析不到可用位址 | 確認節點網域，以及核心用來解析節點的 DNS 路徑 |
connection refused |
目標或中間設備明確拒絕連線 | 確認位址、連接埠與伺服器監聽狀態 |
i/o timeout |
某個讀寫步驟未能在限定時間內完成 | 搭配上下文分辨是連線逾時，還是交握後逾時 |
與 x509 相關的錯誤 |
憑證驗證未通過 | 確認系統時間、伺服器名稱與憑證鏈 |
| 驗證失敗或交握連線遭中斷 | 可能與憑證、傳輸參數或伺服器端策略有關 | 比對訂閱原始參數與伺服器端記錄，進一步確認 |
節點伺服器網域的解析，與網頁目標網域的解析是兩個不同環節。在 mihomo 中，如果設定了 proxy-server-nameserver，應確認它能否解析代理節點網域；只修改瀏覽器 DNS，不一定會影響核心連線節點時使用的解析路徑。
檢查 TCP 連接埠有助於縮小問題範圍。例如在 Windows PowerShell 中，下方命令會檢查 example.com 的 TCP 443 連接埠。此網域僅用於示範語法，實際排查時應替換為訂閱中的伺服器位址與連接埠；示範結果不代表節點狀態。
Test-NetConnection -ComputerName example.com -Port 443即使 TCP 檢查成功，也只能確認 TCP 連線已建立，不能證明代理驗證與 TLS 交握成功。Hysteria2、TUIC 等以 QUIC 為基礎的連線仰賴 UDP，TCP 測試更無法證明這些服務可用。不要因為 TCP 443 可以連線，就排除目前網路限制 UDP 的可能性。
6. 區分系統代理、TUN 與目前網路的影響
核心內建的節點測試與瀏覽器連線，可能使用不同入口。瀏覽器會受到系統代理、擴充功能與應用程式本身設定影響；TUN 則涉及虛擬網卡、路由與 DNS 接管。如果核心本身連不上節點，反覆切換瀏覽器代理通常無法解決問題；若節點測試正常但網頁無法瀏覽，才更應檢查應用程式流量是否進入核心。
先測試明確指定的本機代理
如果實際混合連接埠是 7890，可以使用下方命令略過系統代理設定，明確向本機 HTTP 代理發出請求。若連接埠不是 7890，必須改成目前的監聽值。Windows 上使用 curl.exe，可避免部分 PowerShell 環境中同名別名造成干擾。
curl --verbose --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/這個命令仍會遵循核心規則，不會自動強制選用特定節點。請在連線記錄中確認目標請求經過預期的代理群組，而不是 DIRECT。命令中的 10 秒與 20 秒分別限制連線階段和整體請求時間，不能據此判斷節點效能；若失敗，請記錄錯誤發生的階段，而不只是寫下「無法開啟」。
接著在同一裝置上比較不同網路
- 使用同一台裝置、同一份設定與同一個節點，比較家用網路和手機熱點，避免同時加入多個變因。
- 如果只有其中一個網路連線失敗，請檢查該網路的登入驗證、UDP 限制、路由或防火牆策略，不要立刻重新匯入訂閱。
- 如果已啟用其他 VPN 或網路過濾工具，先記錄其狀態，再於允許的環境中逐一停用並測試；不要直接關閉所有安全防護。
- 查看記錄中的連線目標使用 IPv4 還是 IPv6。只有確認對應的位址族無法連線後，才進行單一項目的設定測試，以免全域停用 IPv6 掩蓋其他問題。
明確指定本機代理後可以正常連線，但啟用 TUN 後失敗時，應進一步檢查 TUN 路由、DNS 劫持設定與其他虛擬網卡是否衝突。變更前先備份設定，測試後再還原；基本操作可參考使用教學，不要把 TUN 當成解決所有逾時問題的預設開關。
7. 盡量減少變因重新測試，並整理可重現的紀錄
完成一項修正後，使用最初選定的節點與相同測試網址重新驗證。如果只是提高逾時門檻後偶爾成功，表示請求可能受到延遲或封包遺失影響，還需要觀察實際瀏覽是否穩定；清單出現一筆延遲數值，不代表排查已完成。
- 訂閱層：確認帳戶有效且流量足夠，目前使用的節點來自最近一次成功更新，並已套用生效。
- 本機層：確認系統時鐘已同步，記錄核心名稱與版本，並排除設定載入錯誤。
- 連線層：確認節點網域解析、目標位址與連接埠，找出記錄中最早出現的失敗環節。
- 請求層：測試測速 URL 與實際網頁，並查看連線記錄是否選用了預期節點。
- 環境層：必要時比較另一個網路，分別記錄系統代理與 TUN 的狀態，不要同時修改。
向服務供應商或用戶端維護者回報時，請附上系統版本、用戶端與核心版本、問題重現時間及所在時區、節點協定類型、已遮蔽敏感資訊的錯誤片段，以及切換網路後的比較結果。服務供應商較適合確認帳戶權限與伺服器監聽狀態；用戶端維護者則較適合檢查設定解析、核心呼叫與路由接管。將問題交由負責的環節處理，比只傳一張「全部 timeout」的截圖更容易找出原因。
排查完成後，請還原暫時調高的記錄層級，刪除含有敏感資訊的除錯檔案，並保留可用的設定備份。之後再次遇到類似故障時，依照「訂閱與憑證 → 系統時間 → 核心相容性 → 解析與連線 → 應用程式入口」的順序檢查，通常比逐一盲目測試節點更容易找出共同原因。