Clash 延遲測試原理：面板上的毫秒數為什麼不等於真實體驗

打開 Clash 面板，節點列表右側那一串數字，是很多人挑節點的唯一依據——數字越小越好，彷彿延遲就是速度的代名詞。但如果你留意過，會發現一個反直覺的現象：某個節點延遲只有 40 毫秒，看起來快得離譜，可打開影片網站卻緩衝個不停；另一個節點延遲 300 毫秒，看起來慢得可疑，實際刷網頁卻很流暢。這不是面板出了 bug，而是延遲測試本身測的東西，跟你日常上網體驗之間，隔著幾層沒說清楚的差異。

延遲測試到底在測什麼

Clash（包括基於 Clash Meta / mihomo 核心的各類用戶端）在做延遲測試時，並不會去存取你實際想打開的網站，而是向設定裡指定的一個固定測速 URL 發起請求，記錄從發出請求到收到回應的時間差，這個時間差就是面板上顯示的毫秒數。預設情況下，這個 URL 通常是類似 http://www.gstatic.com/generate_204 這樣的位址——它是 Google 提供的一個專門用於連通性檢測的介面，特點是回應極快、內容極小，幾乎不佔用頻寬。

整條測速鏈路大致是這樣走的：你的裝置 → 本機 Clash 核心 → 選中的代理節點（經過一次或多次跳轉）→ 落地伺服器 → 測速 URL 所在的伺服器 → 原路返回。這條鏈路上任何一環變慢，最終數字都會變大。但請注意，這條鏈路裡根本不包含「你真正要存取的那個網站」，測速 URL 和你打開的影片站、社群平台、辦公系統，實體位置、網路架構、CDN 分布可能完全不同。延遲數字反映的，是節點到測速伺服器這一條特定路徑的握手速度，並不等於節點到任意目標網站的速度。

為什麼用的是 HEAD 請求，而不是完整下載

細心的人可能會發現，延遲測試幾乎是瞬間完成的，哪怕節點線路本身不算快。這是因為大部分實作走的是 HTTP 的 HEAD 請求（或者是極小內容的 GET 請求，例如回傳 204 No Content 的介面），伺服器只需要回一個回應標頭就結束，根本不涉及正文資料的傳輸。這樣做的好處很明顯：測速本身幾乎不消耗流量，也不會因為要下載幾十 KB 的內容而讓結果受頻寬大小的影響，能更純粹地反映「連線建立」這一步的快慢。

但這也正是它的侷限所在。HEAD 請求測的是握手階段——TCP 三次握手、TLS 協商、請求發出到回應標頭返回，全程傳輸的資料量小到可以忽略。而你實際打開一個網頁、載入一段影片、下載一個檔案，考驗的是持續傳輸大量資料時的穩定表現：頻寬是否充足、傳輸中是否會丟包、丟包後重傳的開銷有多大、多個並發連線之間是否互相擠占。這些因素在一次微小的 HEAD 請求裡根本體現不出來，節點完全可能「握手很快，但一旦開始傳大檔案就掉鏈子」。

握手快與傳輸穩,是兩件不同的事

可以做一個類比：延遲測試像是量一下你和朋友打電話時對方接起來的速度，接得快說明訊號通暢、線路沒堵；但通話品質好不好、會不會突然斷線、聲音會不會忽大忽小，是另一件事，需要通完整段話才能判斷。節點延遲低，說明這條路徑的「接通」環節順暢，可後續大量資料湧進來時是否依然順暢，測速數字給不出答案。

低延遲節點為什麼還會卡頓

結合上面的原理，卡頓的常見原因通常出在延遲測試完全照顧不到的幾個維度：

• 頻寬上限不足。節點伺服器本身的出口頻寬有限，或者被同一時段的其他使用者占滿，握手依舊很快，但真正開始傳輸影片碼流這種持續大流量時，速度就跟不上，表現為反覆緩衝。
• 抖動與丟包。延遲數字通常是單次測量或短時間內幾次測量的平均值，掩蓋了網路品質的波動。如果這條線路時快時慢、偶有丟包，播放影片這類需要持續穩定吞吐的場景會明顯感覺卡頓，但單次延遲測試很可能剛好落在網路狀態較好的瞬間，顯示出一個漂亮的數字。
• 目標網站的 CDN 分布不同。測速 URL 的伺服器和你實際存取的影片站、下載站可能部署在完全不同的機房甚至不同的大洲。你的節點到測速伺服器的路徑很短，到目標網站的實際路徑卻要繞行更遠，中間經過的電信商節點、國際出口壅塞程度也不一樣。
• 落地地區與內容分發策略。不少影片平台會按存取來源的地理位置分配不同的傳輸節點或限速策略，節點的落地地區如果恰好在該平台限速或高峰壅塞的區域，即便到測速 URL 的握手很快，實際拉取影片流時依然會受限。
• 並發連線數的影響。網頁載入、影片播放往往會同時建立多條連線，如果代理節點或落地線路對並發連線的處理能力有限，多條連線互相擠占資源，實際體驗會比單條延遲測試反映的更差。

更貼近真實體驗的判斷方法

既然延遲數字只是參考的一部分，日常挑選節點時可以補充幾種更直接的判斷方式，避免只盯著毫秒數做決定。

1. 結合測速功能看吞吐量。多數用戶端在延遲測試之外還提供「測速」按鈕，會實際下載一段資料來計算頻寬，這個數字比單純的延遲更能反映持續傳輸能力，兩者最好一起參考。
2. 用真實場景做短時試用。對於經常存取的少數幾個關鍵網站或服務，與其糾結延遲數字，不如直接切換節點後打開試用幾十秒，影片是否順暢緩衝、頁面載入是否流暢，比任何測速數字都更接近你要的答案。
3. 多測幾次取參考區間，而非單次數值。如果發現某個節點的延遲在幾次測試之間波動很大（比如一次 60 毫秒、一次 400 毫秒），說明這條線路本身不穩定，穩定性上的隱患比絕對數值更值得留意。
4. 留意規則命中與落地地區是否匹配需求。延遲低但落地地區不適合你要存取的具體服務，速度依然上不去；反過來，如果規則設定能讓不同類型的流量分流到不同節點，各走各自更合適的路徑，往往比死磕「全域最低延遲」的單一節點更實用。可以參考代理模式的選擇方式，讓規則、全域、直連各司其職。

測速 URL 本身也值得留意

如果你在設定裡自訂過測速 URL，也要注意選擇一個回應穩定、地理位置具有一定代表性的位址，避免用一個本身就不穩定或距離你目標存取區域太遠的介面，那樣測出來的數字參考價值會進一步打折。多數用戶端和訂閱設定預設使用的連通性檢測介面已經經過較廣泛驗證，一般情況下不需要額外更改；如果你所在網路環境存取預設位址本身就不穩定，才考慮更換為其他公開的、回應輕量的檢測介面。

小結

面板上的毫秒數，本質是節點到一個固定測速位址的握手耗時，反映的是連線建立環節的通暢程度，而不是持續傳輸大量資料時的真實吞吐表現，更不是你打開某個具體網站時的實際體驗。理解這層差異之後，再看延遲排序就不會再糾結於個位數的毫秒差異，而會更關注頻寬是否夠用、線路是否穩定、落地地區是否匹配自己的使用場景——這些才是真正決定「快不快、卡不卡」的關鍵因素。