如何看懂 Clash 節點延遲：URL 測速原理與實際網速差異

1. 面板上的毫秒數，不等於下載速度

Clash 用戶端代理頁面顯示的 120 ms，通常是核心透過指定節點發出一次 URL 探測所得。這個數字表示「這條代理路徑完成這次小型請求需要多久」，而不是「每秒能下載多少資料」。手動測速、訂閱節點健康檢查與 url-test 自動選擇，可能採用不同的測速網址和逾時設定；比較前請先確認測試來源。

延遲的單位是毫秒，傳輸速率常以 Mbps 或 MB/s 表示。假設節點甲測得 80 ms、下載速度為 2 MB/s；節點乙為 160 ms、下載速度為 15 MB/s：甲可能較適合頻繁發出小型請求，乙則可能更適合下載大型檔案。這些數字僅用來說明指標差異，並非實際線路測試結果或效能保證。

2. url-test 請求會經過哪些階段

以透過代理存取 https://www.gstatic.com/generate_204 為例，流程為：用戶端核心 → 代理伺服器或代理鏈 → 測速網站 → 傳回回應。這個網址通常會回傳 HTTP 204，沒有用來測量持續傳輸速率的大型回應內容，因此適合用於輕量的連線探測。

1. 準備測試目標與連線資訊。解析代理伺服器位址，並準備測速目標的網域名稱或位址。DNS 解析是在本機還是遠端進行，取決於協定、DNS 設定和連線路徑。
2. 建立與代理伺服器的連線。依節點協定而定，可能會進行 TCP 連線、TLS、WebSocket，或使用 UDP 傳輸的交握。不同協定的連線成本並不相同。
3. 建立通往測試目標的路徑。代理出口會連線至測速網站。若目標使用 HTTPS，也會進行目標網站的 TLS 交握；這與代理協定本身使用的 TLS 並非同一層。
4. 送出請求並等待回應。目標網站處理請求後，回應會沿代理路徑傳回，核心再記錄這次探測結果。

不要直接把這四個步驟當成所有版本都固定採用的計時公式。原版 Clash、Clash Meta（現稱 mihomo）與不同版本，在請求方法、連線重複使用、重複探測和延遲記錄方式上可能有所差異；DNS 快取也會影響實際耗時。若要釐清特定數值，請記錄用戶端與核心版本，再查閱對應的實作方式。

為什麼首次測試與再次測試的結果不同

第一次存取可能會觸發 DNS 查詢並建立全新連線；後續測試則可能受到快取、工作階段恢復或伺服器負載變化影響。即使每次都建立新連線，也不代表所有狀態都會從頭開始。第一次測得 240 ms，之後為 130 ms，不能只憑這兩個數字就判定節點「突然變快」。

3. 測速網址會影響節點排名

URL 測試測量的是「節點到這個目標」的路徑。測速網站採用的 CDN、區域調度和電信業者互連方式，都可能與實際使用的網站不同。某個節點連到測速網址很快，但存取程式碼儲存庫、影音 CDN 或辦公服務時卻繞遠路，就可能同時出現面板延遲低、網頁卻卡頓的情況。

更換測速網址時，請確認回應狀態是否符合目前核心的健康檢查條件。需要登入、持續重新導向或設有存取驗證的頁面，不適合當作穩定的探測目標。如果設定了 expected-status，狀態碼不符預期也可能被判定為失敗，因此不能把每次失敗都歸咎於線路中斷。

4. 為什麼並行測試、壅塞與封包遺失會放大差異

小型請求無法測出持續傳輸速率

幾乎沒有回應內容的小型請求，很快就會結束，無法觀察長時間下載時的壅塞視窗變化、頻寬限制、持續封包遺失及共用出口負載。晚間尖峰時段，線路可能仍能在約 100 ms 內完成小型請求，卻無法穩定播放高畫質影片。

同時測試所有節點也會互相干擾

批次測試會在短時間內建立多條連線。多個節點可能共用同一個入口、轉送線路，甚至同一個出口。此時，本機 Wi-Fi、路由器處理連線的能力及電信業者上行都可能成為干擾因素。若背景正在上傳大型檔案，排隊也可能大幅增加延遲。

• 先暫停大型檔案上傳、雲端硬碟同步和其他測速工作。
• 從批次測試結果中挑出 2～3 個候選節點，再逐一重新測試。
• 每個候選節點至少測試 5 次，記錄中位數、最高值和失敗次數。
• 在平常使用的時段重新測試。白天的結果不能代表晚間高負載時的狀況。

例如，五次測試結果為 90、92、95、98、800 ms，中位數是 95 ms，但明顯的單次尖峰仍值得留意。如果五次中有兩次失敗，就不能只拿其餘三次的最低值來比較。網頁互動和即時通訊往往更容易受到延遲抖動與封包遺失影響，不只是平均延遲。

