Clash 延遲測試數字怎麼看？顯示延遲不等於實際體驗的原因

Clash 顯示的延遲究竟測量了什麼

用戶端節點清單中的 45 ms、168 ms 或 timeout，通常來自一次很小的 HTTP 或 HTTPS 請求。Clash 或 mihomo 會讓測試請求經過指定代理節點，存取用戶端預設或設定檔指定的測試網址，再記錄從發出請求到取得有效回應所需的時間。這個結果適合用來判斷節點能否建立連線、握手是否迅速，但不是完整的下載速度測試。

一次 HTTPS 延遲測試大致會經過本機應用程式、Clash 入站連接埠、代理節點和目標網站四個環節。如果目標網域尚未解析，還會先進行 DNS 查詢；新連線通常也包含與代理伺服器建立 TCP 連線、代理協定握手，以及存取測試網站時的 TCP 和 TLS 握手。用戶端是否重複使用連線、是否命中 DNS 快取，都會影響最終數字。

1. 用戶端會把測試請求交給指定節點，而不是交給目前自動選擇的其他節點。
2. Clash 會根據節點協定建立連線，例如 Shadowsocks、Trojan、VLESS 或核心支援的其他協定。
3. 代理節點接著連線到測試 URL 對應的伺服器。
4. 目標伺服器回傳 HTTP 回應，用戶端據此計算耗時。

它不是單純的網路 Ping

系統指令 ping 使用 ICMP 回應封包，而 Clash 的 URL Test 通常使用真實的 HTTP 或 HTTPS 請求。部分伺服器可能限制 ICMP，卻仍允許代理協定與網頁流量；也可能出現 Ping 很低、代理握手卻很慢的情況。因此，不能直接把伺服器 Ping 值當成 Clash 中應顯示的延遲。

同一節點在兩個用戶端中顯示 70 ms 和 130 ms，也不一定代表核心異常。應先核對測試 URL、逾時時間、是否使用 HTTPS、連線是否重複使用，以及測試時的本機網路是否相同。手機使用 5G、電腦使用有線寬頻時，兩組結果本來就不適合直接比較。

URL Test 的路徑與自動選擇邏輯

url-test 是 Clash 代理群組類型之一。它會定期測試群組內的節點，並選擇目前測得延遲較低且可用的節點。常見設定會使用能快速回傳 204 狀態的網址，減少回應內容對測量造成的干擾。以下是一段可讀性較高的範例：

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

interval: 300 表示測試間隔為 300 秒，也就是 5 分鐘。間隔並非越短越好：設為 10 秒會產生額外連線與日誌，也容易因瞬間波動而頻繁切換節點。日常使用可從 300 至 600 秒開始，行動網路變化較快時再適度縮短。

tolerance: 50 用於控制切換靈敏度。假設目前節點為 120 ms，另一個節點測得 92 ms，兩者只差 28 ms，通常沒有必要立即切換；如果新節點降至 60 ms，差距達到 60 ms，切換才更有實際意義。容差可減少在 80 ms、95 ms、110 ms 之間反覆跳轉造成的連線中斷。

測試 URL 會改變結果

測試目標距離代理出口越遠，結果通常越高。東京出口存取東京附近的測試伺服器可能只有 35 ms，存取歐洲目標則可能超過 220 ms。若日常主要使用某項服務，可以選擇穩定、回應內容很小且路徑具代表性的 HTTPS 網址，但應確認該網址允許長期正常存取。

• 測試網址穩定性：目標網站限流或故障時，所有節點都可能顯示逾時。
• HTTP 與 HTTPS：HTTPS 會包含 TLS 建立連線的成本，更接近日常網頁存取情境。
• DNS 解析路徑：不同的 nameserver、fake-ip 或 redir-host 設定，可能造成不同的首次測試耗時。
• 出口位置：同一代理節點存取不同地區的目標時，路由長度與壅塞程度各不相同。
• 快取狀態：第一次測試可能包含 DNS 與握手成本，緊接著進行的第二次測試可能較低。

為什麼幾十毫秒的節點看影片仍然卡頓

影片播放依賴持續吞吐量，而延遲測試只傳輸極少資料。一個節點可以在 45 ms 內完成小型請求，卻只能持續提供 2 Mbps 頻寬。播放位元率約 15 Mbps 的 4K 影片時，緩衝區消耗速度明顯高於下載速度，結果就是頻繁停頓。反過來，一個延遲 180 ms、卻能穩定傳輸 80 Mbps 的節點，首次開啟頁面稍慢，可能更適合大檔案與影片。

