Clash 延遲測試數字怎麼來的：為什麼 60ms 的節點看影片還是卡

延遲數字實際測到的是什麼

在 Clash、Clash Meta（mihomo）及其圖形化用戶端中點擊一次延遲測試時，核心通常會讓指定代理節點存取一個測試 URL，並記錄從發出請求到取得有效回應所需的時間。常見目標是回傳 HTTP 204 的輕量網址，例如 https://www.gstatic.com/generate_204。介面上的 60ms，代表這次小型請求很快完成，不是節點每秒能傳輸多少資料。

一次測試可能包含建立代理連線、解析目標網域、與目標伺服器建立 TCP 連線、TLS 握手、HTTP 請求與回應。實際涵蓋哪些階段，取決於核心版本、協定實作、連線是否重複使用，以及測試入口。有些用戶端會呼叫 mihomo 外部控制介面執行單一節點測試；設定中的 url-test 群組與代理提供者健康檢查，則由核心定期執行。它們都會輸出毫秒值，但執行時機與連線狀態不一定完全相同。

它不等同於純粹的網路往返時間

系統中的 ping 通常使用 ICMP 回應封包測試網路層往返時間，而 Clash 延遲測試走的是代理協定與 HTTP 請求路徑。節點可能禁止 ICMP，卻能正常代理 HTTPS；也可能 ICMP 很低，但代理伺服器負載過高，導致驗證與加密處理很慢。因此，命令列 ping 得到 35ms、用戶端顯示 68ms，並不代表結果互相矛盾。

本機到節點：家用寬頻、Wi-Fi 與電信業者出口會產生第一段延遲。
代理握手：Trojan、VLESS、Shadowsocks、Hysteria2 等協定的傳輸與握手流程各不相同。
節點到測試站：出口線路決定第二段路由，繞路會直接拉高數字。
測試站回應：目標伺服器位置、負載、限速與 CDN 調度都會反映在結果中。
瞬間狀態：封包遺失重傳、CPU 搶占與無線干擾可能只影響某一次請求。

為什麼 60ms 的節點看影片仍然卡頓

影片播放需要持續的吞吐量。以常見位元速率估算，1080p 影片可能需要穩定的 5Mbps 至 10Mbps，4K 內容可能需要 20Mbps 至 40Mbps，峰值還可能更高。延遲測試只下載極小的回應，幾十毫秒便結束，無法觀察節點傳輸數十 MB 後是否限速、遺失封包或發生壅塞。

頻寬不足：首個封包很快，後續資料卻塞住

某個節點可以在 60ms 內完成握手，但共用出口在尖峰時段只有 2Mbps 可用頻寬。網頁開啟時只需傳輸幾百 KB，看起來反應很快；影片緩衝區持續消耗資料後，下載速度追不上播放速度，就會頻繁停頓。這是最典型的「低延遲、低吞吐量」。

反過來，距離較遠、延遲 180ms 的節點若能穩定提供 50Mbps，點擊播放後的初始回應雖然稍慢，卻可能在緩衝完成後持續播放。延遲影響互動等待時間，吞吐量決定大型檔案與影片能否持續載入，兩者是不同指標。

抖動與封包遺失：平均值掩蓋尖峰

連續五次結果為 58ms、61ms、63ms、420ms、逾時，用戶端有時只顯示最近一次或經過篩選的結果。使用者看到的仍可能是 61ms，但實際鏈路已存在明顯抖動。TCP 遇到封包遺失會重傳並縮小壅塞視窗；以 UDP 為基礎的傳輸也會因線路品質下降而增加復原成本。反映在影片分段下載上，就是速度忽快忽慢。

判斷抖動時不要只看最低值。連續測試 10 次，如果大多數結果落在 55ms 至 70ms，只有一次達到 90ms，通常比「最低 42ms、最高 680ms、兩次逾時」的節點更容易掌握。遊戲、語音與遠端桌面對尖峰尤其敏感。

測試站與影片站走的不是同一條出口路徑

測試 URL 可能命中離節點很近的 CDN，但實際影片服務卻被調度到另一個地區。節點存取測試站只需經過 6 跳，存取影片 CDN 卻可能跨洲繞路。即使兩個目標都使用 443 連接埠，自治系統、對等互連與壅塞點也可能完全不同。

地區解鎖也會改變內容節點。一個標示為美國的出口可能快速存取 Google 測試網址，但影片服務將其識別為資料中心網路，分配到負載較高的 CDN；另一個延遲稍高的住宅出口，反而可能取得更合適的內容邊緣節點。只按綠色數字排序，會忽略這層差異。

本機鏈路與用戶端模式也會介入

