Clash 延遲測試原理：URL Test 數值為何不等於實際上網體驗

URL Test 測量的是小型請求耗時，不是下載速度

先說結論：Clash 客戶端顯示的延遲，通常是核心透過指定代理存取測試 URL 所需的請求時間。它不只是 ICMP Ping，也不代表節點頻寬，更不能直接換算成影片畫質。要判斷節點是否適合目前的用途，還得一併觀察延遲波動、持續傳輸能力、目標網站是否可用，以及實際套用的規則。

客戶端負責發起測試並顯示結果；核心則負責建立代理連線、存取目標。介面上的「延遲測試」和「連線測試」可能呼叫不同介面；是否採用統一延遲、是否以第二次請求的結果為準，也取決於核心與客戶端設定。比較兩組結果前，請先確認測試網址和測試方式相同。

• URL Test：測試小型 HTTP 請求能否成功，以及完成測試所需的時間，通常以毫秒顯示。
• 下載測試：測量一段時間內傳輸的資料量，通常以 MB/s 或 Mbps 顯示，並會實際消耗流量。
• 實際使用：還會受到 DNS、連線重用、頁面資源並行載入、伺服器處理，以及應用程式本身等待時間影響。

一次延遲測試會經過哪些環節

測試路徑可簡化為「本機 → 代理入口 → 代理出口 → 測試網站」。實際架構可能包含中繼站或多層代理，入口和出口也不一定位於同一地區。一次請求會受到各環節共同影響，但哪些步驟會計入顯示數值，則視核心實作、快取狀態及是否重用連線而定。

1. 解析連線所需的網域名稱。代理伺服器的網域需要解析；測試目標的解析位置則與代理協定、DNS 設定及核心行為有關，不能一概認定都由本機處理。
2. 建立與代理伺服器的連線。依協定不同，可能會進行 TCP、TLS 或 UDP 傳輸交握。首次連線通常比重用既有連線耗時更久。
3. 透過代理存取測試目標。從代理出口連到測試網站，還會經過路由、壅塞佇列及目標網站的處理。
4. 接收 HTTP 回應。若使用 HTTPS，還會與測試網站建立 TLS 工作階段。回應狀態、重新導向及逾時處理也會影響測試結果。

為什麼第二次測試可能快上許多

DNS 快取、連線重用和 TLS 工作階段恢復，都可能縮短後續請求的耗時。mihomo 的 unified-delay 選項可減少不同代理協定的交握耗時對延遲比較造成的影響；啟用後的數值不宜與其他測試方式的結果混在一起比較。排查問題時請維持此選項不變，別把切換設定前後的差異當成線路改善。

批次測試也會同時建立多條連線。若路由器效能有限、使用行動網路，或節點限制並行連線數，測試本身就可能造成資源競爭。連續按好幾次「全部測試」，不見得能得到更可靠的排序。

測試 URL 如何影響節點排序

測試網址不是無關緊要的參數。不同網域可能使用不同 CDN；即使是同一網域，也可能因代理出口和 DNS 解析結果而連到不同機房。某個節點到測試網站的路徑較短，不代表連到影音平台、程式碼代管服務或工作網站時也一樣。

挑選測試網址的三項條件

• 回應內容精簡：優先選用穩定且回應內容精簡的端點，例如回傳 HTTP 204 的連線檢查網址，減少傳輸本文造成的干擾。
• 存取條件穩定：避開需要登入、驗證碼、地區授權或經常重新導向的頁面。
• 測試條件一致：比較同一組節點時，使用相同 URL、逾時設定和網路環境，不要把不同網站的結果混在一起。

https://www.gstatic.com/generate_204 是常見範例，HTTPS 預設使用 443 連接埠。它適合做為小型請求的探測目標，但不能代表所有網路服務。若本地網路或某個出口無法正常連線至此網址，測試失敗也不能直接推論節點完全無法使用。

更換測試網址後，建議重新測試整組節點並記下切換時間。不要只重測單一節點，再拿新結果和其他節點的舊快取數值比較。

為什麼低延遲節點還是會卡頓

小型請求很快，不代表持續傳輸也快

很小的回應可能在壅塞變嚴重前就已經傳回。下載大型檔案或播放高位元率影片則需要持續傳輸，更容易遇到頻寬不足、封包遺失與重傳、尖峰時段壅塞或連線重設等問題。延遲衡量的是回應時間，吞吐量衡量的是傳輸能力；兩者彼此相關，卻不是同一項指標。

以單位換算為例：20 Mbps 的理論傳輸速度約為 2.5 MB/s，實際應用還須扣除協定額外負擔。這只是換算範例，並非節點實測數據。延遲 60 ms 的節點，下載速度完全可能比延遲 150 ms 的節點慢。

實際流量可能根本沒有經過受測節點

