Clash 節點延遲測試原理：url-test 數值為何與實際網速不符

延遲數值測的是請求耗時，不是下載速度

在 Clash for Windows 的 Proxies 頁面按下測試按鈕，節點旁通常會顯示以毫秒為單位的數值。這個數值適合用來回答「透過這條代理存取測試網址要等多久」，無法直接回答「下載檔案每秒能跑多快」。面板上的 80 ms 和下載工具中的 8 MB/s，代表的是不同指標。

Clash 常見的延遲測試，是透過代理發送 HTTP 請求，並不等同於命令列中的 ICMP ping。測試會透過指定代理向測試 URL 發出請求，再記錄耗時。核心版本、通訊協定、連線重用方式與測試實作各有不同，計時涵蓋的階段也可能不一樣，因此不同客戶端顯示的數值未必採用完全相同的測量標準。

例如，某條線路的首次小型請求很快，傳輸大型檔案時卻遭到限速；另一條線路跨洲往返較慢，持續頻寬卻很充足。前者可能顯示較低的延遲，後者的下載速度反而更快，兩者並不矛盾。

url-test 的請求會經過哪些環節

從本機核心到測試網站

典型路徑為「本機 Clash 核心 → 代理伺服器或代理鏈 → 測試網站 → 返回本機」。測試會建立或沿用代理連線，再存取指定 URL。若使用 HTTPS 網址，也會涉及目標網站的 TLS 交握；網域名稱在哪裡解析，則取決於代理協定、DNS 設定與實際連線路徑。

1. 選擇測試代理：核心會針對節點發起測試；若測試對象是策略組，還要確認該組如何選擇實際出口。
2. 建立連線並送出請求：本機網路、代理交握，以及出口到目標網站的路徑，都可能影響耗時。
3. 判斷請求結果：請求成功後會回傳延遲；若失敗、狀態不符或超過等待期限，介面可能會顯示逾時或錯誤。

測試網址常使用回傳 HTTP 204 的輕量介面。204 表示沒有回應本文，可減少大型檔案傳輸對測量結果的干擾。但這也限制了測試用途：幾乎沒有傳輸本文，自然難以反映持續頻寬。別把這類測試解讀成「已測過下載速度」。

面板測速按鈕與自動選擇組是不同入口

在面板上按一次測速，通常是由客戶端呼叫核心的延遲介面；設定中的 type: url-test 則是定義一個依測試結果自動選擇代理的策略組。兩者使用的測試 URL、逾時參數與觸發時機可能不同。修改策略組中的 url，不代表面板上的測速按鈕也會跟著變更。

url-test 設定：網址、間隔與切換容差

以下是用來說明欄位的策略組片段，採用 mihomo 的寫法。這不是完整訂閱；proxies 中的節點名稱必須已存在於目前設定檔。舊版 Clash 核心與不同分支支援的欄位各有差異，複製前請先查閱對應核心的設定說明。

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

• url：測試目標。範例使用輕量 HTTPS 介面，測試網站是否可用及連線路徑是否暢通都會影響結果，不保證所有網路環境都能使用。
• interval: 300：週期測試間隔為 300 秒，不是每個請求可等待 300 秒，也不代表節點卡住後會立即切換。
• tolerance: 50：切換容差為 50 毫秒，用來避免延遲些微差異造成頻繁切換；這不是頻寬門檻。
• lazy: true：是否執行週期檢查，會依策略組是否正在使用等條件決定，實際行為以核心實作為準。因此，策略組未使用時，面板中的歷史數值可能不會更新。

自動選擇組主要依據延遲與可用性判斷，不會因為某條線路下載較快就自動提高它的排名。選擇結果也不代表既有連線會全部轉移到新節點；長連線通常會繼續沿用原本的連線，重新整理網頁或建立新連線，才比較容易看到切換效果。

逾時門檻與測試間隔要分開看

以相容的核心控制 API 為例，單一節點的延遲介面可使用以下請求格式。這裡的 timeout=5000 代表等待上限為 5000 毫秒，與策略組的週期參數不同。連接埠 9090 只是控制連接埠範例，不是代理連接埠。

GET /proxies/香港入口/delay?url=https%3A%2F%2Fwww.gstatic.com%2Fgenerate_204&timeout=5000

實際呼叫時，節點名稱須先進行 URL 編碼，並依本機設定提供控制介面的驗證資訊。一般排查使用客戶端介面即可，不必為了測速將控制連接埠開放給區域網路。若要查閱設定欄位，可參考設定參考，並留意不要混淆控制連接埠、HTTP 代理連接埠與 SOCKS 連接埠。

低延遲仍然卡頓的五種原因

1. 測試網站距離近，實際服務的路徑卻不同

同一個出口存取輕量測試介面時，可能連到附近的 CDN；存取影片、程式碼儲存庫或檔案網站時，卻可能被分配到其他地區。小型請求順暢，不代表實際服務也走相同線路。跨區存取還可能遇到不同的回程路徑、網路互連壅塞或伺服器端限制。

2. 小型請求很快，持續頻寬卻不足

連線交握只需要傳輸少量資料，即使線路受到限速，也可能很快完成。開始下載後，頻寬限制、共用出口壅塞與伺服器負載才會明顯影響速度。比較傳輸量時，應使用相同來源、相近時段與相同下載方式，不能直接用兩個不同檔案網站的速度判斷節點優劣。

