Clash 節點延遲測試原理：為什麼顯示的毫秒數不等於實際網速

延遲數字實際測量了什麼

Clash 用戶端顯示的 38 ms、126 ms 或 480 ms，通常不是傳統意義上的 ICMP Ping，也不是下載速度。用戶端一般會要求 Clash 或 mihomo 核心透過指定代理節點存取 HTTP 或 HTTPS 測速 URL，再記錄從發出請求到收到有效回應所需的時間。不同用戶端的按鈕可能稱為「延遲測試」、「測速」或「健康檢查」，但核心目標相近：確認節點能否連線，並估算一次短請求的往返時間。

常見測速網址會回傳 HTTP 204。204 回應沒有正文，傳輸量很小，適合重複探測。例如 https://www.gstatic.com/generate_204 和 https://cp.cloudflare.com/generate_204 都屬於這類網址。由於回應內容接近於零，測試結果主要反映連線建立與請求回應速度，無法反映節點持續傳輸 100 MB 檔案時能達到多少 MB/s。

一次 HTTPS 延遲測試可能包含的步驟

Clash 接收用戶端發出的測試指令，並選定一個代理節點。
核心解析節點伺服器位址，建立到節點入口的 TCP 或其他傳輸連線。
完成 Shadowsocks、VMess、VLESS、Trojan 或其他協定所需的握手。
透過節點連線至測速網站，並完成與目標網站的 TCP 與 TLS 握手。
傳送 HTTP 請求，等待狀態碼與回應標頭返回。
用戶端將整段耗時換算為毫秒並顯示。

實際計時邊界取決於用戶端與核心版本。有些實作每次都建立新連線，有些健康檢查可能重複使用部分資源；有些會將 DNS 解析計入時間，有些則會命中 DNS 快取。因此，兩個用戶端同時測試同一節點時，出現 20 至 80 ms 的差異並不罕見。判斷節點狀態時，應優先比較同一裝置、同一用戶端、同一測速 URL 下的結果。

為什麼低延遲節點仍然很慢

低延遲表示短連線探測速度快，但網頁載入、軟體下載與影片播放還會受到吞吐量、封包遺失、目標網站線路與伺服器負載影響。測速請求只有少量回應標頭，即使節點出口限速為 5 Mbps，也可能在 50 ms 內完成一次 204 請求。真正下載檔案時，5 Mbps 的理論上限約為 0.625 MB/s，速度差異才會持續顯現。

節點頻寬或共用入口壅塞

代理入口通常由多位使用者共用。晚上 20:00 至 23:00 的並發流量可能明顯高於上午。節點閒置時延遲為 45 ms，忙碌時仍可能維持在 58 ms，但下載速度從 18 MB/s 降至 2.4 MB/s。原因是小請求仍能迅速排隊完成，大流量則會持續爭用出口頻寬。

封包遺失與抖動不會直接顯示

用戶端通常只顯示最近一次成功測試，或顯示多次結果中的某個數值。假設連續十次結果為 52、54、55、53、410、逾時、61、58、390、57 ms，如果介面只保留最後一次的 57 ms，就會掩蓋明顯的抖動與封包遺失。網頁中的大量並發請求會反覆遇到重傳，表現為圖片分批出現、頁面偶爾停頓。

測速網站與實際目標網站的線路不同

節點到測速 URL 的路由很短，不代表到程式碼託管、影音平台或網路硬碟的路由同樣理想。節點存取測速網站可能走本地互聯，延遲只有 35 ms；存取實際目標網站時卻繞行其他地區，首位元組時間達到 900 ms。測速 URL 只能代表它本身，不能取代對目標服務的驗證。

本地線路與裝置負載

2.4 GHz Wi-Fi 干擾會造成重傳，短測試偶爾正常，大型檔案傳輸卻持續波動。
在 TUN 模式下，防毒軟體、系統防火牆與其他網路過濾程式可能增加處理時間。
低效能路由器處理加密流量時可能達到 CPU 上限，延遲數字仍低，但吞吐量無法提升。
瀏覽器擴充功能、並發下載與系統背景更新會佔用本地頻寬，影響實際體驗。
MTU 設定不合適時，部分連線可能出現分片、重傳或特定網站載入停滯。

為什麼高延遲節點也能流暢播放影片

