Clash 延遲測試原理

延遲數字反映的是單次請求

Clash 用戶端中常見的「測速」按鈕，通常測量的是透過代理存取指定 URL 所需的時間，而不是下載大型檔案來計算頻寬。介面顯示的 80 ms、160 ms，是這條測試路徑所花的時間；不能直接換算成每秒可下載多少 MB，也不代表所有網站的回應時間。

用戶端可能提供 TCP 連線測試、HTTP 延遲測試，或獨立的下載測速功能。本文討論設定中的 url-test，以及以 HTTP 請求進行的節點延遲測試。不同用戶端與核心版本的計時範圍、連線重用方式可能不同，比較前應先確認測試類型一致。

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

以常見的 HTTPS 測試網址 https://www.gstatic.com/generate_204 為例，核心會透過受測代理發出 HTTP 請求。這個網址通常會回傳 HTTP 204，不需持續下載回應本文，適合用來快速檢查連線可用性與回應時間。它不是頻寬測試檔案，也不保證在所有網路環境下都能使用。

1. 準備連線目標。用戶端需要取得代理伺服器位址；若伺服器使用網域名稱，建立連線前可能需要進行 DNS 解析。測試目標的網域由本地或遠端解析，則取決於代理協定與核心的 DNS 設定。
2. 連線至代理入口。本地網路與代理伺服器之間需要建立傳輸連線。TCP 類型的協定可能需要 TCP 握手，部分協定還需要 TLS 握手或驗證；其他傳輸方式則不能一概套用相同流程。
3. 建立通往目標的連線。代理出口會繼續連線至測試網站。代理入口距離近，不代表出口到目標網站也近；跨區繞路或出口壅塞仍會增加等待時間。
4. 送出請求並等待回應。測試會在核心定義的計時範圍內完成，接著將耗時交由用戶端顯示。憑證驗證失敗、連線遭重設或等待超過限制，都可能顯示為失敗，而不是有效的毫秒數。

因此，HTTP 延遲不只是「本機到伺服器的 ping」，也不能解讀為所有握手時間的固定總和。DNS 快取、TLS 工作階段恢復、底層連線重用與核心實作都會影響結果。第一次測得 230 ms，接著降到 120 ms，並不足以證明線路剛提升了頻寬。

為什麼 ping 數字比較低

命令列的 ping 通常會傳送 ICMP 回應請求，測量到指定主機的往返時間。它並未完成上述 HTTP 請求，通常也不會透過系統 HTTP 代理。伺服器也可能限制 ICMP，卻仍正常提供代理服務。因此，ping 不通不能直接判定節點無法使用；ping 延遲低，也不保證 HTTPS 頁面載入得快。

測試網址決定比較的對象

節點測試連線的是測試網址，瀏覽器實際造訪的則可能是影音網站、程式碼儲存庫或會議伺服器。這些目標的 CDN 分布、來源站位置與電信業者互連狀況各不相同。某條線路連到測試站只要 60 ms，存取工作所需的網站卻可能繞遠路；另一條線路測得 110 ms，實際服務路徑反而可能更理想。

• 比較不同節點時，請使用相同網址。若節點 A 和節點 B 使用不同網站作為測試目標，測出的數字就無法公平比較。
• 網址異常應另外排查。測試網域解析失敗、憑證時間驗證失敗或伺服器限流，都可能造成多個節點同時逾時。此時應先換成穩定、回應內容較小的 HTTPS 網址重新測試。
• 狀態碼須配合設定判讀。部分核心或用戶端允許設定預期的回應狀態。收到重新導向、驗證頁面或非預期狀態時，「有收到回應」不一定代表「測試成功」。
• 不可省略實際服務測試。選定候選節點後，還要開啟實際要使用的網站，檢查登入、圖片、影片片段與長連線，不要只看用戶端的節點清單。

延遲低，為什麼下載還是慢

輕量請求主要反映建立連線與等待回應的成本；持續下載則更仰賴可用頻寬、壅塞控制、鏈路封包遺失與伺服器供應能力。小型回應可以很快送達，但同一條線路連續傳輸 500 MB 時，可能很快就遇到出口限速。

用範例區分延遲與吞吐量

假設節點 A 的 HTTP 延遲為 65 ms，持續下載速度為 2 MB/s；節點 B 的 HTTP 延遲為 140 ms，持續下載速度為 15 MB/s。這組數字僅用來說明指標差異，並非實際線路排名。對於短小的網頁請求，A 可能更快開始回應；下載大型檔案或播放高位元率影片時，B 則較可能提供足夠的吞吐量。若網站本身有限速，兩個節點也可能都受來源站限制。

「延遲低就一定快」忽略了傳輸量；「下載快就一定適合開會」則忽略穩定度、上傳能力與即時服務的網路路徑。應先確認用途再挑選指標，不要把所有表現混成一張排行榜。

