Clash 延遲測試數字怎麼看:
為什麼顯示幾十毫秒實際卻卡頓

延遲數字到底測了什麼

打開 Clash 用戶端,節點列表右側那一串毫秒數,來源是核心對每個節點發起的一次網路探測。具體做法是:用戶端透過該節點建立連線,向設定裡指定的 test-url(預設多為 http://www.gstatic.com/generate_204 或類似的輕量介面)發起一次 HTTP 請求,記錄從發出請求到收到回應之間的耗時,這個耗時就是延遲。

這個過程只經歷三件事:DNS 解析(如果目標是網域名稱)、TCP/TLS 握手、以及一次極小的 HTTP 往返。它不下載任何實質內容,目標介面通常只回傳一個 204 空回應或幾個位元組的文字,所以整個測試對帶寬幾乎沒有要求。這意味著延遲數字反映的是「連上這個節點、打一個來回」要多久,和「這個節點能不能扛住看影片、下大檔案」是兩件不同的事。

為什麼延遲很低,實際卻卡頓

看到 30ms、50ms 這種數字就默認節點「很快」,是最常見的誤判。實際卡頓的原因通常出在延遲測試完全覆蓋不到的幾個環節:

• 丟包與抖動(Jitter):延遲測試是單次探測,一次成功不代表持續穩定。節點可能在某個瞬間回應很快,但在你實際瀏覽、播放影片的幾十秒內出現間歇性丟包,畫面卡頓、載入卡死,而延遲列表刷新時剛好又測到一次正常值。
• 帶寬與出口壅塞:延遲探測請求體積幾乎為零,不會觸發限速或壅塞;但打開一個影片、下載一個檔案需要持續吞吐,如果節點出口帶寬有限或正被大量用戶共享,實際速度會遠低於延遲數字暗示的「快」。
• 目標伺服器與落地品質:測試 URL 通常是海外大廠的輕量介面,和你真正要訪問的網站/應用伺服器可能完全不在同一網路路徑上。測試路徑通暢,不代表你實際訪問的目標網站路徑也通暢。
• 協定層差異:不同代理協定在小封包測試和持續大流量下表現不一致,有些協定在低延遲場景占優,但在弱網、高並發場景下反而更容易斷線重連。

test-url、超時與並發機制如何影響你看到的數字

延遲數字不是一次性算出來永遠不變的,它由幾個可設定的機制共同決定,理解這些機制能幫你判斷眼前的數字是否可信。

test-url:測的是誰的路

策略組設定裡的 url(部分文件也寫作 test-url)欄位決定探測目標。多數訂閱預設指向境外的輕量檢測介面,這類介面在全球各地都有較好的回應,測出來的數字普遍偏低、偏「好看」。如果你主要訪問的是特定地區、特定服務的網站,和預設測試目標的網路路徑可能完全不同,數字好看不代表你要訪問的目標也一樣快。

interval:多久重測一次

策略組的 interval(單位秒)決定自動測速的間隔,常見設定在 300 秒左右。這意味著列表裡的數字很可能是幾分鐘前的一次快照,網路狀況隨時在變化,數字有滯後性,不代表「此刻」的真實狀態。

tolerance:容差範圍內不切換

tolerance 欄位(單位毫秒)定義了自動選優策略組的切換容差。如果新測得的延遲只比目前節點略好,差值在容差範圍內,用戶端不會切換節點,避免頻繁抖動導致連線反覆重建。這也是為什麼有時候列表裡明明有延遲更低的節點,自動選優卻「沒反應」——它在按容差規則工作,不是沒測到。

timeout 與並發探測

探測請求本身有超時限制,超過閾值直接判定為超時(通常顯示為失敗或極高數值)。同一批節點往往是並發測速,如果本地網路、CPU 或並發數設定不當,短時間內大量並發請求會互相爭搶資源,導致測出來的數字整體偏高或不穩定,這種情況下單次測速結果參考價值有限,建議多測幾輪再看趨勢。

正確解讀延遲數字的三個動作

1. 看趨勢,不看單次值:手動多次觸發測速(多數用戶端支援點擊刷新或右鍵單個節點測速),觀察同一節點在不同時間點的波動幅度。波動小的節點即便平均值略高,實際體驗通常更穩。
2. 結合真實場景驗證:延遲數字過關後,實際打開一個你常用的網站或做一次小檔案下載測試,感受載入速度和是否卡頓,這一步比看數字更直接。
3. 區分「選優策略組」和「手動選擇」:如果策略組是自動選優(url-test 類型),它已經在按 interval 和 tolerance 幫你篩選;如果是手動分組,數字僅供參考,最終還是要靠實際使用體驗決定是否更換節點。

數字好看但體驗差,如何進一步排查

如果延遲數字長期偏低,但網頁載入慢、影片緩衝頻繁、下載速度上不去,可以按下面順序排查:

• 切換到其他節點做同類型對比測試,判斷是單個節點的問題還是整條訂閱線路的共性問題。
• 檢查是否開啟了 TUN 模式,以及規則分流是否把大流量應用正確導向了合適的策略組,而不是全部走同一個可能過載的節點。
• 確認目前時間段是否是網路高峰期,部分線路在晚間高峰會因為用戶集中而出現帶寬爭搶,這類壅塞不會體現在延遲探測的小封包測試裡。
• 排查本機網路本身是否有問題,比如先在不啟用代理的情況下測試本地網速和丟包,排除是本地網路造成的假象。

選節點時該看什麼組合指標

把延遲當作篩選的第一道門檻,而不是唯一標準,配合以下幾個維度綜合判斷會更靠譜:

• 延遲的穩定性:多次測速的波動範圍比單次數值更重要。
• 協定與加密方式:不同協定在弱網和高並發場景的抗干擾能力不同,同一批節點裡協定一致的情況下比較才有意義。
• 落地地區與線路:同一節點在不同時間段、不同目標網站上的表現可能差異明顯,長期觀察比單次判斷更可靠。
• 實際吞吐測試:有條件的話做一次真實下載或速度測試,直接驗證帶寬是否匹配延遲數字給出的「好印象」。

延遲測試是一個快速篩選工具,能幫你迅速排除明顯異常或超時的節點,但決定日常使用體驗的,始終是帶寬、丟包率和線路壅塞情況的綜合結果。把這幾項拆開看,才能避免被一個漂亮的毫秒數誤導。