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

1. 節點延遲的毫秒數，不等於下載速度

Clash 客戶端中的「測速」，多半是指由核心發起的 URL 延遲測試，而非下載大型檔案來測量頻寬。介面顯示的 120 ms 是一次小型請求的耗時指標，不能換算成每秒可下載多少資料。它主要反映建立連線與等待請求回應所需的時間，並未測量持續傳輸能力。

簡單稱為「握手耗時」有助於理解，但從技術角度來看仍不夠完整：實際計時範圍會受到核心實作、代理協定、是否重用連線，以及 HTTP 或 HTTPS 測試網址等因素影響。這個數值既不是純粹的 TCP 握手時間，也不是系統 ping 指令測得的 ICMP 往返時間。

例如，節點 A 的延遲是 80 ms，下載速度只有 2 MB/s；節點 B 的延遲是 160 ms，下載速度則可達 15 MB/s。這組數字僅供說明，並非本站實測結果。A 可能較快完成短請求，B 卻更適合傳輸大型檔案。兩者並不矛盾，因為頻寬、網路壅塞與單一連線的限制，都不是一次小型請求能反映的。

2. url-test 請求會經過哪些步驟

url-test 是其中一種策略群組類型。核心會透過群組內的候選節點存取指定 URL，取得測試結果後，再依可用性、延遲與容差等條件選擇節點。圖形介面的「全部測速」也可能呼叫核心的延遲測試介面，但使用的 URL、逾時時間或觸發方式，不一定與策略群組相同。

一次典型的 HTTPS 探測

1. 確認測試目標：讀取測試 URL，例如 https://www.gstatic.com/generate_204。這個路徑通常會回傳 HTTP 204，不含需要下載的本文。
2. 建立代理通道：裝置連線至候選節點，並完成該代理協定所需的連線程序。解析節點位址、傳輸層連線與協定握手都可能需要時間。
3. 連線至測試網站：透過代理出口連線至目標；若使用 HTTPS，還會進行目標網站的 TLS 協商。目標網域由哪一端解析，取決於協定與實際設定，不能一概認定是由本機解析。
4. 取得回應並記錄：核心會依實作方式記錄請求耗時，並回傳結果或錯誤。不同客戶端可能將失敗顯示為「逾時」、紅色標記或無法使用。

節點探測通常會測試指定的代理出口，不代表將測試 URL 當成瀏覽器連線，完整重現日常分流流程。實際應用程式的流量可能依規則走直連、另一個策略群組或其他節點。因此，遇到「測試很快、網頁很慢」時，第一步應查看連線面板，確認網頁實際使用哪個出口，而不是馬上更換測試網址。

3. 如何設定測試 URL、逾時與測試間隔

以下是適用於支援這些欄位的 mihomo 核心之設定片段。mihomo 是 Clash Meta 後續採用的專案名稱；舊版 Clash 或部分客戶端的圖形設定不一定支援所有欄位。請先確認客戶端顯示的核心類型，再參照相應的核心文件；不要將這段設定當成完整訂閱檔直接覆蓋。

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

這裡的 香港-01、日本-01 必須與現有 proxies 中的名稱完全一致。使用代理集合時，也可以依核心支援的方式透過 use 引用集合；不要只貼上這段設定到尚未定義節點的檔案中，並期待它能連上網路。

• url：優先選擇回應內容少、路徑穩定，且能代表日常存取方向的網址。HTTP 與 HTTPS 的握手流程不同，切換協定後不宜直接沿用舊數值排名。
• interval: 300：自動檢查間隔為 300 秒，也就是 5 分鐘。這不是連線逾時時間，也不是每 300 毫秒測試一次。
• timeout: 5000：單次測試的逾時上限為 5000 毫秒。上限設得太短，可能會把暫時壅塞誤判為無法使用；調長也無法修復失效節點。
• tolerance: 50：切換容差為 50 毫秒，用來減少延遲小幅變動造成的頻繁切換。它不是頻寬門檻，也不會將顯示的延遲減去 50。
• lazy: true：啟用延遲檢查，群組未使用時可能會略過定期測試。不要因此認為每個節點都會嚴格按照實際時間每 5 分鐘更新。

不要只為了測出更低的數值而更換網址

測試網站所在區域、CDN 調度方式與出口互連都會影響結果。若改用距離出口很近的網址，數值可能降低，但常用網站的連線路徑未必有所改善。比較節點時，應維持 URL、網路環境與測試方式一致；排查特定網站時，再額外加入該網站的小型可存取資源作為參考。

也不建議將數百個節點的測試間隔一律縮短至 10 秒。頻繁探測會增加連線數、流量與裝置負擔，也可能觸發遠端限流。日常可先以 300 秒觀察；發生故障時手動重測幾次，比持續高頻重新整理更容易找出問題。

