Clash 節點測速原理詳解:為什麼延遲低的節點實際體驗卻很卡

一、延遲數字是怎麼測出來的

在 Clash 用戶端的節點列表裡點一下測速按鈕,幾百毫秒後每個節點後面會出現一個毫秒數。這個數字的產生過程是:核心以該節點為出口,向一個測試位址發起一次 HTTP 請求。常用測試位址是 https://www.gstatic.com/generate_204,它只回傳一個 204 空回應,回應內容為零位元組。從請求發出到回應標頭傳回,這段耗時就是頁面上顯示的「延遲」。

把這一次請求拆開來看,耗時由三段組成:本機到節點伺服器建立連線(TCP 握手,TLS 類協定還要再加一輪 TLS 握手)、節點伺服器到測試位址的連線與轉發、測試位址產生回應並沿路傳回。所以它本質上是一次「小請求全鏈路往返耗時」,而不是下載速度,更不是影片位元率。

url-test 策略群組的自動測速與手動點按是同一套機制,只是按週期自動執行。一份典型的自動選擇設定如下:

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies:
      - 節點A
      - 節點B
      - 節點C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

其中 interval 是測速週期,預設 300 秒一輪;tolerance 是容差,只有當某個節點比目前節點快出這個毫秒數時才會切換,預設 50 毫秒,用來避免兩個延遲接近的節點之間來回跳動。理解這兩個參數,後面挑節點時還會用到。

二、為什麼延遲低不等於快

一次 204 請求的全部資料量只有幾百位元組,它測的是鏈路的「反應速度」,完全測不出管道的「粗細」。以下幾個決定實際體驗的因素,延遲數字一個都反映不出來。

頻寬與單連線吞吐量

實際下載速度取決於鏈路剩餘頻寬與 TCP 壅塞控制。粗略地說,單條 TCP 連線的吞吐量上限約等於「傳輸中視窗大小 ÷ 往返延遲」:延遲低確實有先天優勢,但前提是頻寬夠、不丟包。一條 30 毫秒但只剩 5 Mbps 閒置頻寬的線路,下載必然輸給 200 毫秒但有 300 Mbps 閒置頻寬的線路。毫秒數漂亮,不代表傳資料快。

丟包:隱形殺手

TCP 一旦丟包就要重傳,壅塞視窗還會回退。1% 的丟包率就足以讓吞吐量腰斬再腰斬,而測速那個小小的 204 請求很可能剛好一次都沒碰上丟包,於是結果顯示一切正常。在晚間高峰的國際線路上,丟包往往比延遲更早惡化,也更致命。

抖動:穩定性的另一面

延遲忽高忽低叫抖動。測速只取一次樣本,看不出抖動。看影片時的突然卡頓、遊戲裡的跳 ping、通話的斷斷續續,大多是抖動與突發丟包造成的,跟平均延遲關係不大。一個平均 60 毫秒但偶爾衝到 400 毫秒的節點,體驗遠不如穩定在 150 毫秒的節點。

晚間高峰壅塞與電信業者的隱形門檻

很多線路白天空閒、晚上 20 點到 23 點擠滿。如果習慣在下午測速挑節點,挑出來的「最快節點」未必扛得住晚間高峰。此外,部分電信業者會對特定連接埠或協定做限速(QoS),小請求測速感覺不到,持續大流量一跑就現形。

節點伺服器本身的負載

節點是共用資源。同一台伺服器上的使用者越多,CPU 加解密排隊、網路頻寬被稀釋的情況就越嚴重。TLS、混淆等協定開銷在伺服端忙碌時會進一步放大回應時間——這時延遲數字也會變差,但它變差的速度往往落後於實際體驗的惡化,等你看到毫秒數上升,卡頓早已持續一陣子了。

三、測速結果裡還能看出什麼

延遲數字不是一無是處,關鍵是要看對。

timeout 跟「慢」是兩回事。測速顯示 timeout,表示在逾時時間(預設約 5 秒)內沒有取得回應,常見原因是節點當機、入口被封鎖或協定握手失敗。這種節點應直接視為不可用,而不是「很慢的節點」。

連續多測幾次,看波動而不是看單次結果。50、55、52 毫秒是穩定;80、300、150 毫秒是抖動大。後者即使最低值很漂亮,實際體驗也往往很糟。

用儀表板看歷史曲線。metacubexd、Yacd 這類儀表板可以看到每個節點的歷史延遲記錄,曲線平緩比數值低更值得信任。

記住測試位址的線路偏好。到 gstatic 快,不代表到常看的影音網站、遊戲伺服器同樣快——它們走的可能是完全不同的國際出口。測速通過只說明「到測試位址這一段是通的」。

四、更可靠的挑節點方法

用真實流量複測。候選節點縮小到兩三個之後,各掛十分鐘:看一段高位元率影片(播放器統計資訊裡的連線速度是直觀指標),跑一次多執行緒測速,再觀察單執行緒大檔案下載是否平穩。三項都通過,才算合格。
晚間高峰再測一輪。20 點到 23 點之間重複上面的實測。空閒時快、忙碌時垮的節點直接降級為備用,別放在自動選擇群組的前面。
看抖動,不看單次結果。連續測速五到十次,記錄最高值與最低值的差距,差距越小越穩。優先考量穩定性的場景,寧可選穩定的中等延遲,也不選飄忽不定的低延遲。
讓策略群組替你值班。日常瀏覽交給 url-test,搭配合理容差;對穩定性要求高的場景(遠端桌面、線上會議)用 fallback,主節點故障才切換:

proxy-groups:
  - name: 穩定優先
    type: fallback
    proxies:
      - 主力節點
      - 備用節點
    url: https://www.gstatic.com/generate_204
    interval: 120

依場景分流,而不是找一個「全能節點」。下載任務走頻寬大的節點,遊戲與通話走低延遲低抖動的節點,用不同策略群組分開承接,彼此互不影響。

注意

別把測速間隔調太短。interval 改成幾十秒看似「盯得緊」,實際收益卻很小:每次測速都會對節點與測試位址製造額外請求,過於頻繁反而可能觸發目標伺服器的限流。300 秒上下是穩妥的取值。

五、常見疑問

延遲 30 毫秒的節點,看 4K 為什麼還會緩衝?

因為 4K 影片要的是持續 25 Mbps 以上的吞吐量,而不是低延遲。延遲合格但頻寬不足或丟包偏高時,緩衝照樣轉圈。按第四節的方法測吞吐量,而不是盯著毫秒數。

同一個節點,手機快、電腦慢,是測速不準嗎?

不一定是節點的問題。兩端到節點的鏈路相同,瓶頸可能在電腦這一側:Wi-Fi 訊號弱、本機防火牆攔截,或是 TUN 模式的額外開銷。TUN 模式要多經過一層虛擬網卡轉發,效能較弱的裝置上吞吐量會打折扣,這跟延遲測試無關。

測速全綠,為什麼還是打不開網頁?

測速只驗證「到測試位址」這一段通不通,規則比對錯誤、DNS 解析異常都不在它的檢查範圍內。這類問題可以對照常見問題頁逐項排查,方向是系統代理開關、規則模式與 DNS 設定。