Clash 節點超時無法連線怎麼辦:依序排查訂閱、連接埠與協定參數
節點全部超時或個別超時的成因不同。依訂閱有效性、本機測速方式、連接埠與協定參數、系統時間與防火牆的順序逐項排查,提供每一步的判斷依據與對應解決辦法。
節點超時是使用 Clash 及 mihomo 核心時最常見的故障現象,但「超時」背後對應的原因並不單一。同樣的紅色驚嘆號或 timeout 提示,可能來自訂閱本身失效、本機測速方式不準確、連接埠與協定參數寫錯,也可能是系統時間偏差或本機防火牆擋掉了交握封包。逐一排查前,先做一次分類判斷,能省去大半白費的操作。
B-01先分清是全部超時還是個別超時
打開節點列表,觀察超時節點的分布範圍,這一步決定了接下來該往哪個方向排查。
- 全部節點超時:通常指向本機網路環境問題、訂閱整體失效、系統時間偏差,或本機防火牆/安全軟體的整體阻擋,而不是某個節點本身壞掉。
- 個別節點超時,其餘正常:大機率是對應節點的伺服器端已下線、該節點的協定參數與伺服端不匹配,或該節點所在的中轉線路本身不穩定。
- 時好時壞,反覆波動:多見於測速方式本身不準確,或是伺服端在高峰時段限速,並不代表節點徹底失效。
注意 NOTE
在還沒分類清楚前,不要急著重新匯入訂閱或刪除節點重建設定——這類操作會掩蓋真正的原因,導致下次出現同樣問題時又要從頭排查一遍。
B-02訂閱有效性排查
如果是全部節點超時,先確認訂閱本身是否仍然有效,這是最容易被忽略、但發生機率最高的一環。
- 打開客戶端的訂閱管理頁面,查看訂閱的到期時間與剩餘流量。多數訂閱在流量用盡或套餐到期後,機場端會直接拒絕所有連線請求,表現出來就是全部節點超時。
- 手動點擊「更新訂閱」,觀察節點數量是否有變化。若更新後節點數變成 0 或列表是空的,表示訂閱連結已經失效或被伺服端下架。
- 在瀏覽器中直接開啟訂閱連結(去掉客戶端專用的請求標頭限制後),確認回傳的是正常的 Base64 或 YAML 文字,而不是一段錯誤頁面或空白回應。若回傳 403、404 或空內容,問題出在訂閱來源而不是客戶端設定。
- 檢查訂閱連結是否包含到期參數或臨時授權 Token,部分機場的訂閱連結有使用期限,過期後需要在後台重新產生。
訂閱本身正常但節點仍全部超時,再繼續往下排查測速方式與本機環境;若訂閱確認失效,直接聯繫服務商更新連結即可,不需要再檢查客戶端設定。
B-03本機測速方式核驗
客戶端介面顯示的延遲數值,取決於測速方式本身是否合理。測速方式不當,會導致節點其實可用卻被誤判為超時。
- 測速位址選擇:多數客戶端預設使用
http://www.gstatic.com/generate_204或類似的連通性檢測位址。若本機網路對該網域本身連線不穩定,測出的延遲就會失真,可在設定中換成其他探測位址再對比一次。 - 測速協定差異:TCP 延遲測試與實際代理流量所走的協定(如 Shadowsocks、VMess、Trojan、Hysteria2)交握方式不同,TCP 層面顯示正常,不代表代理協定層面一定能建立連線,這也是「測速正常但開網頁還是慢或超時」的常見原因。
- 並發測速的干擾:一次性對全部節點批量測速時,本機頻寬與並發連線數會互相排擠,導致排在後面的節點測速結果偏高。建議先對單一懷疑節點單獨測速,再下結論。
curl -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204 -I -m 5此指令會透過本機代理連接埠發出一次連通性請求,若回傳 HTTP/1.1 204,表示目前選中的節點與本機代理線路皆正常,超時提示更可能出在客戶端介面測速邏輯本身;若指令本身也卡住或報錯,表示問題確實發生在代理線路上,繼續往下排查連接埠與協定參數。
B-04連接埠與協定參數核查
個別節點長期超時,且排查過訂閱與測速方式後依然如此,大多是該節點的連線參數與伺服端設定不一致。
- 核對連接埠號:打開節點詳情,確認連接埠號與機場後台提供的資訊完全一致。手動訂閱或自架節點時,複製貼上過程中多一位或少一位數字是最常見的低級錯誤。
- 核對協定與加密方式:Shadowsocks 需要確認加密方式(如
aes-256-gcm、chacha20-ietf-poly1305)與伺服端一致;VMess 需要核對 UUID、AlterId(新版本通常為 0)與傳輸方式(TCP/WS/gRPC);Trojan 與 Hysteria2 需要核對 SNI 與憑證驗證選項是否與伺服端設定相符。任何一項寫錯,現象都是交握失敗、表現為超時。 - 核對傳輸層設定:若節點使用 WebSocket 或 gRPC 傳輸,還需檢查 Path、Host 標頭是否與伺服端一致。這類參數在手動解析訂閱連結時,偶爾會被截斷或轉義錯誤。
- 核對 TLS/SNI 設定:啟用 TLS 的節點若 SNI 填錯或指向了未備案、已被封鎖的網域,同樣會在交握階段直接超時,現象與連接埠錯誤幾乎無法從介面上分辨,需要逐項核對設定檔。
注意 NOTE
手動修改設定檔後,建議先用客戶端自帶的「設定驗證」或重新載入功能確認 YAML 語法無誤,再進行連線測試,避免把語法錯誤誤判為網路問題。
B-05系統時間與本機防火牆排查
前面幾步都沒查出問題,但仍然全部超時的話,系統層面有兩個容易被忽略的環境因素。
- 系統時間偏差:多數加密代理協定(尤其是 Shadowsocks 的 AEAD 加密與 VMess 的時間戳驗證)依賴用戶端與伺服端的系統時間大致同步。若本機系統時間偏差超過一定範圍,伺服端會直接拒絕交握,表現為所有節點同時超時。檢查系統時間是否已啟用「自動與網路時間同步」,並手動核對時區設定是否正確。
- 本機防火牆與安全軟體:部分安全軟體或系統內建防火牆會擋住或限速 Clash 監聽的本機連接埠(如
7890混合連接埠、TUN 模式虛擬網卡)。可暫時關閉安全軟體的網路防護模組做對照測試,若關閉後恢復正常,再逐條加入對應的放行規則,而不是長期關閉防護。 - TUN 模式的驅動權限:若使用 TUN 模式接管全域流量,虛擬網卡驅動需要系統管理員/root 權限才能正常建立。權限不足時,流量可能仍走系統代理路徑而非 TUN,導致部分應用程式連線異常,排查時可先切回系統代理模式做對照。
- 路由器或上層網路限制:部分家用寬頻或公司網路會針對特定連接埠範圍進行限速或封鎖,若確認本機所有設定皆無誤,可嘗試更換網路環境(如手機熱點)進行交叉驗證。
B-06排查順序小結
整理成表格,方便依序逐項核對,避免遺漏或重複操作。
| 現象 | 優先排查方向 | 判斷依據 |
|---|---|---|
| 全部節點同時超時 | 訂閱有效性、系統時間、本機防火牆 | 更新訂閱後節點數是否異常;系統時間是否已同步 |
| 個別節點長期超時 | 連接埠與協定參數 | 逐項核對連接埠、加密方式、SNI 是否與伺服端一致 |
| 時好時壞反覆波動 | 測速方式、伺服端限速 | 單獨測速對照;更換探測位址複測 |
| 瀏覽器能上網但個別應用程式不通 | TUN 模式權限、程序規則 | 切回系統代理模式做對照測試 |
依上述順序排查一遍後,絕大多數超時問題都能定位到具體環節。若最終確認是伺服端節點本身下線或限速,更換機場或聯繫服務商是唯一有效的解決辦法,客戶端本機設定無法解決伺服端側的問題。
按圖施工:下載 Clash 客戶端
排查設定前,先確認使用的是正規管道取得的客戶端版本,避免因客戶端本身異常而導致誤判。