Clash 節點延遲測速原理：為何 URL Test 數值與實際網速不符？

一、URL Test 測的是請求耗時，不是下載頻寬

在 Clash Nyanpasu 等用戶端中，節點旁顯示的毫秒數通常來自核心的 URL Test：透過指定代理存取測試網址，記錄完成這次探測所需的時間。這不是對節點伺服器執行一般 ICMP Ping，也不是下載大型檔案後計算傳輸速率。要判斷「這個節點快不快」，得先確認畫面顯示的是哪種測試結果。

以常見的 HTTPS 輕量探測為例，請求可能包含建立代理連線、代理協定交握、連接目標網站、TLS 交握及 HTTP 回應。網域解析在哪一端進行、連線能否重複使用，以及核心版本和延遲統計設定，都會影響最終數值。因此，不能把畫面上的 180 ms 簡單解讀為「本機到節點伺服器的往返延遲」。

先看單位：ms 表示時間，MB/s 或 Mbps 表示傳輸速率。短請求只傳送少量資料，無法據此推算線路可持續承載多少流量。

三種「測速」回答不同問題

即使伺服器封鎖 ICMP，也可能正常提供代理服務；反過來說，伺服器可以 Ping 通，代理連接埠卻可能無法使用。排查 Clash 節點時，以 URL Test 判斷代理路徑，比只看 Ping 更貼近實際存取情況，但仍需搭配實際應用測試。

二、延遲低卻下載慢：交握、頻寬與壅塞的差異

延遲可理解為一次互動需要等待多久，頻寬則表示單位時間內能傳輸多少資料。小型探測可能只回傳回應標頭，即使出口頻寬不高，也能迅速完成；下載數百 MB 的檔案時，線路限速、共用出口負載及目標伺服器限速才會充分顯現。

用一組示意數據看出差異

以下數據僅用來說明判斷方式，不代表任何服務的實測保證。假設在同一裝置、同一測試網址及同一時段測得以下結果：

如果要下載大型檔案，節點 B 更值得一試；如果只是傳送少量短請求，節點 A 在低負載時可能回應較快，但其最高耗時也顯示穩定度仍待觀察。1.2 MB/s 約為 9.6 Mbps，9.0 MB/s 約為 72 Mbps；比較前也要先統一位元組與位元單位。

• 網頁首次開啟：會受 DNS、連線交握、首位元組及多個資源請求影響，因此延遲較重要。
• 大型檔案下載：持續傳輸速率、封包遺失後的重傳及伺服器限制更重要。
• 影片播放：需要充足且穩定的傳輸速率；短暫的高峰值不代表緩衝能持續跟上。
• 即時互動：除了平均延遲，也要留意抖動、封包遺失及實際使用的 UDP 路徑。

晚間尖峰時段的壅塞通常會同時拉高延遲、降低傳輸速率，但也可能只在持續傳輸時才顯現。閒置狀態下的一次 80 ms 探測，無法代表接下來十分鐘的線路負載。

三、測試網址與逾時設定為何會改變排名

測試網址決定「測到哪裡」

URL Test 不會在抵達代理入口時就結束，還會經過代理出口到測試目標的路徑。更換測試網域可能改變 CDN 節點、解析結果、TLS 行為及出口路由。某個節點離測試網站很近，不代表它連到程式碼託管網站、串流服務或辦公系統也很近。

常見的輕量測試網址會回傳 HTTP 204，以減少回應內容對結果的干擾。例如 https://www.gstatic.com/generate_204 可做為其中一種探測選項，但無法保證在所有出口及網路環境下都能使用。不要選擇需要登入、有驗證碼或頻繁重新導向的頁面作為通用探測目標。

• 比較不同節點時，請固定 URL、協定及逾時設定。
• 排查特定網站時，應另外測試該網站的實際請求，不要用通用探測結果取代。
• 如果多個節點同時測試失敗，先確認測試網站本身是否可連線。
• 不要改用較容易回應的網址，讓實際服務故障看起來像是「節點正常」。

逾時是等待上限，不是節點延遲值

假設兩次測試的等待上限分別為 3000 ms 和 10000 ms，某節點需要 4200 ms 才能完成探測，前者會失敗，後者則可能取得有效結果。延長等待時間只是讓結果有機會回傳，並不會讓線路變快。用戶端顯示「逾時」也不代表節點永久失效，只表示這次探測未能在指定條件內成功完成。

測試失敗也可能是網域解析、TLS、連線遭拒或測試目標限制所致，需搭配核心記錄判斷。不同用戶端的手動測試、策略組健康檢查及 provider 健康檢查，可能採用不同參數；不要假設修改某個畫面選項就會影響所有探測。

四、如何設定 mihomo 的 url-test 策略組

url-test 策略組會依據探測結果自動選擇候選代理，適合交由核心處理「優先選擇低延遲節點」的需求。以下是設定片段，假設完整設定的 proxies 中已存在名為「香港入口 A」和「日本入口 B」的兩個代理。請先備份設定，再透過用戶端支援的設定編輯或覆寫方式合併；不可將此片段當成完整訂閱直接匯入。

proxy-groups:
  - name: 自動延遲
    type: url-test
    proxies:
      - 香港入口 A
      - 日本入口 B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

• interval: 300：檢查間隔為 300 秒，不是 300 毫秒。
• tolerance: 50：切換容差為 50 毫秒，可減少延遲小幅差異造成的頻繁切換；這不是逾時參數。
• lazy: true：未使用此策略組時，可避免持續執行定期測試；但也不應因此預期背景會一直保留最新探測結果。
• proxies：引用已定義的代理或策略組名稱，拼寫必須與設定一致。

