Clash 節點超時連不上?按這個排查順序逐項定位問題

NT-04.1先確認現象範圍,別急著換節點

「節點超時」是個籠統的說法,背後可能是完全不同的故障點。動手排查前,先花一分鐘確認現象範圍,能省下大量無效操作。核心是回答三個問題:是所有節點都超時,還是只有部分節點超時?是所有軟體都連不上,還是瀏覽器能上、命令列工具連不上?延遲測試(Latency)能測出數字,還是直接顯示超時符號?

如果只有部分節點超時,其餘節點正常,大機率是那些節點本身的伺服器問題或線路壅塞,直接切換到延遲正常的節點即可,不必再往下排查。如果是全部節點同時超時,且延遲測試欄位直接空白或顯示超時,問題往往出在本機網路、訂閱資料或客戶端設定上,這時才需要按下面的順序逐項核對。

NT-04.2第一步:本機網路與系統代理設定

排查順序遵循「由近到遠」的原則——先查離自己最近、最容易驗證的環節,再往訂閱、協定這類需要更多操作的環節推進。第一步永遠是本機網路本身。

1. 確認裝置本身能正常存取網際網路:暫時關閉 Clash 客戶端的代理開關,直接用系統網路開啟任意網頁,確認不是斷網或本地網路故障。
2. 檢查客戶端的系統代理開關是否已經開啟。部分客戶端預設不會自動設定系統代理,代理服務在跑,但流量並未真正經過它,瀏覽器請求走的仍是直連。
3. 確認代理模式設定。規則模式(Rule)下,某些直連規則會讓流量繞開節點;若懷疑是規則問題,可暫時切到全域模式(Global)測試,若全域模式下正常,說明問題出在規則設定而非節點本身。
4. 檢查本機防火牆或安全軟體是否攔截了客戶端的網路請求,尤其是剛安裝的防毒軟體或系統內建防火牆的出站規則。

這一步能排除掉相當一部分「偽超時」——客戶端明明在跑,但流量根本沒走代理,延遲測試自然測不出正常結果。

NT-04.3第二步:訂閱是否仍然有效

確認本機網路無誤後,下一步查訂閱本身。訂閱連結指向的是一份設定檔,內含節點清單、伺服器位址、埠與認證資訊。這份資料若過期或錯誤,所有節點自然全部超時,與節點伺服器狀態無關。

1. 查看訂閱在客戶端裡顯示的最近更新時間。若已超過訂閱方標註的有效週期,說明這份設定可能已經失效,需要手動點一次更新訂閱。
2. 確認訂閱流量或到期時間尚未耗盡。多數訂閱方案有用量或時長限制,一旦超出,伺服端會直接拒絕新連線,表現為節點全部超時。
3. 重新匯入一次訂閱連結,而不是依賴客戶端的自動更新。有些客戶端的自動更新間隔較長,手動強制刷新能立刻取得最新設定。
4. 打開設定檔詳情,核對節點數量與名稱是否與訂閱方頁面上的說明一致。數量驟減或名稱變成亂碼,通常代表訂閱位址本身出了問題。

NT-04.4第三步:協定參數與握手細節

訂閱資料確認無誤、節點清單正常之後,如果超時依舊存在,就要進入協定層面核對。Clash 支援的節點協定(如 Shadowsocks、VMess、Trojan、Hysteria2 等)每一種都有各自的握手流程,任何一項參數寫錯都會導致連線建立失敗,客戶端側統一表現為超時,不會給出具體錯誤原因。

1. 核對伺服器位址與埠是否與訂閱方最新說明一致。部分服務商會不定期更換出口 IP 或埠,而舊的本地快取設定沒有同步更新。
2. 檢查加密方式(cipher)、傳輸協定(如 ws、grpc、tcp)等欄位是否與伺服端設定相符。這些欄位任一不對,握手階段就會卡住直至超時。
3. 若節點使用了 TLS 或 SNI 偽裝,確認證書網域與 SNI 欄位填寫正確。證書驗證失敗通常也表現為連線超時或直接斷開,而不是明確的證書錯誤提示。
4. 查看客戶端的日誌面板(多數客戶端在設定或工具選單裡能找到即時日誌),日誌裡往往會有 dial tcp: i/o timeout、context deadline exceeded 之類的原始訊息,比介面上的「超時」圖示更有參考價值。

time="2026-07-10T14:02:11+08:00" level=warning msg="[TCP] dial ss-node-hk failed: dial tcp 203.0.113.10:443: i/o timeout"

看到這類日誌,基本可以確認問題出在與該伺服器的網路連通性或參數匹配上,而非客戶端本身故障。

NT-04.5第四步:埠佔用與本地衝突

若協定參數核對無誤,節點依然全部超時,就需要排查本機埠層面的衝突。Clash 及其核心程式需要佔用幾個本地埠——HTTP 代理埠、SOCKS5 代理埠、混合埠以及控制面板埠(如常見的 7890、7891、9090)。這些埠被其他程式佔用或被系統權限攔截時,代理服務實際上沒有正常監聽,表現出來也是連線超時。

1. 檢查是否同時執行了另一個代理軟體或 VPN 客戶端,兩者爭搶同一埠時,後啟動的一方往往會靜默失敗。
2. 確認埠號沒有被系統或其他服務佔用。可以在系統命令列裡查看埠佔用情況(Windows 用 netstat -ano,macOS/Linux 用 lsof -i:埠號),確認監聽的行程確實是目前的 Clash 核心。
3. 若最近修改過設定檔裡的埠設定,確認客戶端介面顯示的埠與設定檔中的埠一致,重新啟動一次客戶端讓變更生效。
4. TUN 模式下遇到超時,額外檢查虛擬網卡是否正常建立、路由表是否被其他網路工具覆蓋,這部分排查方法可參考站內 TUN 模式相關的教學說明。

NT-04.6第五步:策略組與節點選擇邏輯

走到這一步,若前面四項都排除了問題,還剩最後一個容易被忽視的環節——策略組(Proxy Group)的選擇邏輯。Clash 的策略組決定了實際流量走哪個節點,常見類型有 select(手動選擇)、url-test(自動測速選優)、fallback(故障轉移)和 load-balance(負載平衡)。若策略組目前選中的節點本身就是失效節點,瀏覽體驗會表現為超時,而節點清單裡其他節點的測速卻是正常的。

1. 打開策略組面板,確認目前生效的策略組實際選中的節點,而不是只看策略組名稱。
2. url-test 類型的策略組會按設定的測速位址與間隔自動切換,若測速位址本身在特定網路環境下不可達,自動選擇的結果可能不準確,可以暫時切換成手動選擇一個已知延遲正常的節點做對比。
3. 檢查規則集裡是否有網域或應用程式被錯誤指向了一個空的或已失效的策略組,這種情況在自訂規則較多的設定裡比較常見。
4. 若使用了多個訂閱合併的設定,確認沒有節點重名導致策略組引用了錯誤的那一個。

把這五步走完,基本可以覆蓋 Clash 場景下「節點超時」的絕大多數成因。排查順序按由近到遠設計,是為了避免走彎路:多數人第一反應是懷疑節點或訂閱商,但實際上本機網路設定與埠衝突這類本地問題佔了不小的比例,而這些問題往往幾分鐘就能確認排除。

NT-04.7排查小結

若按以上順序逐項核對後問題依舊存在,建議保留客戶端日誌面板中的原始錯誤訊息,這些訊息比介面上的「超時」提示更具體,也更方便進一步定位是網路環境問題還是設定本身的問題。