Clash 延遲測試怎麼看？url-test 測速原理與實際使用體驗差異

延遲數字：單次探測耗時，不代表下載速度

用戶端顯示的 80 ms、230 ms，通常是核心透過指定節點向測試網址發出一次 HTTP 或 HTTPS 探測所得到的結果。這個數值代表「這次請求要多久才收到符合測試條件的回應」，而不是「這條線路每秒能傳送多少資料」。介面上的按鈕即使叫做「測速」，也不一定會下載大型檔案。

先分清楚三種指標：延遲代表單次互動的等待時間，吞吐量代表持續傳輸能力，穩定性則看多次請求的波動與失敗情況。低延遲適合頻繁的小型請求，但不能單憑這項指標判斷影片載入、大型檔案下載或長連線的品質更好。

url-test 原理：透過候選節點存取測試網址

url-test 是一種策略組類型。核心會透過組內的候選出站連線進行 URL 探測，再依據可用性、延遲與切換容差選擇出站。用戶端的手動延遲測試按鈕與策略組的定時探測，可能使用不同網址、逾時設定或呼叫方式，因此不能只看介面數字就判定自動選擇是否異常。

一次探測會經過哪些環節

1. 解析與連線準備：需要解析節點伺服器的網域名稱；目標網域由本機或遠端解析，則取決於協定、DNS 設定與具體實作。
2. 建立代理通道：連線至節點並完成該協定所需的交握，再由節點存取測試目標。若有中繼節點，也會經過中繼線路。
3. 請求測試資源：HTTPS 網址通常還會進行 TLS 交握，接著送出 HTTP 請求並等待回應。
4. 記錄結果：探測成功後會取得耗時；若連線失敗、逾時或回應不符合測試條件，可能會顯示失敗、無法使用或逾時。

上述說明的是請求經過的環節，不代表每種核心都會把每個環節完整計入同一個數值。DNS 快取、連線重用、協定實作與計時起訖點都會影響結果。因此，比較 Clash、Clash Meta（mihomo）及不同用戶端介面顯示的數值時，應確保測試條件相同，不宜直接混在一起比較。

這也不是傳統的 ICMP ping。伺服器停用 ICMP，不代表 HTTP 探測一定失敗；能 ping 通伺服器，也不代表代理驗證、協定交握及目標網站存取都正常。

探測結果不等於實際流量規則

策略組會透過候選出站執行探測，不會先把測試 URL 當成一般瀏覽請求交由整份 rules 判斷節點。實際瀏覽器連線仍會受到運作模式、規則命中結果與策略組選擇影響。若測試走的是節點 A，但網頁最後命中 DIRECT 或其他策略組，實際體驗當然可能不同。

延遲低仍會卡頓：四種路徑差異

小型回應很快，持續傳輸卻很慢

常見的 generate_204 網址會傳回很小的回應，適合用來輕量測試連線是否可用，幾乎不會測到持續吞吐量。節點頻寬壅塞、單一連線限速或出口負載過高時，小型請求仍可能很快，但大型檔案卻傳不動。

例如，以下是假設的指標說明，不是本站實測結果：A 節點的探測延遲為 65 ms，下載速度為 1.2 MB/s；B 節點的探測延遲為 140 ms，下載速度為 8 MB/s。A 的短請求回應較快，但下載同一個檔案時，B 可能更早完成。

測試網站近，實際使用的網站卻遠

測試網址通常由 CDN 提供服務。不同出口地區可能連到不同機房，探測結果好只代表前往該目標的路徑表現良好。存取其他地區的程式碼儲存庫、影音服務或企業後台時，出口之後的路由、互連品質與伺服器負載都可能不同。

單次數值低，連續請求卻不穩定

如果同一個節點連續測出 70、75、620、逾時、82 ms，只看最後一次的 82 ms 就會忽略明顯波動。封包遺失可能觸發重傳，尤其會影響 TLS 連線建立、網頁資源同時載入與長時間傳輸。這裡的「逾時」代表應用層探測失敗，不能直接視為 ICMP 封包遺失率。

實際服務使用 UDP 或其他連線方式

HTTP 探測成功，不代表 UDP 轉送也能正常運作。語音、遊戲或使用 QUIC 的服務還會受到協定的 UDP 支援、伺服器設定、用戶端接管方式與防火牆影響。啟用 TUN 也不會憑空增加節點頻寬；它主要改變流量進入用戶端的方式，無法保證所有服務都和 HTTP 探測走相同路徑。

設定 url-test：先固定測試網址與週期

以下是 mihomo 的策略組設定片段，並非可獨立執行的完整設定。現有的 proxies 中必須已定義名為「香港-A」和「香港-B」的節點；合併時請使用自己的實際節點名稱。不要在檔案結尾再新增第二個同名的頂層 proxy-groups 欄位。

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies:
      - 香港-A
      - 香港-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

• type: url-test：依據 URL 探測結果選擇候選出站，不是頻寬測速組。
• url：本組的探測目標。範例使用常見的輕量 HTTPS 測試端點，實際是否可連線仍須在目前的網路環境中確認。
• interval: 300：定時探測週期為 300 秒，也就是 5 分鐘，不是 300 毫秒。
• tolerance: 80：切換容差為 80 毫秒，用來減少因延遲些微差異而切換的情況。
• lazy: true：依照 mihomo 的懶惰探測機制，未使用的策略組可能不會持續進行週期測試；查看結果時，別假設它一直在背景更新。

