Clash 節點延遲測試原理：為何測速數值和實際網速不同

延遲測量的是單次請求，不是下載頻寬

Clash 用戶端節點清單中的「測速」，通常是透過指定代理連線至測試 URL，並顯示核心回報的耗時。結果以毫秒（ms）表示。這不是持續下載測試，也不是對代理伺服器發送一次 ICMP Ping。即使用戶端介面標示「延遲」，實際測量內容仍須視核心與測試設定而定。

這能解釋一種常見情況：某個節點顯示 80 ms，但下載檔案只有 500 KB/s；另一個節點顯示 180 ms，卻能穩定下載至 10 MB/s。前者完成小型請求較快，後者則有較高的持續傳輸能力。這兩項指標反映不同環節，彼此沒有必然的高低關係。

單位也容易讓人誤解。網路頻寬常用 Mbps，下載工具則常用 MB/s；以十進位換算，100 Mbps 的理論上限約為 12.5 MB/s，實際傳輸還須扣除通訊協定開銷。延遲的 100 ms 與頻寬的 100 Mbps 之間沒有換算關係。

URL Test 的連線與握手流程

以 HTTPS 測試網址為例，連線過程可拆成幾個環節。這些步驟有助於理解故障可能發生的位置，但不代表所有核心版本都會分別計時或顯示，也不能將介面上的數值視為各階段固定相加的精確結果。

1. 取得節點伺服器位址。如果代理伺服器使用網域名稱，建立連線前須先取得對應位址。結果可能來自快取，也可能需要重新查詢。
2. 連線至代理伺服器。用戶端會依節點協定建立傳輸連線。TCP、以 UDP 為基礎的傳輸方式，以及不同加密協定的準備流程各不相同。
3. 建立通往測試目標的通道。代理出口必須能連線至目標網站。目標網域由哪一端解析，則取決於協定與相關設定。
4. 完成目標網站的 HTTPS 交握。通常會進行目標網站的 TLS 交握與 HTTP 請求，並在符合核心定義的回應條件後停止計時。

實際計時範圍、連線重用、重試策略與 HTTP 請求方法可能因核心版本而異。不要直接將某個用戶端顯示的「連線延遲」，視為另一個用戶端以相同公式測得的結果。若要橫向比較，請統一用戶端、核心、測試 URL 與網路環境。

為什麼系統 Ping 很低，Clash 延遲仍然很高？

對節點伺服器執行 Ping，只會測量本機到該伺服器的 ICMP 往返時間。URL Test 還會受到代理協定處理、出口至目標網站的路徑，以及目標回應速度影響。伺服器也可能限制 ICMP，造成 Ping 封包遺失，但代理請求仍可正常運作。兩種測試應分開記錄，不能互相取代。

測試網址決定測量哪一段網路

常見測試 URL 會使用回傳 HTTP 204 的小型回應端點，例如 https://www.gstatic.com/generate_204。204 代表沒有回應本文，傳輸負擔很小，適合頻繁檢查連線狀態；但也表示它幾乎無法反映大型檔案的傳輸能力。

同一個出口連線至不同網域，可能會使用不同 CDN 或不同地區的節點。某個節點通往測試端點的路徑較短，不代表連線至影音平台、程式碼儲存庫或辦公服務時也一樣。更換測試目標後，節點排名有所變化是正常現象。

選擇測試 URL 的三個條件

• 回應小且穩定。優先選用明確供連線檢查使用的端點，避免使用含首頁圖片、登入重新導向或經常變動內容的網址。
• 使用相同協定。比較節點時，固定使用同一個 HTTPS URL。HTTP 與 HTTPS 的連線流程不同，不應混在同一組排名中比較。
• 另外驗證實際服務。先用統一端點篩選節點，再透過實際應用程式驗證。不要頻繁請求含登入憑證或敏感查詢參數的連結。

還要區分三種測試入口：節點旁的手動測速、url-test 策略群組的自動測試，以及 proxy-providers 的健康檢查。這些功能可能各自設定 URL、間隔與逾時時間。只修改其中一處，其他介面的測試條件不一定會同步變更。

mihomo 的 url-test 設定與自動選擇節點

url-test 策略群組會根據測試結果自動選擇成員。以下為群組層級的設定範例，其中「香港-01」和「日本-01」是範例中已存在的節點名稱。套用至實際設定時，成員名稱必須與自己的 proxies 定義一致，否則無法正確引用。

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

• interval: 300：自動檢查間隔為 300 秒，不是 300 毫秒。
• tolerance: 50：以毫秒為單位設定切換容差，減少因延遲些微差異而頻繁更換節點；這不是逾時時間。
• lazy: true：未使用該群組時，可略過定期測試以減少背景請求。因此，長時間未使用的群組不一定會保有最新的延遲數值。

