Clash 節點延遲測試原理：為什麼面板顯示的毫秒數不等於實際速度

面板上的毫秒數測量了什麼

Clash、Clash Meta（目前常用名稱為 mihomo）以及呼叫其控制介面的圖形化客戶端，通常會將節點測試結果顯示為一個毫秒數。這個數字常被稱為「延遲」或「測速」，但它既不是傳統命令列工具對伺服器執行的 ICMP Ping，也不是對節點可用頻寬的完整測試。它更接近一次透過指定代理節點完成 HTTP 請求所需的時間。

測試開始後，客戶端或核心會使用選定的代理節點存取測試 URL。過程可能包含連線至代理伺服器、協定交握、連線至目標網站出口、TLS 交握、傳送 HTTP 請求，以及接收回應標頭。不同核心版本、測試網址協定與連線重用狀態都會改變計時範圍，因此即使兩個客戶端測試同一個節點，也不保證顯示完全相同的結果。

一次常見延遲測試的請求路徑

1. 客戶端向 mihomo 控制介面發起節點延遲測試請求。
2. 核心從本機連線至節點伺服器，例如伺服器的 TCP 或 UDP 監聽連接埠。
3. 核心完成 Shadowsocks、Trojan、VLESS、Hysteria2 或其他代理協定所需的交握。
4. 節點伺服器從出口網路連線至測試 URL 對應的目標伺服器。
5. 如果 URL 使用 HTTPS，還要完成 TLS 交握並驗證憑證。
6. 目標伺服器回傳 HTTP 回應，核心停止計時並向客戶端回報毫秒數。

因此，面板上的 80 ms 不能直接解讀為「本機到節點的實際往返延遲是 80 ms」。其中也可能包含節點到測試網站的路徑與應用層交握。反過來，顯示 220 ms 也不一定代表下載速度低；只要線路頻寬充足、封包遺失較少、壅塞控制穩定，單一連線下載仍可能達到較高吞吐量。

它與系統 Ping 的差異

ping 通常會傳送 ICMP Echo 封包，觀察目標主機回應所需的往返時間。許多代理伺服器會限制或完全不回應 ICMP，但代理連接埠仍能正常接受 TCP 或 UDP 流量。也有伺服器對 ICMP 路徑採用不同的路由或優先順序處理，因此命令列 Ping 為 45 ms、Clash 面板顯示 110 ms 並不矛盾。

HTTP 延遲測試更接近日常網頁請求，但仍只是一個很小的樣本。測試回應通常沒有內容或只有極短內容，幾乎不會持續佔用線路。它能揭示「建立連線需要多久」，卻無法說明連線建立後每秒能傳輸多少資料。

測試 URL 如何改變結果

測試 URL 不是裝飾欄位。節點延遲值會同時受到目標網站位置、DNS 解析、HTTP 或 HTTPS 協定、目標伺服器負載、CDN 調度與電信業者路由影響。同一個節點存取位於東京的測試網站與位於法蘭克福的測試網站時，出口段路徑明顯不同，結果可能相差數十至數百毫秒。

為什麼 204 網址常用於連線測試

常見網址包括 http://www.gstatic.com/generate_204、https://www.gstatic.com/generate_204 和 https://cp.cloudflare.com/generate_204。這類介面正常時會回傳 HTTP 204，回應不帶正文，傳輸量很小，適合頻繁執行連線與延遲檢查。

HTTP 網址省略了 TLS 交握，數值通常更偏向連線與第一個 HTTP 回應所需的時間。HTTPS 網址會增加憑證協商與加密交握，更貼近日常 HTTPS 網站，但首次連線的數值可能較高。如果客戶端重用了既有連線，後續測試也可能低於首次結果。比較節點時，應固定 URL、逾時值、客戶端版本與網路環境。

設定中的 URL 與逾時值