單節點測試通常會指定該代理進行探測，卻不能證明瀏覽器的請求會套用相同規則和策略組。應用程式可能命中 DIRECT，也可能改走另一個策略組。即使手動選了某個節點，仍須檢查目標網域實際符合的規則及完整代理鏈。

• 在客戶端的「連線」或「連線記錄」頁面找到目標網域，檢查規則、策略組和出口代理。
• 確認目前使用的是規則模式，而非誤切至直連模式；若使用全域模式，則請檢查 GLOBAL 的選擇。
• 若應用程式不遵循系統代理設定，請確認是否需要透過 TUN 接管流量，以及該應用程式是否被排除在路由之外。

HTTP 探測無法涵蓋 UDP 與服務權限

常見的 HTTPS 探測主要用來確認相應的 HTTP 請求路徑。遊戲、語音及部分 QUIC 流量使用 UDP，節點協定支援、伺服器設定和本機路由都可能不同。測試成功不代表 UDP 一定可用；啟用 TUN 也不代表所有網域解析和 UDP 轉送問題都會自動解決。

此外，目標服務可能會限制出口 IP、帳號地區或請求頻率。若頁面顯示地區限制、403 或驗證碼，應檢查服務回應，不要只看延遲數值而反覆切換節點。

url-test 策略組：interval 和 tolerance 怎麼設定

url-test 是用來自動比較探測結果的策略組，不是下載測速工具。以下範例適用於支援這些欄位的 mihomo 核心。節點-A 和 節點-B 必須是現有 proxies 中定義的名稱，使用前請換成實際名稱；不要直接用這段局部設定覆蓋整份訂閱內容。

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

  - name: 出口選擇
    type: select
    proxies:
      - 自動延遲
      - 節點-A
      - 節點-B

rules:
  - MATCH,出口選擇

這裡的 MATCH 僅用來示範流量如何進入策略組。既有設定應保留原本的區域網路、直連及業務分流規則，再將預設流量或指定服務導向相應的策略組。若設定中已有 proxy-groups 或 rules，請合併項目，不要重複新增頂層鍵。完整欄位結構請參閱YAML 手冊。

先從 300 秒和 50 毫秒開始，再依波動情況調整

一般瀏覽用途可先將 interval: 300、tolerance: 50 作為起始值，但這不是適用所有情況的最佳設定。若節點數量較多，或裝置使用行動數據，可考慮將間隔延長至 600 秒；若網路經常切換，需要更即時的結果，可在確認負載後嘗試 120 秒。策略組未使用或裝置進入休眠等情況，都會影響實際探測時間。

容差設定是在穩定性與切換速度之間取捨。假設目前使用的節點延遲為 120 ms，另一個節點是 100 ms，只快了 20 ms；若容差設為 50 ms，通常會傾向保留目前可用的節點。若另一個節點是 60 ms，改善達 60 ms，才較可能觸發切換。以上僅為參數說明範例，實際結果還會受到節點可用狀態、先前探測結果及核心實作影響。

若更新訂閱會覆蓋手動修改，請使用客戶端支援的覆寫或合併功能。各客戶端的功能入口名稱不盡相同；儲存後請確認核心實際載入的執行設定，而不只是編輯器中顯示的文字。

用一套可重複的步驟判斷實際體驗

排查「Clash 測速很快但網頁很慢」時，應分開記錄探測結果和實際服務測試。一次只變更一項條件，才能判斷改善究竟來自節點、規則還是本機網路。

1. 固定測試條件。使用同一個 Wi-Fi 或有線網路、相同的測試 URL 和延遲設定，並暫停占滿上傳或下載頻寬的工作。
2. 記錄連續測試結果。挑選 2～3 個候選節點，每個測試 5 次，間隔約 10 秒。記錄中間值、最大值及失敗次數，不要只留最快的一次。
3. 手動指定候選節點。在 select 組中選定一個節點，避免驗證實際服務期間自動策略組切換出口。
4. 重新建立服務連線。重新開啟目標頁面或重新發起傳輸，並在連線頁面確認網域、命中規則及代理鏈一致。
5. 檢查持續傳輸表現。使用同一個可合法存取的檔案，或相同的影片片段觀察 60～120 秒，分別記錄載入等待時間、緩衝次數及穩定傳輸速率。
6. 檢查本機因素。若所有節點都出現波動，先比較有線與 Wi-Fi 連線、檢查背景上傳及 DNS，再考慮逐一調整代理參數。

記錄表只要包含「時間、節點、測試 URL、5 次延遲、失敗次數、目標服務表現」這六項即可。若問題只在尖峰時段出現，請在相近時段再次測試；凌晨和晚間尖峰的單次數值不能直接比較。

最終選擇應依用途而定：網頁操作看回應速度與穩定性，檔案傳輸看持續吞吐量，遊戲和語音則要看相應的 UDP 路徑及抖動。url-test 適合依照一致的小型請求指標自動篩選，不能取代實際服務測試。保留手動選擇節點的入口，通常比一味縮短測試間隔更容易找出問題。