設定項目應以目前核心支援的範圍為準。經典版 Clash 與 mihomo 並非所有欄位都相同。用戶端也可能透過設定覆寫或訂閱轉換修改最終內容；檢查時應查看實際運行的設定，而不只看訂閱原文。設定與安裝步驟請參閱全平台指南。

低延遲但下載速度慢的常見原因

出口限速與共用線路壅塞

傳輸少量資料的小型 HTTP 回應，即使線路限速為 5 Mbps，也可能很快完成。下載 1 GB 檔案則需要持續使用頻寬，出口限速、共用線路壅塞與伺服器限速都會顯現出來。晚間尖峰時段若出現「延遲變化不大，下載速度卻明顯變慢」，應優先比較持續傳輸量，而不是反覆點擊延遲測試。

封包遺失與重傳會影響長時間連線

偶發的封包遺失可能剛好沒有影響一次短時間測試，卻會在長時間傳輸中觸發重傳與壅塞控制。常見表現包括速度劇烈起伏，以及起初正常、之後逐漸下降。應搭配多次請求的成功率與下載過程判斷，單次最低延遲並不能代表穩定性。

實際流量並未經過受測節點

手動測試某個節點，不代表瀏覽器已選用該節點。規則可能將目標網域交由其他策略群組處理，甚至使用 DIRECT 直連。系統代理只會影響遵循該設定的應用程式；TUN 模式的涵蓋範圍則取決於路由、排除項目與用戶端設定。請在用戶端連線清單中確認目標網域、命中規則、策略群組與最後使用的節點。

下載來源與本機環境也可能成為瓶頸

遠端網站可能依連線、帳戶或地區限制速度；本機 Wi-Fi 干擾、背景同步與磁碟寫入也會影響測試結果。使用兩個不同來源重複測試，通常比在同一項下載任務中不斷切換節點更有助於找出問題。

timeout 的意義與排查順序

timeout 表示測試未能在規定時間內完成，不代表已確認訂閱失效。DNS 解析失敗、伺服器無法連線、協定參數錯誤、目標網站限制存取，以及目前網路速度過慢，都可能導致測試失敗。部分用戶端會將多種錯誤統一顯示為逾時，應查看記錄檔確認實際原因。

1. 固定網路環境。暫停大量下載，在同一個 Wi-Fi 或有線網路下重新測試，並記錄失敗時間。
2. 確認是單一節點還是全部節點失敗。只有一個節點失敗時，優先檢查節點資訊；所有節點同時失敗時，先檢查本機網路、DNS 與公用測試目標。
3. 更換一次測試網址。改用另一個穩定的小型回應端點。如果只有原本的網址測試失敗，不能據此判定整個節點無法使用。
4. 查看記錄檔中的錯誤類型。解析錯誤、連線遭拒、TLS 錯誤與等待逾時，各自代表不同的處理方向。若是 TLS 異常，也應檢查系統日期與時間。
5. 確認逾時設定的位置。手動測試入口、策略群組與提供者健康檢查可能採用不同的期限。調高其中一處的數值，不代表其他入口也會跟著變更。

例如，測試期限設為 5 秒時，耗時 6 秒才完成的請求會判定失敗。放寬至 10 秒可能讓測試顯示成功，但無法改善線路本身。逾時期限只用來設定等待時間，不是加速參數。若持續出現數秒才完成的回應，應繼續檢查網路路徑，而不是只追求介面顯示成功。

在相同條件下比較，判斷節點品質

以下是一套可重複執行的篩選流程。數字僅用來說明如何記錄，不代表本站對任何節點的實測結果。比較時請固定裝置、測試 URL、下載來源與時段，每次只更換節點。

1. 先測短時間請求。每個節點進行 5 輪 URL Test，每輪間隔約 10 秒，記錄所有數值與失敗次數，不要只保留最佳結果。
2. 接著測試持續傳輸。選擇允許測速的固定下載來源，持續觀察 30～60 秒，分別記錄開始時與進入穩定階段後的速度。也要留意流量用量。
3. 確認實際出口節點。在連線清單中檢查該任務使用的節點。切換策略後重新建立任務；既有連線不一定會立即切換。
4. 重新測試實際應用程式。影音服務觀察啟動、拖曳進度與緩衝情況；網頁觀察首次載入與連續瀏覽；遠端工作階段則觀察輸入回應與斷線狀況。
5. 不同時段交叉測試。至少比較一個白天與一個晚間時段，避免將某一分鐘的結果當成長期品質。

在這組範例中，節點 A 的短時間請求較快，節點 B 則更適合傳輸大型檔案。如果 5 輪中有 2 輪逾時，應另外註明「成功 3/5」，不要只把剩下 3 次的平均值當成完整結果。互動式應用重視較低且穩定的延遲；大型檔案與高位元率影音則同樣仰賴持續傳輸量與成功率。

最後仍應依實際用途選擇：先用 URL Test 排除明顯無法連線的節點，再透過實際應用確認路徑與表現。延遲只是篩選依據之一，不是網速評分，也不能證明所有網站都能正常使用。