故障排查 預計閱讀 8 分鐘

Clash 節點超時無法連線怎麼排查:從訂閱、連接埠到協議的檢查順序

節點全部超時不等於節點失效。按訂閱有效性、本機連接埠占用、系統代理開關、協議與核心匹配、DNS 汙染五層逐一排查,定位到底是設定問題還是連線問題,並提供每層對應解法。

排查前先判斷問題範圍

看到延遲欄一片"超時"或"timeout"時,第一反應往往是懷疑節點失效或訂閱到期,但這只是眾多可能原因之一。更常見的情況是本機環境出了問題:連接埠被占、系統代理沒生效、核心版本與協議不匹配、DNS 解析被汙染。這些問題會讓延遲測試整批失敗,表現和"節點全滅"幾乎一樣,卻和節點本身沒有任何關係。

建議先做一個最小判斷:打開系統的瀏覽器,直接存取一個海外站點,如果連不通且沒有走代理的跡象,大概率是連線層沒打通;如果代理軟體介面顯示"已連線"但網頁依舊轉圈,再往下逐層排查。避免一上來就換訂閱、刪節點,那樣只會把簡單問題複雜化。

第一層:訂閱有效性檢查

訂閱連結本身失效是最容易被忽略的一層,尤其是免費或到期未續費的訂閱。判斷方法很直接:

  • 在客戶端裡手動點擊"更新訂閱",觀察是否傳回節點數量變化或報錯提示。
  • 把訂閱連結貼到瀏覽器網址列直接存取,若傳回的是空文字、404 或一段錯誤 JSON,說明伺服端已經失效,而不是本機設定問題。
  • 查看訂閱到期時間與剩餘流量,部分面板會把這兩項塞進 Subscription-Userinfo 回應標頭裡,客戶端介面通常會展示。

如果訂閱確實失效,後面幾層再怎麼排查都不會有結果,先聯絡服務商或更換有效訂閱連結是唯一出路。訂閱正常但節點仍超時,再進入下一層。

第二層:本機連接埠占用與監聽狀態

Clash 核心會監聽一組本機連接埠:HTTP 代理連接埠、SOCKS5 連接埠,以及用於面板通訊的外部控制連接埠(預設 9090)。如果這些連接埠被其他程式占用,核心會啟動失敗或代理功能不完整,表現出來就是節點看似在線但流量根本沒有經過它。

排查方法:

  1. 查看客戶端設定裡的連接埠號,記下 HTTP 連接埠(常見 7890)與混合連接埠(常見 7891)。
  2. 用系統命令檢查該連接埠是否被其他行程占用,Windows 下用 netstat -ano | findstr 7890,macOS/Linux 下用 lsof -i:7890。
  3. 若發現被占用,關閉衝突程式,或在客戶端設定裡把連接埠改成未被占用的號段,重啟客戶端後重試。

同一台電腦同時運行兩個代理工具是常見誘因,例如另一款翻牆工具的行程沒有完全退出,殘留在背景繼續占用連接埠。

第三層:系統代理與 TUN 模式開關

連接埠正常監聽不代表流量真的會流向 Clash。系統層面的代理開關同樣關鍵:

  • 系統代理模式:客戶端會自動寫入系統的 HTTP/HTTPS 代理設定,如果這個開關被誤關閉,瀏覽器與大多數應用程式會直接繞過 Clash,走原始網路出去。檢查客戶端介面的"系統代理"開關是否處於開啟狀態。
  • TUN 模式:TUN 模式透過虛擬網卡在系統網路層接管全部流量,不依賴單個應用程式的代理設定,適合處理不遵循系統代理的程式。開啟 TUN 模式在部分系統上需要額外授權(網路擴充功能權限、管理員權限),如果授權被拒絕,TUN 會啟動失敗但介面未必給出明顯提示。
  • 某些應用程式不走系統代理:命令列工具、部分遊戲客戶端不讀取系統代理設定,這類場景必須依賴 TUN 模式或單獨設定該程式的代理參數。
提示

判斷流量是否真的經過 Clash,可以打開客戶端的連線面板(Connections),存取網頁時觀察是否出現對應的連線記錄。沒有記錄出現,說明流量根本沒有進入 Clash,問題在這一層,而不是節點。

第四層:協議與核心匹配

Clash 原版核心只支援有限的幾種代理協議,而 Clash Meta(即 mihomo)擴充支援了 Hysteria、Hysteria2、TUIC、VMess 的部分變體等更多協議。如果訂閱裡包含了原版核心不認識的協議類型,對應節點會直接被標記為不可用或延遲測試恆定超時,這不是網路問題,是核心能力不足導致的。

排查方法:

  1. 確認客戶端底層使用的核心版本,大多數現代客戶端(如 Clash Verge Rev、FlClash、Clash Plus)預設已經切換到 Meta/mihomo 核心。
  2. 查看訂閱節點清單中的協議欄位,如果出現 hysteria2、tuic 等關鍵字,而客戶端仍在使用舊版原生 Clash 核心,需要更換支援這些協議的客戶端。
  3. 協議本身對網路環境也有要求,例如基於 QUIC 的協議在部分網路下會被電信業者針對性限速或阻斷,表現為該協議節點普遍超時,而其他協議節點正常,這種情況需要換用其他協議的節點,而不是繼續排查本機設定。

第五層:DNS 汙染與解析異常

就算前四層全部正常,DNS 解析環節出問題同樣會讓節點表現為超時。原因在於:客戶端在測速或建立連線前,需要先把節點的網域名稱解析成 IP 位址,如果這一步被汙染,解析結果就是錯誤 IP 或空結果,後續連線自然失敗。

常見處理方式:

  • 在設定檔的 dns 欄位裡啟用 enhanced-mode: fake-ip,並設定可信的上游 DNS(如加密 DoH/DoT 伺服器),避免走本機預設的、可能被汙染的 DNS。
  • 檢查 nameserver 清單是否包含臺灣本地電信業者預設 DNS,如果有,替換為獨立的加密解析位址。
  • 開啟 TUN 模式後,DNS 請求同樣會被接管,若仍解析異常,檢查 TUN 設定區塊裡的 dns-hijack 設定是否正確劫持了 53 連接埠的請求。
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-range: 198.18.0.1/16

設定好上游 DNS 後重啟核心生效,再次測速觀察節點延遲是否恢復正常數值。

五層排查順序小結

整理成一句話:先確認訂閱本身能不能拉到資料,再確認連接埠沒被占用、系統代理或 TUN 有沒有真正接管流量,然後檢查協議是否被目前核心支援,最後排查 DNS 解析是否被汙染。這五層從"外部資料源"到"本機網路堆疊"層層遞進,任何一層出問題都會造成表面一致的"全部超時"現象,但對應的解法完全不同,按順序排查能避免在錯誤的方向上反覆折騰設定檔。

如果按以上五層逐一核對後節點依舊超時,可以換一個網路環境測試(如手機熱點),用於隔離本機與所在網路環境的干擾因素,進一步縮小問題範圍。

下載客戶端