只有在規則或上層策略組選用此策略組時，它才會參與相應連線的出口選擇。建立策略組卻未引用它，瀏覽器流量不會自動改走此組。對於已建立的下載或長連線，策略變更通常也無法將現有連線無縫切換至其他節點；需建立新連線後再觀察。

自動選擇不等於頻寬排名：url-test 依據探測延遲選擇路徑，不會自動下載大型檔案來測出各節點的持續頻寬。下載時可使用手動選擇組固定節點，再另外比較傳輸速率。

如果候選節點來自 proxy-providers，也要檢查 provider 的 health-check 設定。它與策略組探測各有不同用途及參數。訂閱更新可能會覆蓋直接編輯的內容；如需長期保留調整，請使用目前用戶端支援的覆寫機制，並在載入後確認實際生效的設定。

五、統一測試條件：可重現的節點比較流程

1. 固定網路環境。使用同一台裝置及同一個 Wi-Fi 或有線網路測試；暫停系統更新、雲端硬碟同步及其他大型下載，避免占用本地頻寬。
2. 確認流量路徑。在連線清單中查看目標網域符合哪條規則，以及最後選用哪個代理。在規則模式下，測試網站可能會直連，但延遲探測仍會透過候選節點進行，兩者不能直接比較。
3. 固定候選節點。暫時改用手動選擇，避免自動策略組在測試期間切換。每次切換後都建立新的應用程式連線；必要時先停止舊下載，再重新開始。
4. 重複輕量探測。每個節點測試 5 次，間隔約 5 秒，記錄成功次數、中位數及最大值。不要只記下最低的一次。
5. 補充實際使用測試。使用同一個下載網址，各進行約 30 秒的單一連線傳輸，觀察穩定階段；多連線結果應另外記錄，不要與單連線混在一起計算。
6. 不同時段複查。白天及晚間尖峰時段各測一輪。如果只有晚間尖峰時段明顯變慢，應優先考慮負載及路由壅塞，而不是一再重新安裝用戶端。

使用 curl 檢查指定的本機 HTTP 代理

以下指令假設設定中的 mixed-port 為 7890，且允許本機存取，也沒有額外的代理驗證。若連接埠不同，請以目前生效的設定為準。Windows PowerShell 可使用 curl.exe，避免舊版環境中的同名命令別名影響參數解析。

curl --proxy http://127.0.0.1:7890 --output /dev/null --silent --show-error --connect-timeout 5 --max-time 10 --write-out "status=%{http_code} first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://www.gstatic.com/generate_204

上述輸出檔案的寫法適用於 macOS 和 Linux；在 Windows 上使用時，請將 /dev/null 改為 NUL。--connect-timeout 5 設定連線階段的等待上限，--max-time 10 限制整個請求最多等待 10 秒，輸出時間單位為秒。這個指令測得的是 curl 透過本機代理發出請求的表現，不保證與核心 URL Test 的毫秒數完全相同。

解讀測試結果時，必須搭配連線清單查看：本機 HTTP 代理收到請求後，核心仍會依照目前的模式與規則選擇出口。只加上 --proxy，並不能證明請求一定使用了準備比較的遠端節點。

六、常見異常：從逾時到影片卡頓

所有節點突然逾時

先確認目前網路能正常存取基本服務，再檢查訂閱中的伺服器位址是否解析成功、測試目標是否可連線，以及記錄中是否出現連線遭拒或 TLS 錯誤。可改用另一個穩定的輕量 HTTPS 網址交叉驗證。一次批次測試失敗，不足以判斷所有節點同時失效，也不適合立刻刪除所有設定。

顯示 60 ms，開啟網頁卻要好幾秒

先確認網頁流量實際上是否經過這個節點，再查看瀏覽器是否重複使用舊連線。網頁可能載入數十個第三方資源，其中一個網域的解析或請求受阻，就足以拖慢整個頁面。瀏覽器開發人員工具的網路面板可區分等待首位元組和下載內容所需的時間，協助判斷是交握、伺服器回應還是傳輸速度較慢。

測速正常，影片仍持續緩衝

請查看影片服務本身提供的連線速度、緩衝長度等統計資料，不要只看 Clash 延遲。媒體 CDN 與探測網站可能使用不同路徑，出口也可能受到特定服務的限制。如果 HTTP 探測成功，但實際服務使用 UDP 或 QUIC，還要分別確認該路徑是否受支援；單次 HTTPS 探測無法驗證所有協定。

啟用 TUN 後，數值或實際使用情況有所變化

TUN 改變的是流量接管方式，不會直接增加線路頻寬。切換前後應檢查 DNS 接管、路由及其他代理軟體是否發生衝突。核心本身的節點探測與應用程式透過 TUN 進入核心的實際流量，不一定經過完全相同的本機路徑，因此應參考實際連線記錄來判讀差異。

七、選擇節點：先確認可用，再看穩定度與用途

日常選擇節點可分三個階段判斷：先確認目標服務能否存取，再比較重複探測的成功率和波動，最後依照網頁、下載或影片需求補做測試。穩定維持 150 ms 的節點，往往比偶爾達到 50 ms、卻經常逾時的節點更適合長期使用。

• 網頁與辦公：留意多次連續請求的耗時及實際使用成功率。
• 下載與更新：在相同來源及相同連線數下，觀察持續傳輸速率。
• 影片與會議：留意緩衝、抖動、封包遺失及相應協定的實際表現。

將 URL Test 視為「針對指定目標進行的輕量可用性與延遲探測」，就不容易被單一數字誤導。變更測試網址、逾時設定或策略組之前，先保留原始條件及比較記錄；每次只調整一個項目，才能判斷改善究竟來自設定變更，還是恰好遇上線路負載變化。