先分辨延遲測試失敗與實際連線失敗

Clash 用戶端中的「逾時」，通常表示某次請求未能在指定時間內完成，不代表訂閱一定失效。延遲測試會透過指定節點連線至測試網址；節點交握、網域名稱解析或測試網站回應，其中任何一個環節失敗，都可能顯示逾時。Clash 是用戶端生態系的通稱，實際介面與功能取決於用戶端及正在執行的核心；mihomo 也常出現在使用 Clash Meta 名稱的設定說明中。

先釐清故障範圍：是所有節點的延遲測試都失敗，還是只有一個策略組失敗；是測試失敗但網頁仍可開啟，還是所有代理請求都失敗；問題是在更新設定後，還是切換 Wi-Fi 後才出現。記下這些資訊，比連續按幾十次測速更有幫助。

  1. 先暫停批次測速，手動選擇一個節點；若使用規則模式，請確認目標請求確實套用到該節點所在的策略組。
  2. 開啟用戶端的「連線」與「日誌」頁面，再瀏覽一個已知可正常連線的 HTTPS 網頁，記下同一時間的目標網址、套用的規則與錯誤訊息。
  3. 若網頁能正常瀏覽，但所有測速都失敗，請優先檢查測試網址、測試逾時時間與並行數量，不要急著重新安裝用戶端。

第一步：確認本機網路與訂閱狀態

先排除登入驗證與網路切換問題

暫時關閉系統代理與 TUN，確認一般直連網站能否正常開啟。飯店、校園與公共 Wi-Fi 可能要求先透過網頁完成驗證；驗證前，即使無線網路圖示顯示正常，所有節點仍可能無法連線。可用手機熱點進行對照：維持相同設定、節點與目標，只切換網路。若熱點可用而原網路不行，請繼續檢查原網路的 DNS、出口限制或路由器。

訂閱更新成功，不代表服務仍可使用

  • 帳戶狀態：前往服務供應商網站確認到期日、剩餘流量，以及裝置數或同時連線數限制，並留意網站顯示時間所採用的時區。
  • 更新結果：檢查訂閱更新紀錄與節點數量。HTTP 401、403 通常與憑證或存取限制有關，429 則表示請求可能受到頻率限制；實際原因仍須參考伺服器端提示。
  • 是否已載入設定：下載成功只代表取得檔案，還要確認目前啟用的是新設定，且核心沒有因欄位錯誤而拒絕載入。
  • 節點來源：不同地區的節點可能共用同一個入口網域。「全部逾時」也可能是共用入口故障，而非每台伺服器同時損壞。

若更新訂閱本身需要透過代理，失效線路可能導致更新不斷失敗。可在服務供應商支援的網路環境中更新，或使用供應商提供的本機設定匯入方式。訂閱 URL 通常含有存取憑證，請勿貼到公開測速網站、轉換服務或討論區。

第二步：校準系統時間並檢查交握條件

TLS 憑證有效期限檢查，以及部分協定的驗證機制，都依賴系統時鐘。裝置休眠後時間異常，或手動設定錯誤日期，都可能導致多個節點同時連線失敗。不要只看工作列上的時分，還要一併確認日期、年份、時區與自動同步結果。

  • Windows 11：前往「設定」→「時間與語言」→「日期與時間」，開啟「自動設定時間」，確認時區後按一下「立即同步」。
  • macOS：前往「系統設定」→「一般」→「日期與時間」，啟用自動設定日期與時間；不同系統版本的選項名稱可能略有差異。
  • Linux：執行 timedatectl status，查看系統時鐘同步狀態；使用 systemd 的系統可依照本機管理規範啟用時間同步服務。

例如，日誌出現 x509: certificate has expired or is not yet valid 時，請先將系統時間與可信任的時間來源比對。校時後仍出現相同錯誤，才繼續檢查伺服器憑證。不要透過關閉憑證驗證來掩蓋問題；skip-cert-verify 也無法修正錯誤密碼、無法連線的連接埠或不相符的協定參數。