在 mihomo 設定中，url-test 類型的代理群組可指定測試網址、檢查間隔與容差。以下設定每 300 秒檢查一次候選節點；當新節點只比目前節點快一點時，tolerance 可以減少頻繁切換。

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies:
      - 東京-01
      - 新加坡-01
      - 洛杉磯-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

interval: 300 表示週期檢查間隔為 300 秒，不代表每個使用者請求都會重新測速。tolerance: 80 的單位是毫秒，用於為節點切換保留差值空間。lazy: true 表示代理群組未被使用時可以減少主動檢查。具體支援情況應以目前 mihomo 核心版本與客戶端產生的設定為準。

控制介面也可以執行單一節點測試。典型請求形式為 GET /proxies/節點名/delay，並附帶 timeout 與 url 查詢參數。圖形化客戶端的「測試延遲」按鈕通常會在內部完成這個步驟。如果控制器監聽於 127.0.0.1:9090，請求只應由本機受信任的程式存取；啟用區域網路控制時，還需要設定存取金鑰並限制防火牆來源。

低延遲節點為什麼仍然卡頓

低延遲只代表短請求在測試當下回應較快。網頁開啟、影片播放、雲端硬碟下載與線上會議還依賴吞吐量、抖動、封包遺失、並行連線、DNS 結果與目標網站出口。任何一個環節出現瓶頸，都可能形成「面板 60 ms，實際載入卻很慢」的情況。

頻寬限制與共享壅塞

節點可能很快完成一個幾十位元組的 204 回應，但可用頻寬只有 5 Mbps。按理想換算，5 Mbps 約為 0.625 MB/s；下載 500 MB 檔案至少需要約 800 秒，還未計算協定開銷與速度波動。如果節點的入口或出口由大量使用者共享，凌晨測試可能達到 80 Mbps，晚間同一路線卻可能只剩 8 Mbps，短時間的延遲測試未必能立即反映這種差異。

頻寬也可能受到單一連線限制影響。有些線路使用多連線下載時看似很快，單一連線播放影片卻無法穩定；另一些線路的總頻寬足夠，但短時間突發後便受到限速。評估時應記錄持續 30 至 60 秒的速度曲線，而不是只看下載剛開始時的峰值。

封包遺失、抖動與 TCP 重傳

平均延遲無法描述每次請求的波動。連續五次結果為 62、65、61、64、180 ms，平均值仍不算高，但第五次的突增會影響遊戲、語音與遠端桌面。如果線路存在 2% 封包遺失，TCP 會重傳資料並調整壅塞視窗；大型檔案下載的吞吐量可能明顯下降，而一次成功回傳的 204 測試仍會顯示綠色數字。

UDP 類型的業務更容易暴露抖動。遊戲與即時語音通常不會等待遺失封包重傳，連續 20 至 40 ms 的延遲變化就可能表現為瞬移、聲音斷續或輸入回饋不穩定。此類用途應關注一段時間內的最大延遲、抖動範圍與封包遺失比例，而不是只選擇單次最低結果。

節點到目標網站的出口不同

測試 URL 回應快速，不代表所有網站都使用同一個出口。節點到 Cloudflare、Google、GitHub、串流媒體 CDN 與企業辦公服務可能採用不同路由。某個新加坡節點存取當地 CDN 只需 45 ms，但存取位於美國東部的業務伺服器仍可能超過 230 ms。影片網站還可能根據節點出口 IP 分配不同的 CDN 邊緣節點，使實際路徑與延遲測試路徑完全不同。

判斷特定網站的問題時，應直接透過該節點存取目標服務，而不是只反覆點擊全域延遲測試。瀏覽器開發者工具的「網路」面板可以查看 DNS、連線、TLS、等待第一個位元組與內容下載階段。如果等待第一個位元組很短但內容下載很慢，問題更接近吞吐量；如果連線階段已經耗時很長，則應檢查交握、路由或封包遺失。

本機處理、DNS 與 TUN 模式

