Clash 延遲測試與實際網速不同？解析 url-test 原理

Clash 延遲數值代表什麼：測的是單次請求，不是下載速度

節點旁的「80 ms」通常是透過該代理發出一次 HTTP 或 HTTPS 探測所得。ms 是毫秒，表示這次探測耗時；MB/s 則是每秒傳輸多少 MB，代表持續傳輸能力。兩者有關，但不能直接換算。看到 80 ms，不代表下載速度能達到 8 MB/s。

Clash 設定中的 url-test 是一種自動選擇代理的策略組。它會讓候選代理連線至指定的測試網址，再依探測結果選擇代理。用戶端介面上的「測速」按鈕也可能呼叫核心的延遲測試功能，但按鈕使用的網址與逾時設定，不一定和設定檔中的自動選擇組相同。

以下提到的 Clash Meta，也適用於後續改名為 mihomo 的版本。各用戶端的介面、核心版本和測試參數可能不同。比較前，請先統一測試網址、網路環境與測試時段。

url-test 的請求會經過哪些環節

它不是系統指令中的 ping

系統中的 ping 通常會傳送 ICMP 回應要求封包。Clash 的 URL 探測則是透過代理連線至網頁網址。代理伺服器可能不回應 ICMP，卻仍能轉送網頁請求；反過來說，伺服器的 ping 延遲很低，也不代表透過代理出口連上目標網站就很快。

一次全新的 HTTPS 探測，可能會經過本機連線至代理入口、代理協定交握、出口連線至測試網站，以及 TLS 交握。TLS 是 HTTPS 用來建立加密連線的協定。DNS 查詢、連線重複使用和協定實作也會影響結果，因此不能把顯示的數值簡單理解為「電腦到節點伺服器的往返延遲」。

1. 連線至代理入口：家用寬頻、Wi-Fi 干擾、電信業者路由和入口壅塞，都會影響這段連線。
2. 建立代理連線：協定、傳輸層，以及能否重複使用既有連線，都會影響連線建立成本。
3. 連線至測試網址：代理出口到測試網站的路由、網站回應速度，以及網域名稱解析結果，都可能影響最終結果。
4. 回傳探測結果：核心會記錄單次請求的耗時。實際計時範圍因實作而異，不宜將數值拆解成固定次數的交握。

為什麼常用回應 204 的網址

HTTP 狀態碼 204 表示請求成功，但沒有回應本文。這類探測傳輸量很小，適合頻繁檢查代理是否可用。缺點也很明確：幾乎不涉及大型檔案傳輸，無法測出線路持續滿載時的傳輸量，更無法反映播放長影片十分鐘後的穩定度。

首次測試和後續測試也可能受到 DNS 快取、連線重複使用及伺服器快取狀態影響。不要只記下單次最低值；連續測幾次，再觀察波動和失敗次數，結果會更貼近實際使用情況。

延遲低卻卡頓：五個常見原因

1. 小型請求很快，持續頻寬卻不足

一條線路可能只花約 60 ms 就完成小型請求，但可用傳輸量只有 2 Mbps。以十進位粗估，下載 3 MB 資料約需 12 秒，還不含額外負擔。另一條線路延遲雖有 160 ms，卻能持續傳輸 50 Mbps，載入大型圖片和播放影片通常反而更順暢。

Mbps 是每秒百萬位元，MB/s 是每秒百萬位元組，兩者相差約 8 倍。例如 40 Mbps 理論上約等於 5 MB/s。比較用戶端、瀏覽器和測速網站的數值時，請先確認單位。

2. 測試網址很快，連往目標網站的路由卻不同

測試網站可能由 CDN 提供服務。CDN 是內容傳遞網路，會將請求導向某個邊緣節點。代理連上這個邊緣節點很快，不代表連到其他地區的影音網站、程式碼儲存庫或遊戲服務也一樣快。

因此，「節點 A 測試 70 ms、節點 B 測試 130 ms」只能表示當時連往該測試網址的結果。若主要用途是下載程式碼，就應實際測試目標儲存庫；若主要用來看影片，則應觀察目標平台的緩衝速度、畫質和掉格情況。

3. 偶發封包遺失與晚間尖峰壅塞

單次探測剛好避開壅塞，就可能得到看起來很漂亮的數字。但長連線遇到封包遺失後，可能需要重傳、降速，甚至重新建立連線。若連測五次的結果是 65、68、72、980 ms 和逾時，問題並非「平均延遲稍高」，而是穩定度不足。

晚上 20:00 的線路負載，也可能和上午 10:00 完全不同。請盡量在實際使用時段進行比較，別用清晨的一次測試結果代替晚間尖峰時段的體驗。

4. 實際流量沒有經過受測節點

