Clash 延遲測試數字怎麼看：為什麼 80ms 的節點反而更卡

Clash 延遲測試實際測量了什麼

Clash 介面顯示的 80 ms、150 ms 或 500 ms，通常不是傳統意義上的 ICMP Ping。以 Clash Premium、Clash for Windows 0.20.39，以及採用 mihomo 核心的 Clash Verge Rev 2.3.x 為例，客戶端通常會讓核心透過指定代理節點連線至測試 URL，再記錄完成請求所需的時間。常見網址包括 https://www.gstatic.com/generate_204 和 https://cp.cloudflare.com/generate_204。伺服器會回傳 HTTP 204，且回應本文為空，因此適合用於連通性檢查。

這次請求會經過本機 Clash 核心、節點入口、代理傳輸鏈路、節點出口與測試網站。測得的數字可能包含 TCP 建立連線、TLS 交握、代理協定交握，以及等待 HTTP 回應的時間；實際範圍取決於核心版本、連線是否重複使用、測試 URL 與客戶端實作。因此，這個數字更接近「完成一次小型網頁請求所需的時間」，不能直接視為本機到節點伺服器的實體往返延遲。

測試 URL 會改變結果

測試目標並不是中立的標尺。假設節點出口位於東京，連線至位於亞洲且互聯良好的測試網站可能得到 75 ms；換成路由較遠、連線策略不同的網站，同一節點可能變成 160 ms。若測試網站對某個出口 IP 限速、拒絕連線或觸發 TLS 異常，Clash 也可能顯示逾時，但這不一定代表所有網站都無法使用。

為什麼 80ms 節點反而比 150ms 更卡

80 ms 只代表某一次小型請求完成得較快。網頁瀏覽、影片播放、程式碼下載與雲端硬碟下載都會建立多條連線並持續傳輸資料，實際體驗還會受到丟包、抖動、頻寬、壅塞與出口品質影響。低延遲節點若每隔幾秒就發生重傳，使用感受通常會比延遲稍高但穩定的節點更差。

丟包會觸發重傳與壅塞控制

TCP 必須確保資料依序抵達。某個資料段遺失後，即使後續資料已經抵達，也可能需要等待重傳。一次 URL Test 只傳輸少量資料，若剛好沒有遇到丟包，就會顯示 80 ms；開啟包含數十個資源的網頁後，連線數量與資料量增加，暴露丟包問題的機率也會上升。

可以連續觀察 100 次請求，而不是只看單次結果。例如節點 A 的中位數為 82 ms，但第 95 百分位達到 780 ms，且有 3% 的請求失敗；節點 B 的中位數為 148 ms，第 95 百分位為 190 ms，失敗率為 0%。對網頁與會議連線而言，節點 B 往往更穩定。單次最低值不能代表整段使用期間的品質。

低延遲不代表可用頻寬高

URL Test 的回應本文通常為空，幾乎不會測試持續吞吐能力。一個限速為 5 Mbps 的節點可以在 70 ms 內回傳 204，但下載 500 MB 檔案時，光是理論傳輸時間就約需 800 秒；另一個延遲 160 ms、能穩定提供 80 Mbps 的節點，完成相同資料量會快得多。影片進入高碼率階段後，頻寬不足還會表現為畫質頻繁降低與緩衝。

晚間尖峰壅塞與佇列延遲

家用寬頻上行、電信商跨境鏈路與節點入口都可能發生排隊。閒置時測得 80 ms，開始下載後延遲升至 600 ms，這就是典型的負載延遲上升。此時頁面點擊回應會變慢，即使測速軟體仍顯示較高的吞吐量。判斷節點時，應分別在閒置與傳輸狀態下觀察延遲，不能只記錄凌晨的一組數字。

• 閒置延遲：沒有明顯上傳或下載工作時測量，反映基礎路徑。
• 負載延遲：持續下載或上傳期間測量，反映佇列管理與壅塞狀態。
• 抖動：多次結果之間的波動，例如 80、83、79 ms 較穩定，而 80、420、95 ms 則不穩定。
• 失敗率：逾時次數除以測試總次數，持續使用時比單次最低值更重要。

URL Test、健康檢查與自動選擇的差異

手動點選「延遲測試」通常只會更新介面中的目前結果；設定檔中的 url-test 代理群組則會定期測試成員，並依結果自動選擇。代理提供者的 health-check 負責檢查節點是否可用。這三項功能可能採用相似的請求方式，但觸發時機與用途不同。

proxy-groups:
  - name: AUTO
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

proxy-providers:
  provider-main:
    type: http
    url: https://example.invalid/profile.yaml
    path: ./providers/provider-main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

在這段範例中，interval: 300 表示自動選擇群組會依設定週期進行測試，tolerance: 80 用於減少延遲相近節點之間的頻繁切換。若目前節點仍在容差範圍內，核心不必因為幾毫秒的差距就立即轉移連線。lazy: true 表示代理群組未被實際使用時，可以減少不必要的主動測試。不同 Clash 分支支援的欄位有所差異，使用前應以目前 mihomo 或客戶端核心的文件為準。

自動選擇不會轉移所有既有連線

代理群組從節點 A 切換至節點 B 後，新連線通常會使用新的選擇；已建立的 TCP 連線或長連線不一定會立即轉移。正在播放的影片、SSH 工作階段或下載工作可能繼續佔用舊連線，直到應用程式重新連線。測試數字已經降低但目前頁面仍然卡頓時，可以開啟新的無痕視窗，或完全結束對應連線後再測試。

用四組指標判斷節點品質