影片播放依賴持續吞吐量與緩衝區，不要求每個資料片段都在幾十毫秒內返回。一個延遲為 180 ms、穩定速度為 25 MB/s 的節點，通常可以比延遲 45 ms、速度只有 2 MB/s 的節點更快填滿緩衝區。開始播放後，只要下載速率長期高於影片位元率，較高延遲對連續播放的影響就很有限。

以 4K 影片為例，若平均位元率為 25 Mbps，換算後約為 3.125 MB/s。節點能穩定提供 12 MB/s，即使延遲達到 220 ms，也有足夠餘裕維持播放。相反地，一個延遲 30 ms、但晚間尖峰速度在 1.5 至 4 MB/s 之間波動的節點，可能頻繁耗盡緩衝區。

互動操作與大流量任務重視的指標不同

使用情境	更重要的指標	常見表現
開啟網頁、線上文件	延遲、首位元組時間、封包遺失	低延遲通常能讓多個小請求更快完成
影片播放	持續吞吐量、抖動、可用頻寬	延遲較高仍可依靠緩衝保持流暢
大型檔案下載	持續速度、出口限速、線路穩定性	開始幾秒的峰值不能代表平均速度
遠端終端機、雲端桌面	往返延遲、抖動、封包遺失	80 ms 與 250 ms 的操作回饋差異明顯
語音與即時通訊	延遲、抖動、UDP 可用性	頻寬足夠時仍可能因抖動出現斷續

測速 URL 會如何改變結果

測速網址的位置、協定與回應狀態都會影響數值。選擇 HTTPS 網址時，測試通常包含 TLS 建立連線；選擇 HTTP 網址時則少一層 TLS。測速網站距離節點出口較近，結果會偏低；測速網站跨洲或回應繁忙，結果會偏高。若測速網站受到目標網路限制，即使節點本身正常也可能顯示逾時。

選擇測速 URL 的三項標準

回應穩定：連續存取時狀態碼一致，避免重新導向、驗證碼與動態頁面。
回應很小：使用 204 或小型靜態檔案，避免健康檢查持續消耗流量。
符合實際用途：主要存取某一地區的服務時，測速網站也應能代表該地區的出口品質。

不要直接排序兩個不同 URL 得到的毫秒數。例如節點 A 存取亞洲測速網站為 48 ms，節點 B 存取歐洲測速網站為 130 ms，這組資料沒有公平比較的基礎。批次測試時應確保節點群組使用相同 URL、相同逾時時間與相近的測試時刻。

如何設定 url-test 與健康檢查

Clash 和 mihomo 設定中的 url-test 策略群組會定期測試候選節點，並選擇目前延遲較低的節點。它適合自動選擇，但不等於持續測試下載速度。interval 控制檢測週期，單位通常為秒；tolerance 用於減少延遲接近時的頻繁切換。

proxy-groups:
  - name: 自動選擇
    type: url-test
    use:
      - 代理訂閱
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

這段設定每 300 秒檢查一次。「自動選擇」群組不會因為新節點只快 10 ms 就立即切換；設定 tolerance: 80 後，差異較小時會優先維持目前節點，從而減少連線中斷。對網頁瀏覽而言，50 至 100 ms 的容差通常比追逐毫秒差異更實用。即時會議期間也不建議將週期設為 10 秒，因為頻繁檢測與切換會增加不必要的連線變化。

代理提供者也可以單獨設定健康檢查。以下片段表示每 600 秒確認一次訂閱內節點是否可連線：

proxy-providers:
  代理訂閱：
    type: http
    path: ./providers/airport.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
      lazy: true

lazy: true 表示相關代理提供者未被使用時，減少主動檢查；實際行為以所用核心版本為準。若用戶端已透過圖形介面管理設定，直接編輯執行期間產生的 YAML，可能在訂閱更新後被覆蓋。建議優先使用用戶端的覆寫或合併設定功能來新增規則。例如 Clash Verge Rev 2.x 常見操作路徑為「設定」→「訂閱設定」→ 選擇設定檔 →「編輯全域擴充設定」，完成後重新載入訂閱並檢查執行中的設定。

更貼近實際體驗的測試方法

選擇節點時，可以將測試拆成「回應速度」、「持續吞吐量」與「穩定性」三組，而不是只按一次閃電按鈕。所有比較都應固定裝置、網路、時段與代理模式。混合測試 Wi-Fi 與有線網路、系統代理與 TUN 模式，都會讓結論失去可比性。

第一步：重複測試延遲並查看中位數