2.4GHz Wi-Fi 在擁擠的頻道上容易發生重傳，節點測試偶爾正常，但進行大量傳輸時問題會被放大。
TUN 模式接管系統流量後，MTU 設定不合適可能造成分片、封包遺失或部分網站載入停滯。
瀏覽器啟用 QUIC，而目前節點或線路對 UDP 支援較差，影片連線可能頻繁降級切換。
規則將測試 URL 交給代理，卻把影片網域分配到另一個策略群組，兩個結果便沒有直接可比性。
本機 CPU 滿載、播放器硬體解碼失效，也會呈現「影片卡頓」，但此時代理下載速度未必異常。

測試 URL、快取與連線重複使用如何改變結果

測試網址必須足夠小、回應明確，且能長期存取。回傳 204 的網址不含正文，可以減少下載量對結果的干擾。不過，「減少干擾」不等於「代表所有網站」。選擇不同地區的 URL，同一節點的結果可能相差數十甚至數百毫秒。

使用相同測試網址比較，才有橫向意義

節點 A 使用 Google 204 測得 70ms，節點 B 使用另一家中國大陸 CDN 測得 25ms，這兩個數字不能直接排序。目標伺服器不同，路由終點也不同。批次測試應讓所有候選節點存取同一個 URL、使用相同逾時設定，並盡量在同一時段執行。

如果主要用途是存取海外開發服務，可以保留一個穩定的 HTTPS 204 網址做初步篩選；如果主要用途是某個影片平台，還要補充實際播放或該平台靜態資源的測試。不要把需要登入、回傳大型頁面或經常重新導向的 URL 放進健康檢查，否則驗證、重新導向與頁面大小都會污染資料。

快取不會憑空增加頻寬

DNS 快取可以省下一次解析，TLS 工作階段恢復可減少握手開銷，HTTP 連線重複使用則可能略過重新建立連線。連續點擊測試時，後幾次低於第一次並不罕見。這種變化表示短連線的準備成本下降，不代表節點出口擴容。

用戶端與核心版本對連線池、健康檢查及並行測試的處理方式可能不同。一次批次測試同時對數十個節點施壓時，本機執行緒排程、DNS 查詢與路由器 NAT 表也會產生額外波動。需要複核時，間隔 2 至 5 秒單獨測試目標節點，比反覆點擊完整測試更具參考價值。

逾時不是「無限延遲」

當逾時設定為 5000ms，結果顯示 timeout，只能表示請求未在 5 秒內完成。原因可能是節點失效、目標 URL 遭封鎖、DNS 失敗、TLS 錯誤或網路暫時遺失封包。先換用已知可存取的測試 URL，再判斷節點本身是否離線。

如何解讀 mihomo 中的 url-test 與健康檢查

url-test 策略群組會定期檢查群組內的節點，並傾向選擇目前延遲較低且可用的項目。它適合自動選擇，但不是即時頻寬調度器。某個節點在健康檢查時回傳 55ms，之後進入尖峰時段發生壅塞，核心不會因影片速度下降就立即得知其吞吐量變差。

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

proxy-providers:
  airport-main:
    type: http
    path: ./providers/airport-main.yaml
    url: https://example.net/subscription.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
      timeout: 5000
      lazy: true
      expected-status: 204

這裡的 interval: 300 表示每 300 秒檢查一次，timeout: 5000 將單次健康檢查的逾時設定為 5000ms。tolerance: 50 用來減少延遲接近時的頻繁切換：目前節點與候選節點只差幾十毫秒時，維持現有連線通常比來回切換更穩定。lazy: true 則讓核心在策略群組未被實際使用時，減少不必要的檢查。

不要把間隔壓到 5 秒。假設提供者有 80 個節點，每 5 秒全部探測一次，會持續產生大量小型請求，也可能觸發伺服器端的頻率限制。桌面日常使用可從 300 秒開始；線路變化很快時可嘗試 60 至 120 秒，再觀察日誌與資源使用量。

透過外部控制介面複核單一節點

mihomo 常見的外部控制監聽位址是 127.0.0.1:9090。如果已設定存取金鑰，可以對指定節點發起延遲測試。節點名稱與測試 URL 需要先進行 URL 編碼。

curl -H "Authorization: Bearer local-secret" "http://127.0.0.1:9090/proxies/HK-A-01/delay?timeout=5000&url=https%3A%2F%2Fwww.gstatic.com%2Fgenerate_204"

不要為了遠端查看而將 9090 直接暴露在公網上。桌面端維持環回監聽即可。需要區域網路控制時，應設定存取金鑰，並使用系統防火牆限制來源位址。代理連接埠也要分清楚：常見的 7890 是 mixed-port，9090 是控制介面，兩者職責不同。

一套更貼近實際體驗的節點判斷方法

可靠的選擇流程不是尋找最低數字，而是分層篩選。先用延遲與可用性排除明顯故障節點，再測試持續吞吐量、抖動與目標網站，最後結合倍率與地區做決定。整個過程不需要讓每個節點跑滿，只要讓指標涵蓋實際用途即可。

第一步：連續測試，不看單次冠軍