TUN 模式會接管更多系統流量，並依據設定執行 DNS 劫持、路由判斷與協定堆疊處理。在效能正常的裝置上，這些開銷通常不是主要瓶頸；但在舊裝置、高 CPU 使用率、第三方安全軟體過濾或多張虛擬網卡疊加時，實際體驗可能下降。此時面板延遲測試是由核心直接執行，未必經過與瀏覽器、遊戲完全相同的系統路徑。

DNS 設定也會造成「節點延遲正常但網站很慢」。例如網域被解析到距離節點出口很遠的 CDN 位址，連線仍能成功，卻繞行了不合適的區域。使用 fake-ip 模式時，也應確認需要真實 IP 的區域網路裝置、企業網域或特殊應用程式已加入過濾規則。修改 DNS 設定後應重新載入設定，並清除作業系統或瀏覽器的 DNS 快取再測試。

更可靠的節點評估方法

節點選擇應拆分為連線能力、回應、穩定性、吞吐量與目標業務五個面向。先用面板延遲排除無法使用或明顯繞路的節點，再進行持續測試。這樣比單純依毫秒數由小到大排序，更接近實際使用需求。

第一步：固定條件重複測量

1. 暫停正在進行的下載、雲端硬碟同步與系統更新。
2. 固定使用有線網路或同一個 Wi-Fi 頻段，不要在測試期間切換行動網路。
3. 為所有候選節點使用同一個 HTTPS 204 網址。
4. 連續測試 5 次，每次間隔 3 至 5 秒，記錄最小值、最大值與失敗次數。
5. 分別在常用時段與晚間尖峰測試，至少保留兩組結果。

例如，節點 A 的五次結果為 78、81、79、83、80 ms；節點 B 為 55、210、62、逾時、58 ms。節點 B 的最低值較小，但波動與失敗更明顯。網頁偶爾開啟很快並不能抵消逾時風險，長時間使用時節點 A 往往更穩定。

第二步：執行受控下載測試

選擇來源穩定且允許測試的 HTTPS 檔案，持續下載 30 至 60 秒。每個節點使用相同檔案、同一個下載工具與相近時段，避免將測試網站本身的限速誤判為節點限速。記錄穩定階段的速度，不採用最初 1 至 2 秒的快取峰值。

速度單位也要統一。客戶端顯示 40 Mbps 時，理論上約等於 5 MB/s，因為 1 位元組等於 8 位元。考量 TCP、TLS 與代理協定開銷，實際檔案寫入速度通常略低。如果系統監視器顯示的是 MB/s，而測速頁面顯示 Mbps，直接比較數字會產生八倍誤差。

第三步：依用途測試目標服務

• 網頁與開發：測試常用搜尋引擎、程式碼儲存庫、套件來源與文件網站，觀察首屏與小型檔案請求。
• 影片：連續播放 10 分鐘，檢查畫質切換、緩衝次數與尖峰時段的穩定性。
• 遠端辦公：測試會議、遠端桌面與公司服務，重點記錄抖動與短暫斷流。
• 遊戲：優先測試對應的伺服器區域，確認 UDP 可用性、封包遺失與遊戲內延遲，而不是只測通用 204 網址。
• 大型檔案：觀察至少 60 秒的單一連線與多連線速度，並檢查是否週期性降至零。

第四步：建立簡易評分表

可以分別記錄平均延遲、最大延遲、失敗次數、持續下載速度與目標業務表現。對網頁用途而言，延遲與穩定性的權重可以更高；對大型檔案下載而言，吞吐量權重更高；對遊戲與通話而言，封包遺失、抖動與最大延遲通常比平均下載速度更重要。

延遲異常時的排查順序

當所有節點突然都變成逾時，先排查本機與訂閱狀態；當只有某個地區或某個節點異常，再考慮伺服器與線路。如果一開始就反覆更換 DNS、TUN 協定堆疊與規則集，會讓問題範圍變得更模糊。

