Clash 延遲測試原理拆解:面板顯示 80ms 為什麼實際用起來仍然卡

延遲數字到底測的是什麼

打開任意一個 Clash 核心客戶端的代理頁面,每個節點後面都跟著一個毫秒數,綠色代表快、黃色代表一般、紅色代表逾時或不可用。這個數字來自客戶端定期發起的一次網路測速,業界通常稱它為 URL Test。它的運作方式很直接:客戶端透過這個節點向一個固定位址發起一次 HTTP 請求,記下從發出請求到收到回應標頭的耗時,這段耗時就是面板上顯示的數字。

關鍵在於,這次測速只跑了「一次短請求的往返時間」,既不下載內文內容,也不模擬瀏覽網頁時的多個並發連線。它更接近網路工程裡說的 RTT(Round-Trip Time,往返時延),衡量的是「發一個封包過去、收到確認回來」要多久,不是「打開一個網頁、載入完所有資源」要多久。這兩者聽起來相關,實際差距可以很大。

說明:延遲數字反映的是鏈路的回應速度上限,不是使用體驗的下限。低延遲是必要條件,不是充分條件。

URL Test 測的是握手耗時,不是頁面載入耗時

要理解差距從哪來,得先看一次真實網頁載入經歷了什麼。打開一個普通網頁,瀏覽器至少要做以下幾件事:

DNS 解析網域,取得目標伺服器的 IP 位址
與伺服器建立 TCP 連線(三次握手)
如果是 HTTPS,再疊加一次 TLS 握手協商加密參數
發出 HTTP 請求,等待伺服器回傳回應標頭和內文
解析 HTML,再並發請求頁面裡的圖片、腳本、樣式表等資源
瀏覽器渲染,直到頁面可互動

URL Test 只覆蓋第 2~4 步裡的一小段,而且測試目標通常是一個體積很小、回應很快的固定位址(比如某個測速專用介面),它對伺服器的負載幾乎可以忽略。而你平時造訪的網站、影音站、遊戲伺服器,負載情況、地理位置、CDN 節點分佈都完全不同。同一條代理線路,存取測速位址 80ms,存取另一個目標可能是 200ms,這不是延遲數字「測錯了」,而是它本來就只代表一個採樣點,不代表所有目標。

另外,大多數客戶端的自動測速有節流機制,不會每次請求資源都即時測一次,面板顯示的數字往往是幾十秒到幾分鐘前的快照。鏈路狀況本身也會波動,尤其是尖峰時段的中轉節點,五分鐘前 80ms、現在可能已經漲到 300ms,面板不會即時更新到這個程度。

丟包、頻寬瓶頸與鏈路壅塞如何拖慢真實體驗

延遲數字之外,還有三個變數直接決定「用起來卡不卡」,而它們大多不會體現在那個毫秒數上。

丟包率

TCP 協定靠確認和重傳保證資料完整,一旦某個封包在鏈路中丟失,發送端要等待逾時後重新發送,這個等待往往是幾百毫秒起步。低延遲但高丟包的線路,表現出來就是「網頁刷得開但影片一卡一卡」「遊戲延遲數字正常但會突然卡頓跳格」。URL Test 的單次短請求很難暴露丟包問題,因為它測的樣本量太小,恰好沒撞上丟包的那個瞬間。

頻寬瓶頸

延遲衡量的是「回應快不快」,頻寬衡量的是「管道粗不粗」。一條延遲只有 50ms 但頻寬只有 2Mbps 的線路,打開網頁很快有反應,但下載檔案、看高畫質影片會明顯吃力,進度條走得很慢。這是兩個完全獨立的指標,面板上的延遲數字對頻寬瓶頸完全不敏感。

鏈路壅塞

代理線路往往要經過多段中轉,任何一段中轉伺服器的負載過高、上游頻寬被大量使用者擠占,都會造成壅塞。壅塞的典型表現是延遲隨時間劇烈波動、尖峰時段變差、深夜變好。如果只看客戶端剛啟動時測的那一次延遲,很容易錯判線路品質。

現象	延遲數字表現	真實原因
影片卡頓、緩衝圈轉不停	可能仍顯示「綠色」低延遲	丟包導致 TCP 重傳,或頻寬不足以支撐位元率
網頁秒開但下載檔案很慢	延遲正常	頻寬瓶頸,與延遲無關
白天用著好、深夜突然快很多	不同時段測出的數字不同	鏈路壅塞隨負載波動
面板顯示逾時/紅色	數字異常或缺失	節點失效或測速目標本身不可達

更貼近真實體驗的自測方法

既然單看面板延遲不夠,可以補充幾種更貼近實際使用場景的檢測方式,組合起來判斷線路是否真的可用。

1. 手動測速多個真實目標,而不只信自動測速

大部分 Clash 客戶端支援手動對單個節點或分組重新測速,並且可以在設定裡自訂測速位址。把預設測速位址換成你實際常用的服務(比如常造訪的網站首頁),測出來的數字更貼近實際存取該服務的耗時。同一個節點分別測台灣本地常見的測速位址和你要造訪的目標位址,對比差距,能幫你判斷這條線路是「普遍快」還是「只對測速目標快」。

2. 用日誌頁觀察連線過程,而不只看一個數字

客戶端的日誌頁(或連線頁)會記錄每一次實際連線的目標位址、使用的節點和規則比對結果。真正打開一個卡頓的網頁時去看日誌,能確認這次存取走的是哪個節點、是否頻繁重連、是否有連線被規則誤判走了慢速線路。這比只盯著代理頁的延遲數字更能定位問題出在哪一環。

3. 用系統內建工具做基礎網路診斷

ping -c 20 目標網域或IP
tracert 目標網域或IP   # Windows 用 tracert,macOS/Linux 用 traceroute

連續 20 次 ping 能看出丟包率(輸出裡的 packet loss),比一次性的延遲數字更能反映鏈路穩定性;路由追蹤能看出封包在哪一跳開始明顯變慢或丟失,幫助判斷問題是出在本機網路、中轉節點還是目標伺服器一側。

4. 換一個時段重複測試

如果懷疑是鏈路壅塞,選擇同一條線路在不同時段(比如晚上 9 點尖峰和凌晨 2 點)分別測一次,延遲和丟包表現差距明顯的話,基本可以確認問題出在鏈路負載而不是線路本身設定錯誤。

5. 排除本機與終端裝置的干擾因素

在下結論之前,先確認系統代理是否正確開啟、是否與其他代理軟體衝突、TUN 模式是否正常接管流量。這些設定層面的問題表現出來也是「卡」,但和線路品質無關,排查順序上應該先排除。

注意:如果多個節點在多個時段都測出高延遲或高丟包,更可能是訂閱本身的線路品質問題,換節點或聯繫訂閱提供者比反覆調整客戶端設定更有效。

常見疑問

為什麼兩個客戶端測同一個節點,延遲數字不一樣?

測速位址、逾時門檻、測速頻率的預設設定不同,數字自然有差異,這是正常現象,不代表某個客戶端「測得更準」。

延遲一直是綠色,但影片還是經常卡,該怎麼辦?

優先懷疑丟包和頻寬瓶頸。用 ping 多次測試觀察丟包率,再看該節點的頻寬是否有限速,必要時換一個節點分組重試。

自動測速多久更新一次,能不能調更頻繁?

大多數客戶端支援在設定裡調整自動測速間隔,調得過於頻繁會增加不必要的網路請求,一般保持預設或適度縮短即可,不需要追求即時更新。