Clash 顯示「已連線」，通常只代表 iOS 網路延伸功能、TUN 介面或本機代理已啟動。這個狀態無法證明訂閱仍然有效，也無法證明目前的策略組已選取可用節點。請求還必須依序經過 DNS 解析、規則比對、策略組與遠端節點；其中任何一層失敗，都可能表現為 Safari 持續載入、應用程式顯示網路錯誤，或只有部分網站無法開啟。
排查時不要連續修改多個設定。先記錄目前的設定名稱與策略模式，每完成一步就用同一個網頁重新測試。建議先開啟 Safari，造訪 http://captive.apple.com/hotspot-detect.html，正常回應通常會顯示「Success」；再造訪一個常用的 HTTPS 網站。分開測試 HTTP 與 HTTPS，有助於初步區分網路入口、DNS、TLS 與代理線路問題。
第一步：確認問題只在 Clash 開啟後出現
進行一次關閉與開啟對照
- 維持目前的 Wi-Fi 或行動網路不變，關閉 Clash 的代理開關。
- 在 Safari 開啟兩個先前無法載入的網站，並重新整理一次。
- 重新開啟 Clash，等待狀態穩定 5 秒後，再造訪相同網址。
- 記錄是「關閉後正常、開啟後失敗」，還是兩種狀態都失敗。
如果關閉 Clash 後仍然無法連線，故障多半位於本機網路、電信業者連線或網站本身。先檢查飛航模式、Wi-Fi 登入頁面與行動數據權限。公共 Wi-Fi 經常要求先完成驗證；此時可以暫時關閉 Clash，開啟任意 HTTP 頁面觸發登入頁，完成驗證後再開啟代理。
如果關閉後正常、開啟後立即失敗，請依本文順序繼續檢查。若只有某個應用程式失敗，請進入 iOS 的「設定」→「行動服務」，確認該應用程式與 Clash 客戶端具備行動數據權限。也要留意應用程式是否僅在 Wi-Fi 下運作，以及目前的 Wi-Fi 是否啟用了需要重新驗證的入口網站。
| 對照結果 | 優先檢查 | 暫不處理 |
|---|---|---|
| 關閉與開啟都失敗 | Wi-Fi 驗證、行動數據、系統網路 | 規則與策略組 |
| 關閉正常，開啟失敗 | 節點、規則、DNS、VPN 狀態 | 重置路由器 |
| 網頁正常，單一應用程式失敗 | 應用程式權限、規則命中、UDP 支援 | 刪除整份設定 |
| 網域失敗，部分 IP 可連線 | DNS 設定與 DNS 劫持 | 頻繁切換節點 |
第二步：檢查訂閱是否有效並完整更新
訂閱能顯示在客戶端中，不代表訂閱網址仍可讀取。服務到期、訂閱連結失效、伺服器回傳登入頁面，或更新過程中網路中斷，都可能讓客戶端繼續保留舊設定。當舊節點全部失效時，介面仍可能顯示策略組與「已連線」，但實際連線會逾時。
核對更新時間與更新結果
- 進入客戶端的設定或訂閱頁面，確認目前啟用的是預期設定，而不是較早匯入的本機副本。
- 查看最後更新時間。若訂閱提供方已更換節點，而本機更新時間停留在數天前，請手動更新一次。
- 更新後確認策略組仍包含節點。只有群組名稱、沒有可選節點，通常表示訂閱內容為空或解析失敗。
- 出現 HTTP
401或403時，檢查訂閱權限與網址；出現404時，通常需要重新取得訂閱連結；出現5xx時，等待伺服器恢復後再試。
更新訂閱前不要先刪除舊設定。較穩妥的做法是保留舊設定，建立新的設定欄位並匯入更新後的網址，確認可以正常載入後再切換。即使新訂閱回傳不相容欄位，也能快速切回原設定並比較差異。
第三步：確認策略組確實選取可用節點
Clash 設定常見的策略組類型包括 select、url-test、fallback 與 load-balance。其中 select 需要手動選擇；自動測試組則依賴測試網址、測試間隔與節點可達性。群組內顯示節點名稱，只代表設定已載入，不代表節點交握成功。
先用手動選擇排除自動測試干擾
- 開啟策略組頁面，找到規則最後引用的主要代理組，例如「節點選擇」或「PROXY」。
- 不要只在次級地區組中切換。確認最外層的主要群組沒有停留在
DIRECT、REJECT或已失效的自動群組。 - 手動選擇一個明確的單一節點，連續測試兩到三個不同地區的節點。
- 每次切換後等待 3 至 5 秒，再重新開啟網頁，避免沿用舊連線而造成誤判。
延遲測試只能說明測試網址當時可達。顯示 80 ms 的節點仍可能無法造訪目標網站，也可能缺少 UDP 支援、TLS 交握異常，或出口受到限制。反過來，測試逾時也可能是測試網址遭到封鎖，而節點本身仍能連線到其他網站。因此應同時查看實際網頁結果與連線記錄，不能只看延遲數字。
辨識常見連線錯誤
| 記錄或現象 | 常見原因 | 處理方式 |
|---|---|---|
i/o timeout |
節點網址無法連線、連接埠遭封鎖或線路逾時 | 切換節點，並比較 Wi-Fi 與行動網路 |
connection refused |
遠端連接埠未監聽或節點已下線 | 更新訂閱，停用該節點 |
TLS handshake timeout |
線路丟包、SNI 或伺服器端 TLS 異常 | 更換節點，檢查系統時間 |
| 測速正常但網頁逾時 | 規則使用了錯誤的策略組，或目標網站限制出口 | 查看該請求的規則命中記錄 |
第四步：檢查模式與規則命中
在規則模式下，請求會由上到下進行比對，命中後不會繼續檢查後面的規則。一條範圍過大的 DOMAIN-SUFFIX、IP-CIDR 或 GEOIP 規則，可能讓目標請求進入錯誤的策略組。最後的 MATCH 或 FINAL 也必須指向實際存在且可用的群組。
使用全域模式進行短時間對照
將模式從「規則」暫時切換至「全域」，並讓全域策略選擇一個已確認可用的節點。如果網頁恢復，表示節點與基本代理鏈路大致正常，問題集中在規則命中或策略組引用。如果全域模式仍然失敗，應回到節點、DNS 或系統 VPN 層繼續排查。
全域模式只用於定位問題，不適合作為最終修復方式。確認原因後切回規則模式，開啟連線記錄，找出失敗網域對應的策略與規則。例如記錄顯示請求命中 DIRECT，但目前網路無法直接連線到該目標，就需要調整規則順序或更換規則集；若命中空的策略組，則應修正設定中的群組名稱引用。
rules:
- DOMAIN-SUFFIX,example.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY上方規則會先將 example.com 及其子網域導向 PROXY，再讓符合 GEOIP CN 的目標直接連線，其餘請求則進入 PROXY。如果把寬泛的直連規則放在目標網域規則之前，後面的規則可能永遠沒有機會命中。
第五步：區分 DNS 故障與代理故障
DNS 故障的典型表現是網域無法開啟、應用程式提示找不到伺服器，但既有連線或少數使用固定位址的服務仍能運作。Clash Meta（mihomo）常見的增強模式為 fake-ip 與 redir-host。在 iOS 的 TUN 或網路延伸功能環境中，DNS 請求還可能受到系統加密 DNS、其他 VPN 設定與區域網路劫持影響。
先查看記錄中是否有解析錯誤
no such host通常表示網域解析失敗。context deadline exceeded可能是上游 DNS 逾時，也可能是上游請求必須經過無法使用的代理組。- 只有區域網路網域失敗時，請檢查是否需要由路由器 DNS 解析，例如
192.168.1.1。 - 切換網路後恢復，通常表示原本 Wi-Fi 的 DNS、驗證狀態或 UDP 傳輸受到限制。
如果客戶端提供「設定」→「參數設定」→「DNS」之類的入口，先記錄目前值，再檢查 DNS 是否啟用、增強模式是否與設定相符，以及上游位址格式是否完整。不同客戶端的選單名稱可能有所不同；當設定由訂閱管理時，請優先修改獨立副本，避免下次訂閱更新覆蓋本機調整。
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
nameserver:
- 1.1.1.1
- 8.8.8.8
fallback:
- tls://1.1.1.1:8531053 是範例監聽連接埠，不應與其他本機 DNS 服務衝突。傳統 DNS 通常使用 UDP 或 TCP 53 連接埠，DNS over TLS 通常使用 853 連接埠。不了解訂閱結構時，不要同時修改 nameserver、fallback、proxy-server-nameserver 與 fake IP 範圍；先替換一個可連線的上游並重新測試，才能確認是哪項變更生效。
若 iPhone 安裝了獨立的加密 DNS 描述檔，可前往「設定」→「一般」→「VPN 與裝置管理」查看。排查期間可暫時停用其他 DNS 或 VPN 設定，只保留目前的 Clash 網路延伸功能。測試完成後再恢復原本設定。
第六步：檢查 iOS VPN 與 TUN 狀態
iOS 通常同一時間只允許一條主要 VPN 通道接管流量。企業 VPN、其他代理客戶端、內容過濾器或安全軟體可能與 Clash 的網路延伸功能衝突。狀態列出現 VPN 標記，只能證明某個 VPN 設定處於啟用狀態，不能據此判定目前生效的是哪一個設定。
在系統設定中核對目前設定
- 開啟「設定」→「一般」→「VPN 與裝置管理」→「VPN」。
- 確認目前的連線項目屬於正在使用的 Clash 客戶端。
- 中斷其他 VPN，關閉其他代理客戶端的隨選連線。
- 返回 Clash，先關閉代理，等待 5 秒後再重新開啟。
- 若仍卡在連線狀態，請重新啟動 iPhone，之後只啟動 Clash，不要同時開啟其他網路工具。
使用 TUN 模式時，客戶端需要建立虛擬網路介面並接管相應流量。設定中的路由排除項目過寬，可能讓請求繞過 TUN；過窄則可能影響區域網路裝置存取。若只有印表機、NAS 或路由器管理頁面無法開啟，請檢查是否保留區域網路位址直連，例如 10.0.0.0/8、172.16.0.0/12 與 192.168.0.0/16。
若問題只發生在行動網路，請進入「設定」→「行動服務」，確認 Clash 客戶端可以使用行動數據。雙 SIM 裝置還應確認目前的數據線路已正常註冊。切換 SIM 數據線路後，先中斷再重新建立 VPN，讓網路延伸功能取得新的預設路由。
第七步：利用記錄將故障定位到具體層級
完成前面的對照後，記錄通常能將問題縮小至明確階段。開啟客戶端的連線或記錄頁面，清除舊記錄，然後只造訪一個測試網域。記下時間、網域、命中規則、策略組、節點名稱與最終錯誤。不要同時開啟多個應用程式，否則背景請求會迅速淹沒目標記錄。
依請求階段讀取記錄
- 沒有任何請求記錄：流量可能沒有進入 Clash。請檢查 VPN 設定、TUN 狀態與應用程式網路權限。
- 有網域但無法解析：請檢查 DNS 上游、加密 DNS 設定與 DNS 相關記錄。
- 已顯示規則命中：核對命中的策略組是否符合預期。
- 已選擇節點但連線逾時：切換節點與網路，判斷是節點失效還是目前線路遭到阻斷。
- 建立 TCP 後出現 TLS 錯誤：檢查系統時間、目標網域、節點線路與憑證提示，不要直接接受來源不明的憑證。
如果客戶端支援記錄層級，排查時可以暫時從 info 調整至 debug，重現一次後立即調回。持續使用 debug 會產生大量記錄，也會讓真正關鍵的錯誤更難篩選。提交問題時，請隱藏訂閱網址、驗證資訊、節點密碼與個人網域，只保留錯誤類型與必要的上下文。
最終清單：依結果決定下一步
- 關閉 Clash 也無法上網：先處理 Wi-Fi 登入、行動數據權限或系統網路。
- 訂閱更新出錯：核對訂閱權限、回傳內容與設定格式。
- 手動節點可用、自動群組不可用：檢查測試網址、群組類型與測試間隔。
- 全域模式可用、規則模式不可用：查看請求命中結果並調整規則順序。
- 網域失敗且記錄出現解析逾時：檢查 DNS 上游與系統加密 DNS。
- 沒有請求記錄：檢查 iOS 目前的 VPN 設定，以及 TUN 是否確實接管流量。
- Wi-Fi 失敗、行動網路正常：檢查公共網路驗證、路由器 DNS 與連接埠限制。
- 所有節點都連線逾時：更新訂閱，並向節點服務提供方確認線路狀態。
最有效的排查順序是先進行關閉與開啟對照，再驗證訂閱與節點，接著檢查規則、DNS，最後處理系統 VPN。每一步只變更一個變數，並用相同網站重新測試。如此可避免將節點故障誤判為 DNS 問題，也不會因一次重置所有設定而失去可重現的線索。