可靠的判斷至少需要延遲分布、丟包與失敗率、持續吞吐量，以及出口與目標網站位置這四組資訊。測試時應固定本機網路，暫停系統更新與雲端硬碟同步，並避免同時切換 Wi-Fi 與有線網路。每個候選節點觀察 5 至 10 分鐘，比連續點擊十次按鈕後選擇最低數字更有效。

第一組：記錄中位數與高位延遲

平均值容易被少數極端結果拉高或拉低。可以記錄 20 至 100 次結果，重點觀察中位數、最大值與第 95 百分位。若沒有統計工具，至少檢查結果是否集中。以下兩組資料的平均值接近，但穩定性完全不同：

第二組：檢查代理請求失敗率

系統的 ping 指令可能遭節點入口防火牆停用，也可能只測到伺服器入口，而實際代理流量還要經過出口。因此，ICMP 丟包只能作為補充。更貼近 Clash 使用方式的方法，是透過本機代理連接埠重複請求同一個測試網址。

curl -x http://127.0.0.1:7890 \
  -o /dev/null -s \
  -w "connect=%{time_connect} total=%{time_total} code=%{http_code}\n" \
  https://www.gstatic.com/generate_204

範例假設 Clash 的 HTTP 或 Mixed 連接埠為 7890。如果客戶端設定為 7897 或其他連接埠，應使用「設定」→「參數設定」中顯示的實際連接埠。連續執行時，請注意 total 的波動、HTTP 狀態碼，以及是否發生逾時。同一節點測試 50 次若出現 2 次逾時，失敗率就是 4%；這類節點不適合作為需要長時間穩定連線的預設選擇。

第三組：分時段測試持續吞吐量

選擇來源可信、容量足夠的固定檔案，持續下載 30 至 60 秒，記錄穩定階段而非剛開始時的瞬時峰值。分別在工作日上午，以及 20:00 至 23:00 的晚間尖峰測試。若節點從白天的 70 Mbps 降至晚間 8 Mbps，而另一個節點始終維持 35 Mbps，後者更適合作為長期預設節點。

測速會實際消耗訂閱流量，也會增加節點負載，不需要頻繁下載數 GB 的檔案。驗證網頁與 1080p 影片時，100 至 300 MB 的樣本通常足以發現明顯限速；4K 高碼率影片、系統映像檔或大型儲存庫下載，則需要更長時間觀察穩定傳輸。

第四組：核對入口、出口與目標位置

節點名稱中的「香港」「日本」不一定同時代表入口伺服器、實際出口與完整路由。中轉節點可能先連線至中國大陸入口，再經專線前往境外出口；公網直連節點則可能由本機直接連線至境外伺服器。兩者的 URL Test 數字相近，晚間尖峰的穩定性與頻寬上限仍可能不同。

目標網站的位置也會影響選擇。存取東京的服務時，日本出口通常路徑較短；存取歐洲自建伺服器時，歐洲出口可能減少從出口到目標網站的二次跨洲傳輸。只按「離本地最近」排序，忽略出口到目標網站的後半段路徑，容易得到測試延遲低但實際業務速度較慢的結果。

TUN 模式下數字正常但應用程式仍卡頓的排查順序

Clash 延遲測試由核心主動發起，只能證明核心能透過節點存取測試網址。應用程式流量是否真正經過同一個代理群組，還取決於系統代理、TUN 接管、DNS、規則命中，以及應用程式本身的代理行為。測試顯示 80 ms，但瀏覽器仍然直連或命中了另一個代理群組，這兩種現象並不矛盾。

1. 確認目前模式。檢查客戶端目前處於規則模式、全域模式或直連模式。使用規則模式時，查看連線清單，確認目標網域命中了預期規則與代理群組。
2. 核對系統代理。在 Clash Verge Rev 2.3.x 類型的介面中，檢查「設定」→「系統設定」或首頁的「系統代理」開關。只啟用核心但未開啟系統代理時，遵循系統代理設定的應用程式不會自動進入 Clash。
3. 檢查 TUN 狀態。需要接管不遵循系統代理的應用程式時，再啟用 TUN。若狀態啟動後立即停止，應檢查服務安裝、管理員權限與虛擬網卡衝突，而不是反覆測試節點延遲。
4. 核對 DNS。網域解析失敗、Fake-IP 對映異常或區域網路 DNS 遭劫持，都可能表現為網頁長時間等待。直接存取已知 IP 並不能完整排除 DNS 問題，因為 HTTPS 仍依賴正確的網域與憑證。
5. 查看連線詳細資料。連線清單應顯示目標主機、規則、代理鏈，以及上傳與下載位元組數。若測試節點與實際連線使用的節點不同，請先修正规則或代理群組選擇。
6. 重新建立連線。關閉瀏覽器分頁、暫停下載後重新開啟。HTTP/2、HTTP/3 與 WebSocket 長連線可能會繼續沿用切換前的路徑。

不同使用情境應優先看什麼

對日常網頁而言，80 ms 與 110 ms 的差距通常沒有 0% 與 3% 失敗率的差距重要；對高畫質影片而言，延遲 150 ms 且能穩定提供 60 Mbps 的節點，通常優於延遲 70 ms 但只能維持 6 Mbps 的節點；對遠端桌面而言，平均 90 ms 卻頻繁跳到 500 ms，會比穩定維持 140 ms 更難操作。

更合理的節點選擇方法，是先排除逾時與高失敗率節點，再依使用情境比較穩定性與吞吐量，最後才用延遲進行細部排序。url-test 適合從一組品質接近的節點中自動選擇，不適合取代完整的鏈路品質評估。看到 80 ms 時，應將它理解為一次測試樣本，而不是節點效能的總分。