抖動與封包遺失如何影響體驗

單次最低延遲容易掩蓋波動。例如連續五次結果是 78、82、80、460、85 ms，中間的 460 ms 就值得留意。可能原因包括無線網路互相競爭、排隊、重傳或測試站短暫變慢；只憑這五次 HTTP 請求，無法斷定底層網路的封包遺失率。

對需要可靠傳輸的連線而言，資料遺失可能觸發重傳並影響壅塞視窗，導致長時間下載明顯變慢。即時影音則可能出現聲音斷續、畫面停格或緩衝增加。各種應用程式處理恢復與緩衝的方式不同，因此同一個節點可能適合播放有緩衝的影片，卻不適合即時會議。

• 連續測試 5 到 10 次，觀察中位數、最大值與失敗次數，不要只記最低值。
• 若 10 次 HTTP 測試中有 2 次失敗，應記錄為「本輪請求失敗 2/10」，不要寫成「鏈路封包遺失率 20%」。
• 分別在網路閒置時與晚間常用時段測試；若只有晚間變慢，再比較本地寬頻與代理出口的負載。
• 測試時請暫停雲端硬碟同步、大型檔案下載與其他測速工作，避免自己的流量造成排隊。

url-test 自動選擇節點，不代表優先選頻寬

在 Clash 與 Clash Meta（現多稱為 mihomo）的設定中，url-test 代理群組會依照指定 URL 的延遲測試結果選擇成員。名稱裡有「測速」，不代表它會自動下載大型檔案來比較頻寬。若要手動固定某條線路，請使用手動選擇群組；若使用自動測試群組，就要了解它主要是根據延遲做決策。

以下是代理群組設定片段範例，假設目前設定中已經有名為「香港 A」和「日本 B」的代理。實際使用時，應將成員名稱改成現有設定中的正確名稱，並合併至既有的 proxy-groups 清單，不要用這段取代整份設定檔。

proxy-groups:
  - name: 延遲優選
    type: url-test
    proxies:
      - 香港 A
      - 日本 B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

• interval: 300 表示設定的測試間隔為 300 秒。實際排程還可能受核心的延遲測試等機制影響，不應將它視為任何時候都會精確執行的計時器。
• tolerance: 50 的單位是毫秒，可為自動選擇設定切換容差，減少因幾毫秒差異而頻繁切換的情況。實際行為依使用的核心版本而定。
• 設定代理群組還不夠；流量規則必須引用該群組，或在上層手動選擇群組中選取它，實際連線才會採用它的選擇結果。

自動群組重新選定成員，通常不表示所有已建立的連線都會立即切換。舊連線可能繼續使用原本的出口，新連線才會改走新選定的節點。排查時，請在用戶端的「連線」頁面查看目標網域、規則命中結果與代理鏈，不要只看群組名稱旁目前顯示的節點。

在相同條件下驗證實際速度

多數用戶端可在「代理」頁面選取節點並進行延遲測試，再到「連線」或「日誌」頁面確認請求路徑；這些是常見的功能名稱，但不同用戶端的選單不一定完全相同。系統代理模式與 TUN 模式接管流量的範圍也不同，測試時應維持相同模式。

1. 先固定網路條件。使用同一台裝置、同一條寬頻與相同的 Wi-Fi 頻段；如果條件允許，也可改用網路線重測。不要直接比較手機行動網路與電腦 Wi-Fi 的結果。
2. 確認實際流量確實經過代理。在「連線」頁面尋找測試網站，確認出口不是 DIRECT，並核對實際使用的節點。核心內建的延遲探測通常會指定受測代理；探測成功不代表瀏覽器流量已正確導向代理。
3. 記錄輕量請求結果。使用相同 URL 連續測試 5 到 10 次，記錄一般耗時、明顯高峰與失敗次數。不要同時密集測試大量節點。
4. 接著測持續吞吐量。選擇頻寬充足的固定來源，單獨下載約 30 秒，觀察速度穩定後的表現。比較時應使用相同檔案、來源與並行連線數，並留意方案的流量用量。
5. 最後測試實際用途。觀看影片時觀察緩衝與播放穩定度；開會時檢查上傳能力與聲音是否連續；使用程式碼儲存庫時，則分別測試頁面載入與檔案下載。每次驗證只調整一個變數。

選擇節點時，先用延遲測試排除目前無法連線或明顯異常的選項，再觀察波動、持續吞吐量與實際應用表現。瀏覽網頁時，回應時間很重要；下載大型檔案時，頻寬更關鍵；即時通訊則同樣重視穩定度與上傳能力。將這些指標分開記錄，才能解釋為何用戶端顯示的數字很漂亮，實際體驗卻沒有同步改善。