第三步：檢查核心啟動狀態與連接埠占用

節點清單顯示正常，不代表代理核心已正常執行。圖形介面可能已讀取設定，但核心啟動時可能因連接埠遭占用而停止。先在用戶端日誌中搜尋啟動失敗、設定解析錯誤及 address already in use，再確認實際監聽的連接埠。

以下以本機混合代理連接埠 7890 為例；這只是範例值，並非所有用戶端的固定設定。請先從用戶端的連接埠設定或生效中的設定讀取 mixed-port、port、socks-port。控制介面有時使用 9090，此連接埠用於管理核心，不應填入瀏覽器的 HTTP 代理連接埠。

查看是哪個程式占用 7890

在 Windows 中，可透過 PowerShell 查看監聽位址與處理程序 ID，再查詢對應的程式：

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

Get-Process -Id 1234

第二個指令中的 1234 僅為示範，請替換成第一個指令實際回傳的處理程序 ID。macOS 與常見的 Linux 系統可使用：

lsof -nP -iTCP:7890 -sTCP:LISTEN

若監聽中的程式是另一款代理用戶端，請先正常結束該程式，再啟動目前的用戶端；不要直接終止不明的系統處理程序。若改用 7891，應用程式中的手動代理設定也必須一併修改。平時僅供本機使用時，維持監聽回送位址即可，無須為了排查而啟用區域網路存取。

第四步：透過明確指定代理的請求縮小範圍

暫時關閉 TUN，並手動選定一個節點。透過指定的本機代理位址傳送請求，可排除「應用程式是否遵循系統代理」的不確定因素，但請求仍會受到核心目前模式與規則影響。測試時請開啟連線面板，確認流量沒有被規則分流至 DIRECT。

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 5 --max-time 15 \
  --output /dev/null --write-out "%{http_code}\n" \
  https://cp.cloudflare.com/generate_204

此指令適用於 macOS 或 Linux shell。Windows PowerShell 可使用下方單行指令，明確呼叫 curl.exe：

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 --output NUL --write-out "%{http_code}\n" https://cp.cloudflare.com/generate_204
  • 回應 204：表示這次透過本機代理成功連線至目標；仍須在連線面板確認實際套用的策略與出口。
  • 立即拒絕連線：先檢查本機連接埠、監聽位址與核心處理程序。若本機連線已建立，拒絕也可能發生在後續的遠端連線階段，請配合日誌判斷。
  • 等待後逾時：檢查遠端連線、DNS、交握與測試目標，不要只憑 curl 的結果判定特定協定故障。

特定線路也可能限制測試網址，因此應改用另一個已知可正常連線的 HTTPS 目標交叉驗證。若測試逾時設為 1000 毫秒，可暫時調高至 5000 毫秒，依序測試兩次；這只是排查範例，並非通用建議值。延長逾時只會增加等待時間，無法修正驗證錯誤或失效的入口。

第五步：依據日誌關鍵字判斷 DNS、驗證與協定問題

先將日誌等級暫時設為 info，資訊不足時再切換至 debug。只重現一次請求，並依時間篩選相關紀錄。排查完成後請恢復原本等級，避免持續產生大量日誌。分享日誌前，請移除訂閱網址、密碼、權杖及其他帳戶資訊。

日誌線索 優先檢查項目 下一步處理方式
lookup、no such host 節點入口網域或目標網域解析失敗 先確認正在解析哪個網域，再檢查 DNS 上游是否可連線，以及節點網域是否仍有效。
i/o timeout、context deadline exceeded 連線或請求逾時 依據前後日誌區分 DNS、TCP、TLS 等階段，再切換網路進行比對。
connection refused 目標位址的連接埠未接受連線 確認拒絕發生於本機還是遠端，並檢查連接埠設定與服務狀態。
authentication failed 驗證資訊或協定參數不相符 更新原始訂閱並核對憑證，不要只手動修改節點顯示名稱。
TLS handshake、x509 時間、憑證、SNI 或交握流程 先校準系統時間，再確認設定中的伺服器名稱及伺服器端要求。
unsupported、unknown proxy type 核心不支援該協定或設定欄位 確認實際執行的核心類型與版本，並使用與訂閱相容的用戶端。