所有節點都顯示逾時

1. 確認目前設定已成功載入，代理清單中存在可選節點。
2. 檢查測試 URL 能否透過目前網路解析，嘗試更換為另一個可靠的 HTTPS 204 網址。
3. 確認系統時間準確。時間偏差可能導致 TLS 憑證驗證失敗。
4. 查看客戶端日誌，重點尋找 timeout、connection refused、TLS handshake 與 DNS 錯誤。
5. 暫時關閉再重新啟用系統代理或 TUN 模式，確認舊程序與虛擬網卡狀態已釋放。
6. 更新訂閱並檢查節點位址、連接埠與驗證資訊是否發生變化。

許多圖形化客戶端提供「設定」→「日誌」或「核心」→「日誌」入口，具體選單名稱會隨客戶端版本變化。mihomo 日誌層級設為 info 通常足以確認連線階段；只有在需要定位交握細節時才短暫使用 debug，完成排查後恢復，避免日誌持續快速增長。

只有某個節點逾時

先在代理群組中切換至同一地區的其他節點。如果其他節點正常，問題通常集中在該節點的伺服器、連接埠、協定參數或入口線路。如果同一台伺服器承載多個連接埠，可以分別測試，但不要同時修改協定、SNI、傳輸層與測試 URL，否則無法確定是哪一項讓連線恢復。

Trojan 與使用 TLS 的節點需要正確的伺服器名稱與憑證匹配；WebSocket 節點還依賴 Host 與路徑；Hysteria2、TUIC 等 UDP 方案可能受到本地網路或防火牆的 UDP 限制。這類參數應以訂閱提供的設定為準，不應只為降低延遲數字而任意刪除。

延遲正常但瀏覽器仍然很慢

1. 確認瀏覽器流量確實命中預期的代理群組，可在客戶端連線清單中查看目標網域、規則與出站節點。
2. 檢查規則模式下是否有目標網域被錯誤分配至 DIRECT 或另一個代理群組。
3. 清除瀏覽器 DNS 快取，關閉可能使用獨立代理設定的擴充功能，再重新測試。
4. 比較系統代理與 TUN 模式。如果只有其中一種模式異常，請檢查連接埠衝突、虛擬網卡與路由表。
5. 測試目標網站，而非通用延遲網址，觀察連線階段與內容下載階段各自耗時多久。

常見本機連接埠包括 HTTP 代理 7890、SOCKS5 代理 7891、混合連接埠 7890 與外部控制器 9090，但訂閱與客戶端可能採用不同數值。瀏覽器手動代理、系統代理與第三方網路工具都必須使用目前實際的連接埠。如果兩個程式同時監聽同一個連接埠，核心可能啟動失敗，日誌通常會出現位址已被使用的訊息。

從延遲數字得到可執行的結論

Clash 面板延遲是一項短請求指標。它把本機到節點、代理協定處理、節點出口到測試網站，以及可能存在的 TLS 與 HTTP 互動，濃縮成一個數字。這個數字對連線檢查與同條件比較很有用，但無法涵蓋頻寬、晚間尖峰壅塞、封包遺失、抖動、目標網站路由與本機網路堆疊。

實際選擇節點時，維持測試條件一致，比追求某一次最低值更重要。連續五次穩定在 90 ms 的節點，通常比在 50 ms 到 300 ms 之間跳動且偶爾逾時的節點更適合長期使用。下載用途再加入 30 至 60 秒吞吐量測試，遊戲與會議再加入封包遺失與抖動觀察，才能得到符合用途的結論。

如果客戶端支援 URL-Test 自動選擇，可以將相近地區的節點放入同一個群組，設定固定測試 URL、合理的 300 秒檢查間隔與適度容差。對必須穩定維持工作階段的業務，則可選擇手動節點或具備健康檢查的故障轉移策略，避免輕微延遲變化觸發頻繁切換。