Clash 速度慢怎麼排查:節點、線路、本機設定三層定位法

為什麼要分層排查,而不是直接換節點

速度慢幾乎是所有代理工具都會遇到的抱怨,但「慢」背後的原因分布在三個完全不同的位置:節點本身的品質、從你的裝置到節點之間的傳輸線路,以及本機客戶端的設定。很多人一遇到卡頓就切換節點,換了三五個還是慢,便斷定「這個訂閱不行」,其實問題可能一直卡在本機的 DNS 設定或規則比對上,跟節點根本沒關係。

盲目換節點有兩個代價:一是浪費流量倍率較高的付費節點額度,二是掩蓋了真正的故障點,下次同樣的問題還會再發生。按層排查的好處是每一層都有明確的測試動作與判斷標準,做完一層就能排除或鎖定一類原因,大約十分鐘就能把範圍收斂到具體環節。

第一層:節點品質檢測

節點品質指的是代理伺服器本身的回應速度、負載狀況與線路頻寬,和本機設定無關。這一層最容易驗證,也是最該先排除的一層。

1. 看延遲數值,別只看顏色

大多數 Clash 客戶端(包括基於 Clash Meta 核心 mihomo 的客戶端)在節點清單裡都有延遲測試按鈕,點擊後每個節點會顯示一個毫秒數。判斷標準大致如下:

延遲測試測的是「連線回應時間」,不是下載速度,但兩者高度相關:延遲長期偏高的節點,下載速度基本不會好。如果延遲正常但實際下載仍然慢,說明問題不在這一層,可以跳到第二層繼續查。

2. 換 2~3 個不同地區的節點交叉驗證

別只測一個節點就下結論。從同一訂閱中選 2~3 個不同機房、不同地區的節點分別測速,如果都慢,大機率是線路或本機設定問題;如果只有個別節點慢,那就是節點自身負載問題,換一個正常的即可,不需要繼續往下排查。

3. 注意流量倍率與方案餘量

部分訂閱商會對高倍率節點做限速處理,或者帳戶流量已接近上限被臨時降速,這類情況下延遲測試可能依然正常,但實際下載速度明顯受限。查看客戶端訂閱資訊裡的剩餘流量與到期時間,排除方案層面的限制。

第二層:傳輸線路排查

線路指的是資料從本機裝置出發,經過本機網路、電信業者骨幹網路,最終到達代理伺服器的整條路徑。這一層的問題往往不是代理軟體能解決的,但可以透過測試確認症結,避免誤怪軟體。

1. 先測直連速度作為基準

先關閉代理,直接測一次本機網路的下載速度(用電信業者測速工具或直接下載一個較大檔案計時)。如果直連本身就慢,說明是本機寬頻或 Wi-Fi 訊號的問題,和 Clash 完全無關,先解決網路本身問題。

2. 用 mtr 或 tracert 看路由跳數

如果直連正常但走代理就慢,可以用路由追蹤工具觀察封包經過的節點。Windows 下用命令列:

tracert 目標伺服器IP

macOS 或 Linux 下用:

traceroute 目標伺服器IP

關注兩點:哪一跳開始延遲驟增,以及是否出現大量丟包(顯示為星號 *)。如果國際出口那幾跳延遲是正常上升,屬於正常的物理距離衰減;如果某一跳突然跳升幾百毫秒且後續都維持高位,說明該跳所在的電信業者節點存在壅塞。

3. 換傳輸協定試試看

同一個代理服務商往往會提供多種協定的節點(例如 Shadowsocks、VMess、Trojan、Hysteria2 等)。不同協定對不同電信業者線路的適應性不同,尤其部分線路對 UDP 流量限速明顯,如果你用的是 Hysteria2 這類基於 QUIC/UDP 的協定,在某些網路環境下反而比 TCP 類協定更容易被限速。如果訂閱裡有同地區但協定不同的節點,可以交叉比較一下。

4. 留意電信業者晚間高峰

晚間 20:00~23:00 通常是台灣本地連外頻寬較壅塞的時段,同一個節點白天測速飛快,晚上測速腰斬是常見現象,這屬於線路層面的正常波動,不是設定故障,換個時間段再測一次即可確認。

第三層:本機客戶端設定排查

前兩層都排除之後,剩下的原因基本集中在客戶端自身的設定。這一層問題較隱蔽,但一旦找到往往是「改一個開關就好」的輕量修復。

1. 檢查 DNS 是否出現重複解析

如果 enhanced-mode 設定不當,或者系統 DNS 與 Clash 內的 DNS 設定產生衝突,可能導致同一個網域名稱被解析兩次,甚至又繞回本機 ISP 的 DNS,增加不必要的延遲。檢查設定檔裡的 dns 區塊,確認 nameserver 指向的是回應快的解析位址,並確認 fallback 沒有被頻繁觸發(頻繁觸發代表主要解析節點不穩定)。

2. 規則模式下檢查是否命中錯誤策略群組

規則模式(Rule)下,一次請求可能因規則比對錯誤被分到限速節點,或走直連後被電信業者限速,表現出來就是「網頁開啟很慢」,但代理軟體顯示節點正常。開啟客戶端的連線詳情面板(通常在「日誌」或「連線」分頁),觀察實際存取的網域名稱比對到哪條規則、走的是哪個策略群組,確認沒有比對到不符預期的規則。

3. TUN 模式與系統代理不要同時衝突開啟

TUN 模式是在網路卡層接管全域流量,系統代理則是在應用層設定 HTTP/SOCKS 代理。兩者原理不同,如果客戶端同時開啟了 TUN 模式又手動設定了系統代理,部分流量可能被重複處理或繞路,造成莫名其妙的卡頓。確認只啟用其中一種模式,通常保留 TUN 模式即可涵蓋全域流量。

4. 混合連接埠與本機防火牆

本機防火牆、安全軟體或虛擬網路卡驅動異常,有時會對 Clash 監聽的混合連接埠(預設 7890)做深度封包檢測,拖慢轉發效率。可以暫時關閉第三方安全軟體測試一次,如果速度明顯恢復,說明該軟體的流量檢測拖慢了轉發鏈路,需要為 Clash 相關程序加入白名單。

5. 客戶端版本過舊

較舊版本的客戶端可能沒有針對核心轉發效率做優化,尤其是核心長期未跟進 Clash Meta / mihomo 主線更新的情況下,轉發效率會明顯落後。確認客戶端與核心版本是否為近期發布版本,過舊的建議更新到目前維護中的版本。

十分鐘排查流程小結

1. 開啟節點延遲測試,交叉比較 2~3 個不同地區節點,確認是否為節點本身問題。
2. 關閉代理測直連速度作為基準,排除本機寬頻問題。
3. 路由追蹤查看是否有異常跳點,判斷線路是否壅塞。
4. 檢查 DNS 設定、規則比對、TUN 與系統代理是否衝突,排查本機設定。
5. 暫時關閉安全軟體測試轉發效率,確認是否被攔截檢測拖慢。

拧錯了就拆回上一步——三層排查本質上就是逐步縮小範圍的過程,不需要一次記住所有細節,依序做完每一步的測試動作,答案通常會在中途就浮現。