5. url-test 自動選擇不代表下載速度最快

url-test 是一種依據探測結果自動選擇出口的代理群組類型。它不會自動下載大型檔案來比較頻寬，也無法判斷目前的用途是看影片、開會還是更新軟體。select 用於手動選擇；fallback 著重依序尋找可用出口。不要把這些策略群組的名稱都當成「網速最佳化」。

檢查現有的 url-test 群組時，可以先查看以下欄位。範例僅說明欄位用途，並非完整訂閱內容，不能直接用來取代整份設定檔；可使用的欄位請以實際核心版本為準。

type: url-test
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
lazy: true

• interval: 300：每 300 秒定期檢查一次，不表示每次瀏覽網頁都會重新測速。
• tolerance: 50：以毫秒為單位設定切換容忍值，減少因細微差異而反覆切換；這不是逾時上限，也不會提高頻寬。
• lazy: true：群組未使用時，可略過定期檢查；活躍狀態的判定方式請以目前核心的實作為準。因此面板顯示的結果不一定是剛測出的數值。

訂閱中的 proxy-providers 也可能有自己的 health-check。代理集合健康檢查與代理群組測試並非一對一對應；用戶端手動測試也可能採用另一組參數。排查時請一併確認探測 URL、結果時間與設定來源，以免把舊結果當成目前狀態。更新訂閱可能會覆蓋本機變更；若要長期調整，請使用用戶端支援的覆寫機制。

6. 以實際請求驗證節點，別只看面板

先將出站模式設為規則模式，在代理頁面固定候選節點，再查看連線記錄，確認目標請求符合哪條規則、進入哪個代理群組，以及最後使用哪個出口。系統代理只會影響遵循系統代理設定的應用程式；終端機工具可能不會讀取系統代理。TUN 模式可接管更多流量，但不會自動提高線路頻寬。

透過混合連接埠進行可重複的測試

以下指令適用於 macOS 終端機，假設用戶端實際使用的混合連接埠是 7890。請先在用戶端設定頁確認連接埠；若不同，請改用實際值。-x 會明確指定本機 HTTP 代理，不依賴終端機是否遵循系統代理；--noproxy "" 則可避免現有的代理略過清單讓目標意外直接連線。

curl --noproxy "" -x http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 \
  -sS -o /dev/null \
  -w 'status=%{http_code}\nconnect=%{time_connect}s\ntls=%{time_appconnect}s\nfirst_byte=%{time_starttransfer}s\ntotal=%{time_total}s\n' \
  https://www.gstatic.com/generate_204

time_connect 在此主要反映與本機代理建立 TCP 連線所需的時間；time_appconnect 是完成相關安全交握時的累計時間；time_starttransfer 是收到第一個位元組時的累計時間。這些時間不是彼此不重疊的獨立區段，也不能直接對應面板顯示的核心探測值。這項測試適合在固定條件下重新檢查請求，不適合用來證明兩種實作理應顯示相同數字。

再測試實際服務與持續傳輸速度

1. 開啟平常使用的網站，連續瀏覽數個頁面，觀察首屏、登入和資源載入是否正常。
2. 從有權存取且允許測試的固定來源下載同一個檔案，保持並行下載數量一致，觀察 30～60 秒的穩定速度。
3. 記錄測試時間、網路環境、節點、失敗次數與穩定速度。換節點後重複測試，請勿同時執行多項下載測試。

注意單位換算：8 Mbps 約等於 1 MB/s；實際應用程式的傳輸速率還會受到通訊協定負載影響。測速網站顯示的 Mbps，不能直接和瀏覽器下載視窗中的 MB/s 比較數值大小。

7. 延遲很低卻無法開啟網站，依序檢查

1. 確認測試結果是否為最新。手動重新測試單一節點，並記錄測速網址與時間。先排除快取結果，以及定期檢查尚未執行的情況。
2. 確認請求是否經過該節點。查看連線頁面的命中規則與最終出口。有些網域可能符合 DIRECT 規則，或被導向另一個代理群組。
3. 確認流量入口。檢查系統代理是否已啟用，以及應用程式是否使用專屬代理；若使用 TUN 模式，請再確認權限、路由及其他 VPN 的影響。
4. 檢查目標與 DNS。探測目標可連線，不代表服務網域也能連線。請查看記錄中的解析失敗、連線逾時和 TLS 錯誤；不要一遇到問題就同時更改所有 DNS 設定。
5. 區分 TCP 與 UDP。HTTPS 小型請求成功，不能證明 UDP 轉送可用。遊戲、語音通話和 QUIC 需要另外確認協定支援與實際路徑。