延遲、頻寬、丟包與抖動是四項指標

例如某節點連續五次測試為 48、52、51、49、55 ms，平均值約 51 ms，波動很小；另一個節點的結果為 35、280、62、410、44 ms，雖然最低值只有 35 ms，抖動卻非常大。如果節點清單只顯示最近一次的 35 ms，就會掩蓋後續請求頻繁變慢的問題。

丟包對 TCP 傳輸尤其明顯。TCP 發現資料未抵達後會重新傳送，並可能降低壅塞視窗。即使基礎往返延遲只有 60 ms，持續出現 2% 至 5% 的丟包，也可能讓下載曲線呈鋸齒狀。UDP 語音或遊戲流量通常不會等待完整重傳，表現則是聲音缺段、位置更新延遲或畫面突然跳動。

伺服器負載與線路時段同樣重要

代理伺服器的 CPU、記憶體、連線數或上游頻寬接近上限時，小型探測請求仍可能快速回應，但大流量傳輸會受到限制。晚間 20:00 至 23:00 的跨網壅塞也很常見：白天測試為 70 ms，晚間可能在 90 ms 至 400 ms 之間跳動。只在上午測試一次，不能代表晚間的實際體驗。

目標服務針對不同出口位址的調度，也會改變速度。同一節點存取測試 URL 很快，存取影片服務時卻可能被分配到距離較遠的 CDN；某些出口還可能遇到目標網站限速。此時問題發生在代理出口到目標服務之間，不一定是使用者裝置到代理伺服器的這一段。

用一組可重現的步驟判斷實際體驗

更可靠的判斷方式不是尋找一個絕對最低的數字，而是在相同裝置、相同網路與相同時段下，比較多輪結果。測試前先暫停雲端硬碟同步、系統更新與大檔案下載，避免背景流量佔滿頻寬。手機測試時固定使用 Wi-Fi 或行動網路，不要在兩者之間自動切換。

第一步：連續測試五次延遲

1. 開啟用戶端的代理或節點頁面，找到需要比較的同一個代理群組。
2. 保持測試 URL 不變，連續執行五次，每次間隔約 10 秒。
3. 記錄最低值、最高值與大致平均值，不要只看最後一次結果。
4. 如果五次分別為 82、87、79、91、84 ms，可視為相對穩定；如果為 60、320、75、timeout、180 ms，應優先排查抖動與丟包。

圖形化用戶端的選單名稱各不相同，通常可在「代理」→「代理群組」→「延遲測試」找到測試入口；部分用戶端也會在「設定」→「參數設定」中提供測試 URL 與逾時時間。修改前先記下原值，避免因無法存取的網址導致所有節點都顯示失敗。

第二步：測試持續吞吐量

選擇兩到三個延遲較穩定的節點，分別進行至少 30 秒的實際下載或影片播放。觀察的是穩定速度，而不是剛開始的一次峰值。例如下載速度先衝到 18 MB/s，5 秒後長時間停留在 1.2 MB/s，這個節點的可持續吞吐量更接近 1.2 MB/s。比較時應使用同一個目標檔案、同一時段，並避免多執行緒工作互相爭用頻寬。

若影片是主要用途，可分別播放固定解析度的內容，並觀察 60 秒內緩衝區是否持續增長。1080p 影片所需位元率會隨編碼方式與內容變化，不能只憑「能開啟」來判斷；4K 內容對持續吞吐量與線路穩定性的要求更高。測試期間頻繁手動切換節點會中斷既有連線，因此每輪都應單獨完成。

第三步：依使用情境選擇

• 瀏覽網頁：優先選擇延遲穩定、握手快速的節點，頻寬達到日常需求即可。
• 影片與下載：優先比較持續吞吐量與晚間尖峰時段的穩定性，不必執著於最低延遲。
• 語音與遊戲：重點觀察丟包、抖動與 UDP 可用性，平均延遲只是其中一項。
• 遠端終端機：互動對往返延遲敏感，應選擇連續測試波動較小的線路。
• 行動網路：電梯、捷運與基地台切換會顯著改變結果，應在實際使用位置進行測試。

TUN 模式、DNS 與本機網路如何影響結果

TUN 模式會接管更多系統流量，但不會自動提升代理伺服器的頻寬。啟用 TUN 後，應用程式流量可能從原本的系統代理路徑改為虛擬網卡路徑，DNS 劫持、路由表、MTU 與防火牆規則也會參與處理。因此，啟用前後的延遲差異需要結合日誌與實際連線路徑判斷，不能簡單歸因於核心效能。