在 Clash Verge Rev 2.x 中進入「代理」→ 目標策略群組。
點擊策略群組右上角的測速按鈕，等待整個群組的節點完成測試。
對候選節點重複測試 5 至 10 次，每次間隔約 10 秒。
記錄中位數、最高值與逾時次數，不要只記錄最低值。

一組結果為 68、71、69、74、70 ms，中位數是 70 ms，波動很小；另一組為 42、45、310、逾時、53 ms，最低值較好但穩定性較差。網頁瀏覽與遠端操作通常更適合第一組。

第二步：測試持續下載而非瞬時峰值

選擇來源穩定、距離與用途相近的 100 MB 至 500 MB 測試檔案，連續下載至少 30 秒。忽略開始 2 至 3 秒的峰值，記錄第 10 秒、第 20 秒與第 30 秒的速度。例如節點 A 延遲 46 ms，三次讀數為 8.2、7.9、7.8 MB/s；節點 B 延遲 128 ms，讀數為 30.5、31.4、30.8 MB/s。若是下載任務，顯然應選擇節點 B。

測速會產生實際流量。行動網路或按量計費的線路應縮小檔案大小，並停止其他下載任務。瀏覽器開發人員工具中的「網路」面板可以查看請求耗時；以 Chromium 系列瀏覽器為例，按下 F12 後進入「網路」，選擇目標請求，在「計時」中查看「等待伺服器回應」與「內容下載」階段。

第三步：檢查目標服務

網頁使用情境：連續開啟 5 個常用頁面，觀察首屏是否快速出現。
影片情境：固定使用相同畫質，記錄開始播放時間與 10 分鐘內的緩衝次數。
下載情境：使用同一個檔案來源，記錄 30 秒平均速度。
遠端連線：連續操作 3 至 5 分鐘，觀察鍵盤回饋與畫面跳動。
TUN 模式：分別測試啟用前後的結果，確認問題是否來自系統代理的涵蓋範圍。

延遲異常時按環節排查

所有節點同時升高

先檢查本地網路。關閉正在執行的雲端硬碟同步與系統更新，使用有線連線或 5 GHz Wi-Fi 後再測。如果直接連線開啟網頁也明顯變慢，問題更可能出在本地寬頻、行動網路或路由器。重新啟動 Clash 只能重建代理連線，無法修復電信業者線路壅塞。

只有一個地區升高

同一地區的多個節點同時從約 80 ms 上升到 300 ms，可能是跨境路由調整或區域入口壅塞。可以暫時選擇另一個地區，並分別在白天與晚間尖峰測試。若凌晨恢復、晚間反覆升高，通常比用戶端設定錯誤更符合壅塞特徵。

測速逾時但網頁可以開啟

更換測速 URL 後重新測試，並確認 DNS 模式正常。使用 Fake-IP 時，測速網域會先取得保留位址，再由 Clash 在連線階段還原網域；若規則將測速網域錯誤分配至直連或拒絕策略，測試可能失敗。檢查日誌中的目標網域、命中規則與出站節點，可以確認請求是否真正經過待測代理。

延遲正常但部分網站很慢

在日誌中確認該網站是否命中預期的策略群組。Clash 規則會由上至下比對，命中第一條後即停止。若目標網站被較前面的 DOMAIN-SUFFIX、GEOSITE 或 IP-CIDR 規則分配到其他節點，策略群組中顯示的低延遲就與實際連線無關。也應檢查瀏覽器是否啟用了獨立代理、HTTP/3 或安全 DNS，避免流量路徑與預期不同。

節點排序應同時查看四項數值

單一毫秒數適合快速排除不可用節點，不適合決定所有使用情境。更穩妥的記錄方式包括延遲中位數、最大抖動、逾時率與持續下載速度。例如節點甲的資料為 72 ms、抖動 12 ms、逾時率 0%、平均 14 MB/s；節點乙為 41 ms、抖動 280 ms、逾時率 20%、平均 6 MB/s。雖然節點乙顯示的最低延遲較低，節點甲通常更適合作為預設節點。

自動策略群組也應保留一定容差。兩個節點分別為 64 ms 和 71 ms 時，7 ms 的差異通常不足以抵銷切換現有連線的成本。只有在延遲差異長期穩定，或吞吐量與目標網站體驗也更好時，切換才有實際意義。將測速結果當作篩選入口，再用實際任務驗證，得到的節點選擇會比依一次測試結果排序可靠得多。