固定使用同一個 HTTPS 測試 URL，逾時設定為 5000ms。
對候選節點連續測試 5 至 10 次，每次間隔至少 2 秒。
記錄中位數、最高值與逾時次數，不要只記最低值。
淘汰連續逾時、波動超過數百毫秒或頻繁斷線的節點。

例如節點 A 的結果集中在 75ms 至 88ms；節點 B 的最低值是 48ms，但其餘結果介於 60ms 至 530ms。網頁瀏覽或許兩者都能使用，但會議與遊戲應優先選擇 A。中位數穩定、極端值少，通常比偶然刷出的最低值更有意義。

第二步：進行 20 至 30 秒的持續下載

選擇可信賴的測速網站或大型檔案來源，透過目前的策略群組下載 20 至 30 秒。觀察速度能否保持穩定，而不是只看瞬間峰值。某個節點開頭衝到 18MB/s，5 秒後降至 700KB/s，表示突發頻寬不錯但持續能力不足；另一個節點穩定在 6MB/s，實際觀看高畫質影片往往更省心。

測試會消耗訂閱流量。倍率為 2.0 的節點下載 500MB，計費可能按 1GB 計算。流量有限時可以縮短測試時間或減小檔案大小，不必對數十個節點逐一進行完整測速。

第三步：直接測試目標服務

影片：播放 1080p 或 4K 內容 5 分鐘，觀察緩衝速度以及是否自動降低畫質。
開發：測試 Git 拉取、軟體套件索引與容器映像檔，確認目標儲存庫路由正常。
遊戲：查看實際遊戲內延遲、封包遺失與尖峰時段穩定性，不要用網頁測速取代。
會議：持續通話 10 分鐘，留意聲音斷裂與上行品質；下載速度快不代表上傳穩定。
遠端桌面：快速拖曳視窗並輸入文字，互動抖動比峰值頻寬更關鍵。

第四步：確認 Clash 規則是否選中同一個節點

延遲測試針對的是節點或策略群組，實際網站流量則會先經過規則匹配。若設定中的 DOMAIN-SUFFIX,example-video.com,MEDIA 命中 MEDIA 群組，而手動測試的是 PROXY 群組，數字再漂亮也無法解釋影片表現。

rules:
  - DOMAIN-SUFFIX,example-video.com,MEDIA
  - DOMAIN-SUFFIX,example-cdn.net,MEDIA
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

排查時開啟用戶端的連線頁面，開始播放後依網域篩選，查看命中的規則、策略群組與最終節點。以常見桌面用戶端為例，路徑通常是「連線」→「搜尋網域」→「展開連線詳細資料」；修改設定則從「設定」→「編輯目前設定」進入。不同用戶端的選單名稱略有差異，但需要確認的三項不變：目標網域、命中規則、實際出站。

延遲異常時應依什麼順序排查

先將問題拆分為裝置、本地網路、節點與目標網站四個層面。不要一看到紅色數字就立刻重新安裝用戶端。按照以下順序，可以快速縮小範圍。

檢查本地網路：分別使用有線連線與 5GHz Wi-Fi 測試一次，排除無線網路擁塞。
切換測試 URL：原網址全部逾時時，改用另一個穩定的 204 網址交叉驗證。
比較 DIRECT：直接連線存取測試站也很慢，問題可能出在本地電信業者或目標網站。
查看核心日誌：搜尋 timeout、DNS、TLS、connection reset 等錯誤。
核對系統時間：時間偏差會導致 TLS 憑證驗證失敗，看起來就像節點無法使用。
暫時關閉並行下載：網路硬碟、系統更新與雲端同步可能佔滿上行或下行頻寬。
檢查 TUN 參數：只有在 TUN 模式異常時，才測試系統代理模式並比較結果。

如果所有節點同時從 80ms 上升到 800ms，應優先檢查本地網路與訂閱服務入口；如果只有一個地區異常，通常是該地區線路或出口的問題；如果延遲正常但特定網站很慢，應轉向規則、DNS、目標 CDN 與地區解鎖方向排查。

結論：將延遲放回它應有的位置

Clash 延遲測試最適合回答兩個問題：節點此刻能否透過代理存取測試 URL，以及短請求的完成速度大致處於什麼程度。它適合用於可用性檢查與第一輪排序，不適合單獨預測頻寬、影片畫質、遊戲封包遺失或尖峰時段穩定性。

看到 60ms 時，可以將它理解為「短請求回應較快」，不要解讀成「節點一定很快」。還要查看多次測試的波動、20 至 30 秒的持續吞吐量、目標服務表現，以及規則實際命中的結果。延遲、頻寬、抖動、封包遺失、地區、倍率與協定共同決定使用體驗，任何單一數字都無法代表全部結論。

繼續檢查 Clash 節點

先安裝適合目前平台的用戶端，再依照教學匯入訂閱、核對規則命中與 DNS 設定。

前往下載頁查看教學