先排除本機 Wi-Fi 抖動

如果本機路由器本身不穩定，所有節點都會受到影響。可以先比較有線連線與 Wi-Fi，或將裝置移到路由器附近再測試。2.4 GHz 頻段在擁擠環境中容易受到干擾，5 GHz 通常更適合近距離高吞吐量，但穿牆衰減也更明顯。若所有節點同時從 80 ms 升至 500 ms，應先檢查本機鏈路，而不是立即更換訂閱。

DNS 緩慢會拖長首次連線時間

使用網域作為伺服器位址或測試位址時，DNS 查詢速度會影響首次連線。若解析結果異常或上游 DNS 逾時，用戶端可能先等待數秒，才開始真正的代理握手。Clash 的 fake-ip 模式會為網域分配保留位址，並在內部對映真實網域，但最終的上游解析與代理出口連線仍需正常完成。

排查時可以查看 mihomo 日誌中是否反覆出現 DNS timeout、connection refused 或 i/o timeout。若只有某個測試網域失敗，請替換為另一個穩定且回應內容較小的網址進行對照；若所有網域都失敗，則檢查 nameserver、網路權限與系統時間。TLS 憑證驗證依賴正確時間，系統日期偏差過大可能導致 HTTPS 測試直接失敗。

MTU 問題可能只在大流量時暴露

小型延遲請求能夠成功，不代表較大的資料封包一定正常。在 TUN、VPN 疊加或特殊寬頻環境中，MTU 設定不合適可能引發分片或黑洞問題：網頁小型請求可用，大檔案傳輸卻停頓。若啟用 TUN 後只有大流量異常，可以比較關閉 TUN 的系統代理模式，並檢查用戶端的 MTU 設定、系統是否同時執行其他 VPN，以及路由是否形成重複接管。

常見誤判與設定建議

誤判一：延遲最低的節點一定最快

最低延遲只代表某次短請求完成得較快。選擇影片或下載節點時，還需要至少進行一次持續 30 至 60 秒的吞吐量測試。節點延遲相差 20 ms，但穩定速度相差 40 Mbps 時，後者對大流量工作通常更關鍵。

誤判二：一次 timeout 就表示節點失效

一次逾時可能來自測試網站故障、DNS 查詢失敗、本機網路切換或瞬間壅塞。連續測試三至五次，並用另一個測試 URL 進行對照，才能區分節點故障與探測目標故障。如果只有一個節點持續失敗，再檢查節點位址、連接埠、協定參數與訂閱更新時間。

誤判三：測試間隔越短就越準確

過短的間隔會增加請求量，也會讓自動群組對瞬間變化過於敏感。一般家用網路可先使用 300 秒間隔與 30 至 100 ms 的容差，再依節點數量與使用情境調整。即時服務需要穩定連線時，應避免自動群組頻繁切換，因為既有 TCP 工作階段通常不會無感移轉到新節點。

誤判四：啟用 TUN 就能修復所有卡頓

TUN 的主要作用是擴大流量接管範圍，適合不遵循系統代理的應用程式，並不是線路加速開關。伺服器壅塞、出口限速與遠端 CDN 路由問題不會因 TUN 而自動消失。應先確認是流量沒有進入 Clash，還是流量已經經過代理但傳輸品質較差，再決定是否調整模式。

一套更貼近實際體驗的結論

閱讀 Clash 延遲數字時，可以將它理解為「目前節點完成一次指定 URL 小型請求所需的時間」。它能快速篩選出無法連線或握手明顯過慢的節點，也能為 url-test 自動選擇提供依據，但無法單獨回答影片是否流暢、下載速度能達到多少，或遊戲是否穩定。

實際選擇時，先看五次延遲的波動，再看 30 至 60 秒的持續吞吐量，最後在常用時段驗證目標服務。網頁與遠端終端機更重視穩定的低延遲，影片與下載更重視持續頻寬，遊戲與通話還要檢查丟包、抖動及 UDP 路徑。分開測量這幾項指標，才能解釋「顯示幾十毫秒卻仍然卡頓」的真正原因。

如果所有節點同時變慢，應依序檢查本機 Wi-Fi、測試 URL、DNS、系統時間與晚間尖峰壅塞；如果只有單一節點異常，再檢查該節點的伺服器負載、出口路由與協定設定。按照這個順序排查，比反覆重新整理延遲或盲目切換模式更容易找出問題。