Clash 網速慢分層排查法:節點、線路還是本機設定

排查前先確認問題範圍

動手調整任何設定之前,先花兩分鐘確認問題的具體表現,可以省下後面大量無效嘗試。「網速慢」是一個籠統的描述,背後至少對應三種不同現象,而這三種現象指向的原因幾乎完全不同:

• 開啟網頁/應用程式慢,但一旦載入完成就播放順暢——通常是延遲(RTT)偏高,而不是頻寬不足,重點看節點距離與線路品質。
• 持續下載/播放時速度上不去,卡頓反覆出現——大機率是頻寬或線路壅塞,重點看節點負載與傳輸協定。
• 只有特定網站或應用程式慢,其他一切正常——問題往往不在代理本身,而是分流規則把該流量導到不合適的出站,或該站點本身對代理 IP 做了限速。

把現象分類之後,再決定從哪一層開始排查。若不確定,可依下文給出的三層順序逐一檢查,這個順序是依「排查成本由低到高」設計的——先排除最容易驗證的節點問題,再看線路配置,最後才動到本機系統層級的設定。

第一層排查:節點本身的速度瓶頸

節點是鏈路的起點,也是最容易驗證、最該優先排除的一層。多數訂閱提供多個地區、多條線路的節點,速度差異往往比想像中大。

以延遲測試初步篩選

客戶端的節點清單通常帶有延遲測試按鈕(Clash Meta 核心對應的是以 url-test 為基礎的健康檢查),點擊後會對每個節點發送一次 HTTP 探測並記錄來回時間。延遲測試反映的是「能不能連上、連線建立快不快」,不完全等同實際傳輸速度,但延遲長期超過 500ms 或直接顯示逾時的節點,基本可以排除。

• 延遲低於 150ms:一般可用於網頁瀏覽、即時通訊。
• 延遲介於 150~400ms:可用,但影音/遊戲場景會有明顯卡頓感。
• 延遲超過 400ms 或頻繁逾時:優先更換節點,不建議繼續在此節點上排查後續問題。

排除節點負載過高的情況

共享節點在尖峰時段(晚間 19:00–24:00 是多數訂閱的尖峰)容易被大量使用者瓜分頻寬,表現為延遲測試結果正常,但實際下載速度很低。這種情況下延遲測試無法反映問題,需要手動實測一次:切換到該節點後存取一個已知速度穩定的靜態資源(例如某個公開測速檔案),比較不同節點、不同時段的下載速度差異。若同一節點在非尖峰時段速度明顯較好,基本可判定是負載問題,而非配置問題。

在分組策略中加入自動測速與故障切換

若訂閱中同地區有多個節點,建議在 proxy-groups 裡使用 url-test 類型分組,設定合理的測試間隔,讓客戶端自動挑選延遲最低的節點,減少手動切換的頻率:

proxy-groups:
  - name: 自動選擇-香港
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - HK-01
      - HK-02
      - HK-03

tolerance 表示容差範圍,避免節點因幾毫秒的延遲波動而頻繁切換,造成連線反覆中斷。

第二層排查:傳輸線路與協定設定

確認節點本身沒有明顯問題後,下一步要看的是「資料從本機到節點之間走的是什麼路徑、用什麼協定封裝」。這一層的調整往往比換節點更能帶來速度提升,尤其是在網路環境本身對某些協定做了限速或干擾的情況下。

嘗試切換傳輸協定

同一個節點若同時提供多種協定(如 VMess、Trojan、Hysteria2、ShadowTLS 等),不同協定在同一網路環境下的表現可能差異很大。部分網路對 TCP 類協定的深度封包檢測更嚴格,而以 UDP 為基礎的協定(如 Hysteria2、TUIC)在丟包率較高的線路上反而更穩定,因為它們自帶前向糾錯與壅塞控制機制,能更好地應對丟包。若訂閱同時提供多種協定節點,建議逐一測試:

1. 先測 TCP 類協定(VMess/Trojan)的實際下載速度。
2. 再測 UDP 類協定(Hysteria2/TUIC)在同一時段的表現。
3. 記錄兩者差異,固定使用速度較穩定的一類協定。

檢查是否被限速或干擾

某些網路環境會對識別出的代理流量進行限速而非直接封鎖,表現為連線能建立、延遲測試正常,但傳輸速度被限制在一個很低的固定值(例如穩定卡在 200KB/s 左右,無論換哪個節點都是同樣的數值)。這種情況下換節點沒有意義,需要考慮更換傳輸層的偽裝方式,例如啟用 TLS 偽裝或切換到抗干擾能力更強的協定。

確認 TUN 模式與系統代理的差異

TUN 模式在系統網路層接管全部流量,常見於需要處理非瀏覽器應用程式(遊戲、背景服務)代理的場景,理論上不應該比系統代理慢,但若本機同時開著其他虛擬網卡或安全軟體的網路掛勾,可能出現互相干擾導致的丟包重傳。可以做一次對照測試:關閉 TUN 模式,改用系統代理模式測試同一節點的速度,若系統代理模式明顯較快,問題大機率出在本機網路驅動層面,而非節點或協定。

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

若前兩層都沒找到問題,大機率是本機設定在拖累速度。這一層排查成本略高,但往往是長期反覆出現速度問題的根源。

調整 DNS 解析設定

DNS 解析慢會造成「頁面首次載入慢,但資源載入後很順暢」的假象,容易被誤判為節點問題。建議在設定檔中為客戶端指定獨立的 DNS 伺服器,並啟用 fake-ip 模式減少不必要的真實 DNS 查詢延遲:

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

nameserver 用於處理台灣本地網域解析,fallback 用於代理網域的解析,兩者分開設定能避免本地網站被繞道解析所導致的額外延遲。

精簡分流規則

規則數量過多、規則集體積過大,會增加客戶端比對每條連線所需的時間,在低效能裝置(尤其是路由器或舊手機)上表現更明顯。檢查是否載入了多個功能重疊的規則集,例如同時啟用兩套廣告過濾規則或多份地區分流規則,合併或刪減重複規則可以減少比對開銷。同時確認規則順序是否合理——高頻比對的規則(如台灣本地直連網域)放在規則清單較前面的位置,能減少平均比對次數。

關閉背景占用頻寬的程式

雲端同步工具、系統自動更新、背景下載任務都會占用出口頻寬,與代理流量互相競爭,表現為「代理本身沒問題,但整體網速就是上不去」。測速前建議先檢查工作管理器或活動監視器裡的網路占用情況,暫停明顯占用頻寬的背景行程後再測一次。

確認客戶端版本與核心狀態

使用較舊版本的客戶端或核心,可能缺少後續版本對某些協定的效能優化。若長期存在速度問題且以上排查都未找出原因,可檢查是否有新版本可用,更新後重新走一次上述三層排查流程,確認問題是否隨版本更新解決。

建立一套可重複使用的排查流程

把上述內容整理成一份簡單的檢查清單,遇到速度問題時依序過一遍,能明顯減少排查耗時:

1. 延遲測試篩掉明顯異常的節點。
2. 同地區節點做實測下載速度比較,排除負載問題。
3. 切換協定類型,比較 TCP 類與 UDP 類的表現。
4. 關閉 TUN 模式做對照測試,排除本機網路層干擾。
5. 檢查並調整 DNS 設定,確認解析速度。
6. 精簡分流規則,減少比對開銷。
7. 排查背景占用頻寬的程式。
8. 確認客戶端與核心版本皆為最新。

大多數速度問題在前三步就能定位。真正需要走到本機設定層面排查的情況相對少見,但一旦出現,往往是長期反覆困擾的根源,值得花時間徹底排查一次,而不是反覆換節點應付。