Clash 節點延遲測試原理：為什麼延遲毫秒數不等於實際網速

節點清單上的毫秒數，測量的是單次請求

Clash 用戶端中的「測速」，通常是指讓核心透過指定節點連線至測試網址，記錄這次探測所花的時間，再以毫秒顯示結果。這比較接近小型 HTTP 請求的回應時間測試，而非持續下載大型檔案的頻寬測試。節點旁顯示 80 ms，只表示這次探測很快完成，不能換算成每秒可下載多少 MB。

用戶端負責按鈕、清單與結果顯示，實際連線則由 Clash 或 Clash Meta（目前通常稱為 mihomo）核心處理。不同用戶端及核心版本的測試方式、計時範圍與結果快取可能不同，因此兩個介面顯示的數字不一定能直接比較。先確認測試網址與測試方式一致，再比較哪個節點較快，才有意義。

一次典型探測會經過哪些步驟

1. 使用者點選節點的延遲測試按鈕，或由策略群組依排程觸發檢查，核心便會收到測試任務。
2. 核心透過指定的代理節點建立對外連線；節點伺服器的網域名稱可能需要先解析，代理協定也可能需要進行交握。
3. 流量經由代理伺服器連線至測試網站；若使用 HTTPS，還需要與目標網站進行 TLS 交涉。
4. 核心依實作方式判斷回應是否有效，並將耗時或失敗狀態回傳給用戶端。

上述步驟不一定每次都會重新執行：DNS 快取、連線重複使用及協定工作階段重複使用，都可能縮短後續探測時間。有些實作也會發出多次請求。因此，介面上的「延遲」不應嚴格解讀為單一網路封包往返一次的時間，也不等同於系統 ping 指令的結果。

測試網址、逾時設定與自動選擇如何影響結果

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

常見的測試網址會回傳少量內容或 HTTP 204 狀態，例如 https://www.gstatic.com/generate_204。回應內容很小，可減少下載資料本身對耗時的影響。但這個網址的測試結果，只能代表節點連線至該服務所在網路的狀況，不代表連線至所有網站都一樣快。

節點出口連往測試服務的路徑可能品質良好，但連往影音網站或工作平台時，可能會經過另一組路由。CDN 也可能依出口位置、DNS 解析結果及負載，分配不同的邊緣節點。將測試網址從 HTTPS 改為 HTTP，也會改變連線所需步驟；這兩種結果不宜混在一起，直接挑選數值最小的結果。

逾時表示測試未能及時完成，不代表節點永久失效

假設單次測試的逾時設定為 5000 ms，核心若未能在限定時間內完成有效探測，就可能回報失敗。原因可能是代理連線失敗、目標網站無法連線、TLS 錯誤或當時網路壅塞，不一定是「節點離線」。反過來說，把逾時改成 10000 ms 只是延長等待時間，不會讓線路本身變快。

介面顯示的 Timeout、Error、空白或 0 ms，可能是不同用戶端表示測試失敗或尚未測試的方式。遇到這些狀態時，應查看連線記錄中的具體錯誤，不要一概解讀為封包遺失。

url-test 會選擇低延遲節點，不會測試最大頻寬

以下是 mihomo 風格的策略群組範例。香港 01 與 日本 01 必須是目前設定中已定義的節點名稱；這只是設定片段，不是可直接匯入的完整訂閱內容。

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

• interval: 300：檢查間隔以秒為單位，此處為 5 分鐘；並非每次開啟網頁時都會測試一次。
• tolerance: 50：切換容差以毫秒為單位，用來減少因細微差異造成的反覆切換，並非頻寬門檻。
• lazy: true：群組未使用時可略過定期檢查，因此清單中的結果可能不是剛測得的。

手動點選「全部測速」、策略群組自動檢查，以及代理集合的健康檢查，可能各自使用不同的測試入口與參數。只修改某個策略群組的 url，不保證用戶端手動測試也會改用該網址。欄位是否相容，請以目前使用的核心為準；相關概念可參考協定與設定參考。

為什麼低延遲節點仍會下載慢、影片卡頓

小型回應對傳輸量的需求很低。即使線路只能提供 5 Mbps 的持續頻寬，幾十到幾百位元組的回應仍可能很快傳回。換成高位元率影片或大型安裝檔時，頻寬限制才會明顯浮現。節點延遲低、下載速度慢，兩者並不矛盾。

