正確給節點測速：延遲、頻寬與常見誤區

延遲測試測的是什麼

用戶端的延遲測試是透過節點向一個測試位址發一次 HTTP 請求，記錄從發起到收到回應的時間。mihomo 預設用的是一個回傳 204 空回應的位址，例如 http://www.gstatic.com/generate_204。

這個數字包含建連、TLS 握手與一次往返，反映的是「回應快不快」，和「能跑多少 MB/s」沒有直接關係。一條走香港中轉的線路可能只有 60ms 但頻寬被限死，一條延遲 200ms 的直連線路反而能跑滿。

三個讓數字失真的因素

• 並發測試。很多用戶端點一次就同時測幾十個節點，全部流量擠在你本地這一條出口上，結果整體偏高。要比較關鍵的幾個節點，一個一個單獨測更準。
• 測試位址本身。若測試 URL 有就近 CDN 或被解析到別處，不同節點測到的其實不是同一個目標。自己指定測試位址時盡量選全球一致的服務。
• 快取與重用。剛測過的節點連線可能還在，第二次測會明顯偏低。想對比就間隔一會兒再測。

怎麼測實際頻寬

1. 先固定變數：只保留一個節點被選中，關掉自動切換和負載平衡策略群組，否則測到一半可能已經換了節點。
2. 用瀏覽器跑一次常規測速網站，記下下載與上傳數字。這測的是「你的網路 + 節點 + 測速伺服器」整條鏈路，也正是你日常體驗到的東西。
3. 換成直連再測一次作為對照。若直連本身只有 20Mbps，節點再好也超不過它。
4. 同一個節點在不同時段各測一次。晚上尖峰和凌晨的差距常常比不同節點之間的差距還大。

測速網站本身也會走代理，選伺服器時注意它挑的是哪個地區，測到一個離出口很遠的伺服器結果會明顯偏低。

怎麼依用途選

• 看影片、下載：優先頻寬，延遲一兩百毫秒基本無感。
• 開會、遊戲、SSH：優先延遲與穩定性，抖動比平均延遲更重要。同一個節點連續測五次，數字跳來跳去的比穩定在 150ms 的更糟。
• 日常瀏覽：延遲影響更明顯，因為一個頁面要發幾十個請求，每個都吃一次往返。