規則模式會依規則和策略組決定出口。你測試了「自動選擇」組，但目標網域可能符合另一個組，甚至符合 DIRECT，也就是直接連線。系統代理只會影響遵循系統代理設定的應用程式；TUN 模式則透過虛擬網路介面接管流量，但實際涵蓋範圍仍取決於路由和排除設定。

開啟用戶端的「連線」頁面，找到目標網域，檢查符合的規則、策略鏈和最終節點。這比反覆點擊測速更能解釋「換了節點卻沒改善」的情況。若清單沒有請求紀錄，請再確認應用程式是否透過代理連線，以及連線紀錄的篩選條件。

5. 網頁慢在 DNS、應用程式或裝置

網頁不只會請求一個網域，還可能載入圖片、指令碼和登入 API。網域解析速度慢、擴充功能干擾，或裝置 CPU 使用率過高，都會讓頁面卡頓。一次簡短的 URL 探測無法涵蓋這些問題。如果影片已充分緩衝卻持續掉格，也應檢查硬體解碼和裝置負載，而不是只更換節點。

url-test 設定：網址、間隔與容差各自控制什麼

以下是 mihomo 代理組設定範例，假設設定檔中已定義名為「香港01」和「日本01」的代理。合併至現有 YAML 時，請保留原有節點定義和其他策略組，並確認規則確實使用這個組。YAML 以縮排表示層級，請勿用 Tab 取代空格。

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

tolerance: 50 並非替測試結果加減 50 ms，也不代表延遲保證低於 50 ms。它會影響自動選擇的切換判斷。實際行為還與目前的代理狀態、探測是否成功及核心實作有關，不能只憑兩個靜態數值預測每次切換。

更新訂閱可能會覆蓋直接編輯的代理組。若需要長期調整，建議優先使用用戶端提供的覆寫或合併設定功能，並檢查最終生效的設定。相關功能入口會隨用戶端版本改變，別只確認編輯器中儲存的內容。

用十分鐘整理一組可比較的測試結果

不必一次測完所有節點。先挑選 2 至 3 個地區合適的候選節點，再依相同流程比較。以下數值僅用來說明判斷方式，並非本站實測結果。

1. 固定測試環境：使用同一台裝置和同一個網路，暫停大型檔案同步。先記錄目前使用系統代理還是 TUN，以及實際使用的策略組。
2. 確認出口節點：在「連線」頁面開啟目標請求，確認最終節點。手動選擇節點時，務必操作目標規則實際符合的策略組。
3. 重複探測：使用同一個測試網址，每個節點測 5 次，每次間隔約 5 至 10 秒。記錄中位數、最高值和逾時次數，不要只記最低值。
4. 補測傳輸量：使用相同來源的大型檔案下載 30 至 60 秒，觀察穩定階段的速度。確認檔案不是直接從瀏覽器快取讀取，並留意訂閱流量用量。
5. 驗證實際用途：開啟平常使用的網站，或以相同畫質播放影片 3 分鐘。最後再於常用時段重測一次。

語音通話、遠端操作等互動情境更重視延遲和抖動；影片與大型檔案則更仰賴持續傳輸量；遊戲還得另外測試 UDP 路徑。HTTP 探測成功不代表 UDP 可用，更不能取代遊戲內的延遲測試。

異常數值與自動選擇：依現象逐步排查

顯示 timeout、負值或空白

這些通常代表探測失敗、未取得有效結果，或結果尚未更新，實際顯示方式由用戶端決定。不一定表示節點完全無法使用，也可能是測試網址無法連線、逾時門檻過短，或代理協定設定不相符。先手動開啟實際使用的目標，再查看用戶端記錄中的連線錯誤。分享記錄前，請遮蔽訂閱連結、權杖和節點驗證資訊。

顯示 0 ms，代表速度非常快嗎？

不能這樣判斷。0 可能是數值取整、介面初始值或某次異常結果，應確認用戶端的實作方式。請重新測試，並查看實際請求的出口與耗時。跨區代理若長期固定顯示 0 ms，尤其應確認測試是否真的有執行。

自動選擇總是挑到「延遲最低卻不好用」的節點

url-test 主要依據探測延遲運作，不會自動判斷影片緩衝、頻寬上限、服務地區限制或流量倍率。請先縮小候選範圍，只保留通過實際用途測試的節點，再交由自動選擇。若服務需要固定出口地區，也應另外設定策略組，別把所有地區的節點放進同一個自動選擇組。

切換成全域模式會比較快嗎？

全域模式改變的是流量選擇策略，不會直接增加線路頻寬。暫時切換可協助判斷分流規則是否影響結果，但測試後應恢復原本的規則模式，並在「連線」頁面確認出口。系統代理與 TUN 也不是單純的「速度開關」，應依應用程式是否需要接管流量來選擇。