封包遺失會讓問題更不容易察覺。單次探測若剛好成功，顯示的數值可能很好看；但在連續傳輸時，TCP 重傳與壅塞控制會降低有效速度。使用 QUIC 的服務還涉及 UDP 路徑，而單次以 TCP 進行的 HTTPS 探測，無法證明節點支援 UDP，也無法反映 UDP 品質。

可重複執行的節點測試流程

第一步：確認業務流量確實經過受測節點

先在用戶端選取要測試的節點，再前往「連線」或「Connections」頁面查看目標網域的記錄，確認命中的規則與代理鏈。頁面名稱會因用戶端而異，但檢查重點相同：實際連線最後使用了哪個出口。測試期間不要同時使用自動切換群組，否則大型檔案下載與下一次網頁請求可能已改走不同節點。

系統代理只會影響遵循該設定的應用程式。命令列、遊戲及部分下載工具未必會使用系統代理；TUN 模式可擴大接管範圍，但仍須確認路由、排除項目與實際連線記錄。啟用 TUN 本身不會加速，也無法讓低頻寬線路變成高頻寬線路。

第二步：固定測試條件，連續測試而非只看一次

1. 關閉其他高流量工作，並維持相同網路、測試網址與逾時設定。
2. 每個節點測試 10 次，間隔約 5 秒，記錄成功耗時與失敗次數。
3. 以中位數比較典型等待時間，同時記錄最大值，避免單次偏低的結果掩蓋波動。
4. 在平常使用的時段再測一次，例如晚間 20:00—22:00，觀察繁忙時段的變化。

如果 10 次請求中有 2 次失敗，準確的說法是「本輪應用層探測失敗率為 20%」，不能直接寫成「網路封包遺失率 20%」。一次請求可能包含多個封包，也可能因 DNS、TLS 或目標服務問題而失敗。即使連續 10 次成功，樣本數也不足以證明長時間連線穩定。

第三步：以實際使用情境補充頻寬與穩定度測試

選擇自己有權存取、大小已知的檔案或同一段影片，固定來源後比較不同節點。下載時先觀察約 10 秒的連線建立與速度爬升過程，再觀察 30—60 秒的持續速度；播放影片時則留意緩衝次數、緩衝時間，以及播放器提供的連線速度資訊。這兩種測試都比只看節點清單更貼近日常使用體驗。

單位也要一致：8 Mbps 以十進位換算約為 1 MB/s，80 Mbps 約為 10 MB/s，實際有效速度還會受到協定額外負載影響。如果工具顯示的是 MiB/s，採用的是二進位單位，數值也會略有不同。持續頻寬測試會消耗訂閱流量，使用行動網路時尤其要控制測試次數。

使用 curl 區分連線時間與首位元組時間

想進一步了解時間花在哪個階段，可以讓 curl 明確使用本機 HTTP 代理，並輸出各階段的耗時。以下假設用戶端的 HTTP 或混合監聽連接埠為 7890；這是常見設定，不代表所有用戶端都使用此預設值，執行前請先到用戶端的連接埠設定中確認。

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

這段指令適用於 macOS、Linux 等常見 shell。Windows PowerShell 可呼叫 curl.exe，將指令合併為一行，並把 --output /dev/null 改成 --output NUL。明確指定代理後，就不必猜測命令列是否使用了系統代理；但仍須先確認用戶端目前選用的出口。

• time_connect：在此本機 HTTP 代理情境中，主要反映連線至 127.0.0.1:7890 所需的時間，不能視為連線至遠端節點的延遲。
• time_appconnect：HTTPS 的 TLS 交握完成時間；透過 HTTP 代理時，此前還包含建立代理通道等步驟。
• time_starttransfer：收到回應第一個位元組的累計時間，包含先前的連線過程與等待目標服務回應的時間。
• time_total：本次請求的總耗時。由於測試頁面幾乎沒有回應內容，因此無法反映大型檔案的傳輸速度。

這些時間都是從請求開始計算的累計值，不應直接相加。由於測試實作與連線重複使用方式可能不同，結果也不保證與用戶端核心的測速數值一致。這段指令較適合用於比對與排查：以相同節點、目標和參數重複執行，觀察變慢主要發生在連線階段，還是在收到第一個位元組之前。

常見問題：逾時、封包遺失與自動選擇

選擇節點時，可先用延遲進行第一輪篩選，再以持續傳輸速度、失敗頻率和目標應用程式的表現確認。發現異常後，每次只變更一項條件：先固定出口，再固定測試目標，最後比較網路或時段。這樣得出的結論比不斷點選「全部測速」更容易重現，也更有助於找出問題。