先確認：逾時發生在測速，還是實際連線
開啟用戶端的「代理」頁面，記下目前的策略群組和選取的節點，再前往「日誌」頁面查看一次失敗的請求。不同用戶端可能將這兩個頁面命名為「代理群組」和「執行日誌」，請以實際介面為準。先別重新安裝，也不要一次更改 DNS、規則和連接埠。
節點測速通常會讓核心透過指定節點請求測試網址，再依用戶端設定計算延遲。顯示 timeout，只能表示這次測試未在時限內完成。測試網址無法使用、DNS 查詢失敗或節點交握失敗，都可能出現相同結果。
- 測速逾時，但網頁能開啟：先檢查測試 URL 和測試逾時時間，不要直接刪除節點。
- 測速有延遲，某個應用程式無法開啟：優先檢查依應用程式設定的代理、規則比對結果，以及應用程式本身的網路設定。
- 所有節點都逾時，所有代理連線都失敗：依照下方順序檢查共用環節，先確認本機網路，再檢查訂閱和 DNS。
- 只有一個節點失敗：先找另一個伺服器位址不同的節點進行比較，不必馬上修改整份設定。
第一步：停止代理，檢查本機網路和 VPN 介面
先確認手機在直連狀態下能正常上網
- 在用戶端首頁停止連線，確認 Android 狀態列上的 VPN 圖示已消失。
- 開啟平時可直接瀏覽的網站。若公共 Wi-Fi 顯示認證頁面，先完成登入，再啟動用戶端。
- 中斷 Wi-Fi，改用行動數據測試同一個節點。接著切回 Wi-Fi，其他設定維持不變。
- 如果只有某個 Wi-Fi 無法連線，記下這項差異。別馬上判定所有節點都已失效。
Android 的 VpnService 是讓應用程式建立本機 VPN 介面的系統機制。在一般個人使用情境下，同一位使用者通常只能啟用一項 VPN 服務。其他 VPN、防火牆或使用 VPN 介面的過濾應用程式，可能會取代 Clash 的介面。請先停止這些服務，再重新連線。
排除系統設定造成的直連阻擋
開啟 Android「設定」→「網路和網際網路」→「VPN」→ 點選目前用戶端旁的設定按鈕，檢查「一律開啟 VPN」和「封鎖未使用 VPN 的連線」。部分系統會將入口放在「連線與共用」中。如果啟用了封鎖選項，停止用戶端後無法上網，可能是系統依設定執行，不是 Wi-Fi 本身故障。若要比較直連狀況，可暫時關閉此選項；測試期間流量可能會繞過代理，測試完成後再視需要恢復。
如果只有在鎖定螢幕後中斷，先解鎖並重新啟動服務，再前往「設定」→「應用程式」→ 目前的用戶端 →「電池」檢查背景限制。請將這種情況與持續發生的節點交握逾時分開記錄。
第二步：確認訂閱更新成功，且設定已啟用
開啟「設定檔」頁面，手動更新目前的訂閱，查看更新時間和錯誤提示。訂閱是取得節點和規則的設定來源；更新失敗與代理連線失敗是兩回事。舊設定可能仍可使用，而更新成功也不代表訂閱中的每台伺服器都能連線。
- 確認目前啟用的是剛更新的設定，而不是同名的舊匯入檔案。
- 前往訂閱服務商的管理頁面，確認到期時間、剩餘流量，以及裝置或連線數量限制。
- 查看更新錯誤：HTTP
401或403通常與授權或存取政策有關，404表示請求的位址不存在；仍須搭配回應內容判斷具體原因。 - 若出現 YAML 解析錯誤或不支援的代理類型，先解決設定載入失敗，再進行節點測速。
YAML 是 Clash 常用的設定文字格式，縮排會影響結構解析。不要把訂閱網址當成節點伺服器位址，也不要將回傳的登入頁面存成設定檔。介面顯示「已下載」後又出現解析錯誤，通常表示取得的內容不是用戶端可使用的設定。
第三步：分辨節點網域解析與目標網站解析
DNS 是將網域名稱轉換為 IP 位址的查詢程序。一次代理連線可能會先解析節點伺服器的網域，再由本機或遠端解析目標網站。任一環節失敗，都可能被介面歸類為連線逾時。先確認日誌中的錯誤網域屬於哪一端。
| 觀察到的情況 | 優先檢查項目 | 下一步 |
|---|---|---|
| 節點伺服器網域顯示找不到主機 | 啟動連線前的 DNS 解析路徑 | 確認本機能解析該網域，並檢查解析請求是否錯誤地依賴尚未連線的節點 |
| 節點交握成功，但特定網站出現解析錯誤 | 目標網域的 DNS 與規則 | 改用另一個目標網站比較，並查看 DNS 設定和連線日誌 |
| 只有啟用 Android 私人 DNS 後才失敗 | 系統私人 DNS 是否可連線 | 暫時改為自動，再使用相同網路重測 |
| 切換網路後仍使用舊的解析結果 | 應用程式與核心快取 | 停止並重新啟動服務，再重試一次相同請求 |
可在 Android「設定」→「網路和網際網路」→「私人 DNS」查看系統設定。私人 DNS 通常使用加密的 DNS over TLS，與設定檔中的 DNS over HTTPS 並非同一項設定。將系統私人 DNS 暫時設為「自動」僅供比較，不代表用戶端內部 DNS 一定已恢復。
mihomo 是相容於 Clash 設定生態系的代理核心。在其 DNS 設定中，proxy-server-nameserver 可指定用來解析節點伺服器網域的解析器，default-nameserver 則用於解析 DNS 服務本身的網域等初始解析情境。欄位是否生效取決於實際核心的支援情況，不能只看用戶端外殼的名稱。不要強制將所有解析請求送進目前無法連線的代理，以免形成啟動依賴循環。
不要任意將節點網域改成網路上找到的 IP。TLS 伺服器名稱驗證、SNI，以及 CDN 或負載平衡的路由選擇，都可能依賴原本的網域。SNI 是交握時告知伺服器所要存取名稱的欄位；改成 IP 後，即使 TCP 已連線，也不一定能完成正確的 TLS 交握。
第四步：校正系統時間並檢查 TLS 錯誤
開啟「設定」→「系統」→「日期和時間」，啟用「自動設定時間」和「自動設定時區」。部分系統的入口名稱為「更多設定」→「日期和時間」。確認日期、年份和目前實際時間一致，再重新啟動連線。
TLS 是用於加密連線及驗證伺服器身分的協定。憑證有有效期限，部分代理協定也會受到時間差影響。若日誌出現 certificate has expired or is not yet valid，應先核對本機時間，再檢查伺服器憑證；不能只憑這行錯誤就斷定手機時間有問題。
x509: certificate signed by unknown authority：可能是憑證鏈不完整、使用自簽憑證，或連線遭中間設備攔截。- 憑證名稱不相符：確認節點網域是否符合服務商要求的伺服器名稱。
- 時間正確但仍出現憑證錯誤：保留日誌，請服務商檢查憑證部署和入口位址。
不要為了消除錯誤而長期啟用 skip-cert-verify。略過憑證驗證會降低伺服器身分檢查的安全性，既無法修復連接埠不通，也無法解決協定參數錯誤。
第五步：確認協定、伺服器連接埠與核心支援情況
在節點詳細資訊中查看協定類型、伺服器位址和伺服器連接埠，再到用戶端的「關於」或核心資訊頁面記錄實際核心版本。Clash 外殼和核心是不同的版本概念；用戶端能匯入設定，不代表執行中的核心支援其中所有協定和欄位。
別混淆本機監聽連接埠與遠端連接埠
- 本機連接埠：例如設定中的
mixed-port: 7890，供本機應用程式連接 HTTP 或 SOCKS 代理。7890 只是常見範例，請以目前設定為準。 - 伺服器連接埠：節點詳細資訊中的
port，用於連線至遠端服務。可能是 443，也可能是服務商指派的其他連接埠。 - 管理連接埠：
external-controller屬於控制介面，不是供瀏覽器連線至網站的代理入口。
將本機連接埠 7890 改為 7891，無法解決遠端伺服器連接埠遭封鎖的問題。若日誌出現 address already in use，才需要檢查本機連接埠是否已被占用，或服務是否重複啟動。
依傳輸方式進行比較
Hysteria2、TUIC 等協定仰賴 UDP。部分網路會限制 UDP，導致這類節點失敗，而使用 TCP 的節點仍可運作。請選擇服務商明確提供的 TCP 節點，在相同網路下比較；只關閉節點設定中的 UDP 選項，不代表協定已轉換為 TCP。
使用 WebSocket 或 gRPC 的節點，也要確認傳輸路徑、Host 或服務名稱。收到 HTTP 400、404 或異常的交握回應，可能是入口參數不相符，也可能是伺服器反向代理設定有問題。優先重新取得相容於目前核心的訂閱，不要逐個欄位猜測修改。
第六步：確認實際流量是否進入正確的策略群組
開啟「連線」頁面，再用瀏覽器造訪一次目標網站。確認是否出現該請求，以及顯示的規則、策略群組和最後使用的節點。Rule 模式會依設定規則選擇直連或代理；選取節點只會影響對應的策略群組，不會覆蓋所有直連規則。
- 如果沒有出現該請求，請檢查 Android 依應用程式設定的代理是否排除了瀏覽器，並確認 VPN 服務確實正在執行。
- 若請求符合
DIRECT，先檢查對應規則，不要反覆切換代理群組中的節點。 - 若請求進入其他策略群組，請前往該群組確認實際選取項目，並留意群組中可能仍選著
DIRECT或舊節點。 - 可短暫切換至 Global 模式進行比較，並選取一個明確的節點。測試後請恢復 Rule 模式，避免將暫時狀態當成最終設定。
Global 模式用於比較代理選擇，不保證會接管所有裝置流量。依應用程式設定排除的應用程式，以及未進入代理介面的流量，都不會因切換模式而自動出現。桌面版的 TUN 是透過虛擬網路介面接管流量，Android 用戶端一般則透過 VpnService 接收流量；兩者都無法修復失效的伺服器或錯誤的憑證。
桌面版輔助檢查：指定本機代理連接埠
若同一份訂閱也用於電腦，可在電腦終端機執行以下命令。範例假設電腦用戶端的 HTTP 或 mixed 連接埠確實是 7890，測試目標為 https://example.com/；該目標本身也必須能正常使用。這不是 Android 系統內建的測試步驟。
curl --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 -I https://example.com/127.0.0.1 一律代表執行命令的裝置本身。在電腦執行的命令不會自動連到手機用戶端。若要讓其他裝置連線，還涉及區域網路監聽和存取控制，不建議在本次疑難排解時額外啟用。命令收到 HTTP 回應，只能表示這條測試路徑可用，不能證明所有應用程式都已透過代理連線。
日誌錯誤速查：先找出連線流程中最早發生的失敗
前往「日誌」頁面，暫時將層級調整為 info；資訊不足時再短暫使用 debug。記下單次請求的時間，重現問題後保留前後相關日誌。不同核心的訊息文字可能不同，下表用於判斷排查方向，不能取代完整的上下文。
| 日誌片段 | 通常代表 | 接著檢查 |
|---|---|---|
lookup … no such host | 網域查詢未取得有效記錄 | 確認出錯的是節點網域還是目標網域，以及 DNS 回傳的內容 |
dial tcp … i/o timeout | 未能在時限內建立通往指定位址的 TCP 連線 | 伺服器位址、連接埠、目前網路和遠端狀態 |
connection refused | 連線嘗試收到拒絕回應 | 確認目標連接埠是否有服務監聽，以及防火牆是否主動拒絕 |
TLS handshake timeout | TLS 交握未能在時限內完成 | 鏈路封包遺失、伺服器負載、TLS 入口和名稱參數 |
authentication failed | 驗證未通過 | 訂閱狀態、密碼或 UUID，以及協定要求 |
connection reset by peer | 對端或鏈路中的設備重設了連線 | 協定參數、伺服器端日誌，以及切換網路後的差異 |
EOF | 讀取時連線已結束 | 先前的交握與驗證錯誤；無法單憑此訊息判定原因 |
例如先出現節點網域解析失敗，接著才是測試逾時，就應先處理 DNS；不要將最後一行的逾時當成唯一原因。完成疑難排解後，請恢復常用的日誌層級，避免長期保留大量連線記錄。
仍然全部逾時：整理可重現的回報資料
如果直連正常、訂閱有效、時間正確，而且至少兩台不同伺服器在 Wi-Fi 和行動數據下都無法連線，請將證據提供給訂閱服務商或用戶端維護者。多個節點若共用同一個入口網域，就不能算是完全獨立的伺服器比較。
- 環境：依實際介面填寫 Android 版本、用戶端名稱與版本，以及核心名稱與版本。
- 時間：失敗日期、具體時分和所在時區，方便比對伺服器端記錄。
- 影響範圍：是所有節點還是單一節點，是測速失敗還是實際網頁無法開啟。
- 網路差異：Wi-Fi 和行動數據各測試 3 次的結果，以及是否完成公共網路認證。
- 日誌：首次錯誤前後的必要內容，並遮蔽訂閱權杖、驗證資訊和個人使用的網域。
- 已完成的檢查：訂閱更新結果、系統時間、DNS 比較和協定類型，避免重複測試。
排查結束後，恢復暫時修改的日誌層級、代理模式、私人 DNS 和系統 VPN 封鎖選項。保留能重現問題的最精簡步驟，比繼續疊加覆寫設定更容易找出故障原因。