入口解析與目標解析是兩回事

節點伺服器網域必須先正確解析，核心才能連線至入口；瀏覽器所存取網站的網域則屬於後續的目標解析。兩者可能採用不同的解析路徑。若節點入口解析已失敗，反覆調整網站分流規則通常無濟於事。可使用 nslookup 查詢自己的入口網域，但系統查詢成功，也不代表核心的 DNS 設定正常。

mihomo 的 DNS 設定可能涉及 nameserver、default-nameserver 與 proxy-server-nameserver；實際支援範圍請以目前使用的核心文件為準。不要強制將所有 DNS 請求送入尚未連線的代理，以免造成解析與連線互相依賴的循環。

整組核對協定參數

舊版 Clash 核心的功能範圍不能直接比照 mihomo。設定包含 Hysteria2 等協定時，請確認執行中的核心支援該協定。採用 UDP 的傳輸方式也可能受到目前網路限制：若 TCP 類型的節點可用，但這類節點全部失敗，改用手機熱點比盲目修改密碼更有助於判斷問題。伺服器連接埠、驗證資訊、SNI、傳輸方式等設定應以原始訂閱為準；轉換後的設定可能遺漏欄位。

第六步：基本代理恢復後，再排查 TUN 與規則

若明確指定代理的請求已成功，但開啟 TUN 後才失敗，問題應轉向路由、權限、DNS 接管及其他虛擬網路介面。TUN 接管的是系統網路流量，不是提高節點連線能力的開關。它無法讓過期帳戶恢復，也無法修正伺服器的錯誤連接埠。

  1. 先結束其他 VPN、代理用戶端及可能修改路由的軟體，避免多個流量接管元件同時運作。
  2. 依照用戶端要求確認服務模式或系統權限，再單獨啟用 TUN，並保留連線日誌。
  3. 檢查 DNS 請求是否正確接管，以及代理伺服器本身的連線是否被錯誤地再次導入隧道。
  4. 若只有在 TUN 模式下瀏覽部分 HTTPS 網站時卡住，再考慮路徑 MTU 等問題；記下原始值後逐項測試，不要將調整 MTU 當成所有逾時問題的首選解法。

使用規則模式時，也要確認實際選用的策略組。某個 select 組可能選到另一個自動策略組，而自動組仍在使用舊的測試結果。直接選擇特定節點並查看連線路徑，可減少巢狀策略組造成的判斷困難。也可暫時切換至全域模式進行對照，但測試結束後應恢復原模式，避免改變其他應用程式的流量路徑。

記錄排查結果並依序還原設定

問題仍未解決時，只提供「全部逾時」四個字，通常不足以判斷原因。請整理以下資訊，方便向服務供應商確認入口狀態，也便於用戶端維護者判斷是否為核心或系統流量接管問題。

  • 作業系統版本、用戶端版本，以及實際核心名稱與版本；請從本機的「關於」頁面或啟動日誌查詢。
  • 記錄故障開始時間，以及此前是否更新訂閱、升級系統、切換網路或啟用 TUN。
  • 記錄相同節點在原網路與手機熱點下的結果，以及明確指定代理請求的回應情況。
  • 提供一段包含錯誤前後文且已遮蔽敏感資訊的日誌，並註明目標請求時間、是否使用 TUN，以及實際套用的策略組。

還原時，先確認一個節點能透過明確指定的代理完成請求，再測試系統代理，最後才啟用確有需要的 TUN 與自動策略組。依照「本機網路與帳戶 → 系統時間 → 核心與連接埠 → DNS 與交握 → 流量接管與規則」的順序排查，可將入口故障、測試誤報與本機設定問題分開處理。若需要重新選擇相容的用戶端，請前往Clash 用戶端下載中心；匯入方式與基本設定請參閱使用教學。