訂閱服務供應商也可能透過 proxy-providers 的 health-check 設定健康檢查。提供者的檢查週期、策略組的 interval，以及用戶端介面的手動測試，是不同的設定項目；只修改其中一項，不代表所有顯示與測試行為都會同步改變。

tolerance 怎麼設：減少因些微差異而切換

tolerance 不是「允許的最高延遲」，也不是「低於這個值就算通過」。它用來控制目前選用的節點與較快候選節點之間的切換容差。可以這樣理解：候選節點只快一點時，優先維持目前可用的節點；快到超過設定的差距時，才有理由切換。

以 mihomo 常見的選擇邏輯為例：目前節點為 150 ms，候選節點為 110 ms，兩者只差 40 ms。設定 tolerance: 80 時，通常不會只因這點優勢就切換；若候選節點降至 60 ms，差距達到 90 ms，才會超過這項容差。實際選擇仍會受到目前節點是否可用、有效測試結果與核心實作影響。

調整順序比單一數值更重要

1. 先固定測試網址與網路環境，確認節點沒有頻繁探測失敗。
2. 可以先從 50 到 100 毫秒的容差範圍開始觀察；這只是設定起點，不是適用於所有線路的標準。
3. 若候選節點的延遲相近，卻經常來回切換，可適度提高容差；若明顯較快的節點長期未被選中，再確認延遲差距與目前有效的測試結果。
4. 若目前節點已無法使用，應優先排查健康檢查與失敗判定，不要把容差當成保留故障節點的規則。

切換策略通常只會影響後續新建立的連線，既有 TCP 連線不會因此無縫轉移到另一個節點。切換後舊下載仍然很慢、新網頁卻變快，兩者並不矛盾。也不建議把 interval 改成 1 秒來反覆測試：探測本身會建立連線並產生流量，過於頻繁的檢查可能增加負載，卻無法消除實際線路波動。

如何選擇測試網址：輕量、穩定且用途相符

測試網址應能長期連線，回應內容盡量精簡、不需登入、不依賴短效簽章，也盡可能避免多次轉址。用完整影片頁面、大型檔案或需要驗證碼的網頁進行健康檢查，容易把頁面行為誤判為網路故障。

https://www.gstatic.com/generate_204 可作為起始測試網址，但不一定適用於所有網路。若某個出口連線異常，請檢查記錄、目標可達性與回應狀態，再換另一個穩定且回應精簡的端點交叉驗證。單一網址連線失敗，不足以判定所有服務都無法使用。

HTTP 和 HTTPS 的測試結果也不應混在一起排名。HTTPS 通常會多出 TLS 相關開銷；改用 HTTP 後數值降低，不代表節點線路有所改善。若要測試特定服務，可以另外確認該服務的首次回應時間，但不要把需要登入的服務頁面直接當成所有策略組的常駐健康檢查網址。

對照實際使用體驗：沿同一路徑重新測試

排查「延遲低但網頁很慢」時，先確認探測結果與實際請求使用的是同一個出站，再檢查 DNS、吞吐量與目標服務。用戶端選單名稱可能因版本而異，以下步驟以功能為準，不依賴特定版本的介面配置。

1. 確認運作模式：若需要依規則分流，請確認設定為 mode: rule，並確定目前啟用的是剛修改的設定，而不是另一份 Profile。
2. 確認連線使用的路徑：開啟用戶端的連線清單並存取目標網站，查看該連線命中的規則、策略組與實際出站。必要時搭配記錄進一步排查。
3. 暫時固定節點：透過可手動選擇的策略組固定使用 A 節點，避免比較期間自動切換；測試結束後再恢復原本的策略。
4. 記錄多次測試結果：在相同網路下，使用相同網址測試 10 次，記錄中位數、最大值與失敗次數。失敗次數應另外統計，不要把 0 ms 納入平均值。
5. 補做實際服務測試：在同一個網站下載同一個檔案 30 秒，記錄速度穩定後的數值；測試影音服務時，則觀察緩衝情況、拖曳後恢復速度與持續播放狀況。
6. 分開檢查流量接管：若只有在 TUN 模式下異常，請檢查 DNS、路由與 UDP 支援；若在系統代理模式下，服務流量沒有出現在連線清單，請先確認該應用程式是否遵循系統代理設定。

也要確認本機代理連接埠是否正確。例如設定使用 mixed-port: 7890 時，測試工具應連線到目前用戶端實際監聽的 127.0.0.1:7890；不要把其他用戶端留下的 7897 或 1080 當成通用連接埠。連接埠是否可用，應以生效中的設定與監聽狀態為準。

完成比較後，依故障類型處理：探測穩定但大型檔案下載很慢，優先檢查吞吐量與壅塞；只有特定網站很慢，優先檢查目標路徑與規則；若週期性失敗，則檢查網路波動與節點狀態。延遲數值適合篩選候選節點，最後仍應以實際服務測試結果為準。

常見問題：逾時、手動測試與自動選擇