4. 延遲很低，但網頁或影片仍然很慢的原因

小型請求成功，不代表尖峰時段頻寬充足

204 請求只需傳輸少量資料。即使出口頻寬已經壅塞，請求仍可能很快完成；影片分段資料和大型檔案卻需要持續占用連線。伺服器限速、共用出口負載、跨網互連，以及本機 Wi-Fi 封包遺失，都可能降低實際傳輸速度。

實際網站與測試網站的後半段路徑不同

從裝置到代理節點的路徑只是前半段。節點連往測試網站與影片網站時，可能經過完全不同的線路。某個測試網址速度快，不能推論另一家 CDN 也很快；目標網站的區域策略、負載或對出口 IP 的限制，也可能直接影響連線是否可用。

瀏覽器並未使用測試時的節點

• 在規則模式下，網域可能符合 DIRECT，或被導向另一個策略群組。請開啟連線紀錄，核對目標網域、符合的規則與最後使用的代理鏈。
• 系統代理通常只會影響遵循該設定的應用程式。遊戲、使用自有網路堆疊的應用程式，以及部分命令列程式可能不會使用系統代理。
• TUN 會透過虛擬網卡接管相應流量，但接管範圍仍會受到路由、排除項目與 DNS 設定影響。啟用 TUN 並不會自動提升節點頻寬。
• 瀏覽器重用的長連線未必會在切換策略後立即重新建立。測試切換效果時，可以重新開啟目標應用程式；必要時只關閉相關連線，並留意不要中斷正在進行的下載。

另一個常見誤解是單位比較：8 Mbps 理論上約等於 1 MB/s，實際速度還需扣除協定負載。當電信業者標示的頻寬、測速網站顯示的單位與下載工具使用的單位不一致時，請先換算單位，再判斷速度是否異常。

5. 依延遲、頻寬與穩定性三步挑選節點

挑選節點時，先排除無法使用的節點，再觀察穩定性，最後依用途比較傳輸速度。不要只看清單排序；也不要在自動切換的同時比較固定節點的速度，否則測試對象可能早已改變。

1. 固定測試條件：使用同一台裝置與同一個網路進行測試，並暫停背景下載。暫時透過手動選擇群組鎖定候選節點，確認實際應用程式的連線也經過該節點。
2. 觀察多次延遲：以約 10 秒為間隔手動測試 5 次，記錄結果與失敗次數。這是短時間排查方式，不建議長期將自動探測設為每 10 秒一次。
3. 測試持續傳輸：使用同一個可信任的下載來源測試 30～60 秒，記錄速度穩定後的數值，而非只看第一秒的峰值。測速會消耗流量，使用計量網路前請先確認可用額度。
4. 確認實際用途：觀看影片時觀察緩衝與拖曳後恢復速度；使用遠端終端機時觀察輸入回應；開會時留意斷線與音訊是否連續。URL 測試無法取代 UDP 服務測試。

表格中的數據僅示範紀錄方法，並非任何服務供應商的實測結果。A 的延遲中位數為 83 ms，B 為 153 ms；C 在 5 次測試中失敗 1 次，樣本失敗率為 20%。樣本數很少，無法據此推估長期故障率，但已足以提醒我們需要繼續觀察，而不是因為 C 最低的一次只有 70 ms 就優先選用。

6. 逾時、結果不一致與自動切換的排查順序

所有節點都逾時

先確認本機基本網路正常、訂閱中的節點仍在有效期限內，且系統日期與時間正確。接著查看核心記錄：timeout 表示未能在時限內完成；connection refused 通常表示連線遭拒；若是憑證相關錯誤，則需進一步檢查時間、目標憑證與網路是否受到干擾。不要把所有失敗都歸因於「節點太慢」。

再換用另一個已知可連線的小型測試網址進行比對。若只有原本的測試 URL 失敗，應檢查目標服務或出口至該目標的路徑；若多個網址都失敗，再檢查節點參數、本機網路與防火牆。不要為了消除憑證錯誤而直接關閉憑證驗證，否則只會掩蓋真正原因。

介面測速與自動選擇群組的結果不同

核對兩邊使用的 URL、逾時時間與更新時機。介面手動測速、url-test 策略群組，以及 proxy-providers 下的 health-check 是不同的設定入口，不能假設修改其中一處就會同步套用到其他入口。更新訂閱時也可能覆蓋本機編輯內容；若要持續套用設定，應使用客戶端支援的覆寫或合併設定。

最快的節點沒有立即被選中

先確認目前的連線確實使用 url-test 群組，而非手動選擇群組或 fallback 群組。fallback 主要依序選擇可用的候選節點，不是單純追求最低延遲。使用 url-test 時，還需考慮容差、測試更新時機、延遲檢查與既有連線；相差幾毫秒通常不值得頻繁切換。