3. 單次延遲低，波動卻很大

一次測得 65 ms，不能代表線路穩定。連續請求若出現 70、75、820 ms，還夾雜失敗，瀏覽網頁時就可能偶爾突然卡住。TCP 重傳會拉長等待時間，而持續資料傳輸也很容易受到封包遺失與抖動影響。觀察一整組測試紀錄，比一再追求最低數值更有參考價值。

4. 實際應用程式沒有使用受測節點

在 Clash for Windows 中，先確認 General → System Proxy 是否已啟用，再到 Proxies → Rule 查看規則模式與目標策略組。遵循 Windows 系統代理設定的程式通常會使用這個入口，但採用自有網路堆疊的程式可能會略過系統代理。

開啟 Connections，依目標網域搜尋連線，確認命中的規則與代理鏈。手動測試的是「日本入口」，實際連線卻命中 DIRECT，結果當然不會一致。自動選擇組、手動選擇組與規則分流也可能層層巢狀，不能只看單一卡片上的名稱。

5. UDP、DNS 或應用程式機制與測試不同

一次 HTTPS 測試無法證明 UDP 轉送可用。遊戲、語音與使用 QUIC 的應用程式可能採用不同的通訊路徑。瀏覽器快取、連線重用、DNS 快取與網站本身的回應速度，也會影響實際感受。TUN 可以接管更多不遵循系統代理設定的連線，但不會憑空增加出口頻寬，也不保證所有流量都會經過代理；最後仍取決於路由、規則與排除設定。

節點顯示 timeout：依影響範圍排查

timeout 只表示這次測試未能在指定條件與時間內成功，不能直接推論「節點已永久失效」。先確認問題影響的是單一節點、單一測試網址，還是整個網路。

1. 所有節點都同時失敗：先確認本機網路正常、核心正在執行，再檢查測試 URL 能否透過已知可用的路徑存取，並查看日誌是否有 DNS 或連線錯誤。
2. 只有一個節點失敗：檢查訂閱是否已更新、節點驗證資訊是否失效，以及目前核心是否支援該通訊協定。更新訂閱後，再重新選擇一次實際節點。
3. 換個測試網址就成功：問題較可能出在原測試目標、憑證、名稱解析或連線路徑。比較時請讓所有節點使用相同的新網址，避免測試條件不一致。
4. 等待上限太短：若介面允許調整，可暫時將 3000 毫秒改為 5000 毫秒再試。延長等待時間有助於辨識緩慢回應，但無法排除壅塞或加快線路速度。
5. 測速成功但網頁無法使用：立即改查目標網站、規則命中結果與應用程式的連線路徑，別再反覆按同一個測速按鈕。

更貼近實際體驗的節點比較方式

準備兩到三個候選節點即可。暫停系統更新與大型檔案同步，盡量維持相同的網路連線方式；若使用 Wi-Fi，測試期間不要更換位置。記下客戶端、核心、測試 URL 與時段，才能確認前後比較是否有效。

1. 固定代理路徑：暫時在手動選擇組中指定一個節點，確認目標應用程式的連線確實經過該節點，避免自動切換造成干擾。
2. 重複進行輕量測試：使用同一個網址測 5 至 10 次，每次間隔幾秒，記錄中位數、最高值與失敗次數，不要只看最低值。
3. 開啟實際使用的網站：瀏覽平常使用的兩三個服務，觀察首次開啟與重新整理是否穩定。瀏覽器開發者工具的「網路」面板可協助查看請求耗時，但數值也包含快取與伺服器處理時間。
4. 另外測試持續傳輸：選擇允許下載的固定檔案來源，持續觀察 30 至 60 秒。留意流量使用量，維持相同的並行連線數，並註明記錄單位是 MB/s 還是 Mbps。
5. 在實際使用時段再次測試：平日白天與晚間的壅塞情況可能不同，保留兩個時段的紀錄，比只看單次排名可靠。

以下是用來說明判斷方式的假設紀錄，並非本站實測。兩條線路都成功完成 10 次輕量請求，但適合的選擇可能因使用情境而異：

聊天、遠端互動與網頁操作通常更重視回應速度和穩定性；下載則更看重持續傳輸量；影片播放還會受到位元率、自適應緩衝與 CDN 分配影響。也要留意單位：理論上 8 Mbps 約等於 1 MB/s，實際有效速度還需扣除通訊協定的額外負擔。

舊版 Clash for Windows 的使用限制

Clash for Windows 已停止維護。若仍保留舊環境，可透過 General、Proxies、Connections、Logs 這幾個頁面檢查執行狀態、規則命中與錯誤資訊，但不要預設舊版核心支援新訂閱中的所有通訊協定或 mihomo 欄位。介面能匯入訂閱，不代表每個節點都能正常運作。

新安裝可先在客戶端比較中確認 Clash Verge Rev、FlClash 等仍在維護的專案目前狀態、支援平台與核心支援情況。更換客戶端後，請重新確認系統代理、監聽連接埠與測試網址，不要直接拿舊客戶端留下的歷史數值比較。

建議判斷順序：先確認連線使用正確節點，再核對測試條件，接著觀察多次請求的穩定程度，最後以實際工作負載驗證頻寬與使用體驗。url-test 適合篩選可用出口；它提供的是單一測量結果，不是整條線路的綜合評分。