Clash 節點延遲測試怎麼看？延遲數值與實際網速不同的原因

先分清延遲、傳輸量與穩定性

先用延遲排除明顯無法使用的節點，再透過實際用途判斷速度。Clash 清單中的 80 ms 通常代表一次探測所花的時間，不代表下載頻寬，也不保證影片能持續播放。節點甲測得 80 ms、節點乙測得 160 ms，不能因此推斷甲的下載速度是乙的兩倍。

把「速度」拆成三項指標，問題會更容易排查。瀏覽網頁時，留意建立連線及收到第一個位元組的速度；下載檔案時，留意持續傳輸量；視訊會議和遊戲則還要看封包遺失、延遲抖動，以及實際使用的 UDP 路徑。單次 HTTP 探測只能涵蓋其中一小部分。

例如，持續以 10 MiB/s 下載，約等於 83.9 Mbit/s；此處 MiB 以 1024² 位元組計算。電信業者常以 Mbit/s 標示網路頻寬，下載工具則可能使用 MB/s 或 MiB/s。先確認單位再比較數字，才不會把約八倍的單位差異誤當成線路故障。

了解 Clash 延遲測試的請求流程

先確認用戶端執行的是哪一種測試。許多 Clash 用戶端會呼叫核心的 URL 延遲測試：透過指定節點存取測試網址，並記錄請求完成所需時間。這不是單純對節點伺服器執行 ICMP ping，也不是持續下載大型檔案。

一次 URL 測試包含哪些步驟

1. 核心準備節點連線，必要時解析節點伺服器的網域名稱。
2. 連線至代理伺服器，並完成相應代理協定的交握。
3. 透過代理存取測試網站；使用 HTTPS 時也會進行 TLS 交握。
4. 取得測試回應，再由核心或用戶端顯示結果。

實際計時範圍、連線重用方式與結果呈現，會依核心及用戶端版本而異。不要把所有用戶端顯示的毫秒數都解讀成完整網頁載入時間。測試時使用的快取、既有連線，以及測試目標是否需要額外解析，也會影響結果。

操作時先開啟用戶端的連線記錄，再重新整理目標網頁。核對目標網域、比對到的規則及策略路徑，確認出口後再比較延遲。啟用 TUN 只會改變流量接管方式，不會自動增加節點頻寬，也不會把 HTTP 測試變成 UDP 效能測試。

統一測試網址與逾時條件

比較節點前，先統一測試 URL、網路環境與測試時間。常見測試網址 https://www.gstatic.com/generate_204 會回傳極小的 HTTP 204 回應，適合檢查短請求是否連通。回應內容很小，正是它無法代表大型檔案傳輸能力的原因。

測試網址不是中立的「全網速度標尺」。目標服務的部署位置、CDN 調度、出口網路互連情況與存取限制，都會改變測試結果。某條線路存取這個網址只需 90 ms，存取實際服務網站卻需要 300 ms，兩者並不矛盾。

在相同條件下完成一輪比較

• 固定使用同一個 Wi-Fi 或有線網路，並暫停系統更新與雲端硬碟同步。
• 選取兩個候選節點，使用相同的 HTTPS 測試網址。
• 每個節點分開測試 10 次，每次間隔約 5 秒，記錄成功次數與延遲中位數。
• 手動測試的逾時值統一設為 5000 ms；若用戶端無法修改，記下實際預設值。
• 接著用實際網站驗證，不要把更換測試網址後的結果直接混入原始紀錄。

逾時是等待上限，不是速度目標。若結果顯示 timeout，只能表示這次請求未能在時限內完成，或測試流程遇到連線、解析、TLS 等錯誤。把 3000 ms 改成 10000 ms 後出現數值，只能證明多等一會兒可能成功，不能證明線路已經變快。

若遇到「所有節點都逾時，但網頁能開啟」，先查看記錄中的具體錯誤，再檢查測試網址及用戶端是否確實使用預期的核心。若遇到「測試正常，但某個網站無法開啟」，應檢查該網站的規則、DNS、出口限制與登入狀態，而不是立刻調高測試逾時值。

排查延遲低、下載卻慢的原因

檢查頻寬限制與共用線路壅塞

小型回應只傳輸少量資料，即使節點被限制為 5 Mbit/s，延遲數值仍可能不錯。但 5 Mbit/s 的理論上限只有約 0.625 MB/s，扣除協定開銷後還會更低。此時繼續挑選延遲低十幾毫秒的節點，通常無法解決大型檔案下載緩慢的問題。

晚間尖峰時段也可能出現類似情況。共用出口仍能快速處理一次小型請求，卻無法持續提供足夠頻寬。分別在 09:00 和 21:00 下載同一個檔案；若只有晚間的持續速度明顯下降，而本機直連測試正常，就應優先懷疑代理路徑或出口壅塞。

檢查封包遺失與重傳

少量封包遺失可能不會反映在某次延遲測試中，卻會讓長連線反覆重傳並縮小傳送視窗。連續十次短請求全數成功，也不足以證明長時間傳輸穩定。可以同時觀察下載速度曲線是否反覆歸零、連線是否重新建立，以及系統網路工具中的 TCP 重傳次數是否增加。

中間路由器對 ICMP 回應進行限速，也可能讓路徑探測看起來有封包遺失。因此不要只憑某一跳的 ping 遺失率判定故障；應一併檢查最終目標、實際連線失敗情況與持續傳輸表現。尤其不能把 HTTP 探測失敗率直接當成線路的實際封包遺失率。

檢查目標網站、裝置與本機網路

• 改用另一個允許下載的大型檔案來源，排除單一網站限速與 CDN 快取差異。
• 改用有線網路重新測試，或移近路由器，以排除 Wi-Fi 干擾。
• 查看工作管理員或活動監視器，確認 CPU 是否持續接近滿載。
• 暫停其他裝置的上傳。上傳頻寬滿載後，確認封包與互動請求也可能排隊。

影片開始播放較慢，也可能與播放清單請求、分段影片伺服器、帳號地區及解碼流程有關。用戶端顯示的單一延遲數值，既無法涵蓋完整播放路徑，也不能證明這些環節都正常。

依固定流程記錄實際速度

先手動固定一個節點，再開啟實際使用的服務。測試期間不要讓自動選擇群組切換出口，也不要同時對所有節點進行並行測速。若修改了節點或規則，請關閉舊頁面並重新建立連線；既有連線不一定會立即改走新的出口。

使用 curl 分別查看請求各階段耗時

以下指令會透過本機 127.0.0.1:7890 的 HTTP 或 mixed 代理連接埠存取範例網站。先在用戶端確認實際連接埠；若不是 7890，請依本機設定修改。Windows 使用 curl.exe，可避免部分 PowerShell 環境中同名指令的差異。

curl --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 --output response.html --silent --show-error --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

time_connect 在此主要反映連接本機代理的耗時，不能當成遠端節點延遲。time_appconnect 與 time_starttransfer 是從請求開始累計的階段時間，不能視為可直接相加的獨立耗時。這個指令適合比較同一個 URL 的請求階段，不適合測量頻寬。

接著測持續下載速度，而非只看起始峰值

1. 選擇有權限存取且檔案大小足夠的固定檔案，確保測試能持續約 30 秒。
2. 固定使用單一連線或多連線方式；比較兩個節點時不能混用。
3. 略過開始幾秒的波動，記錄穩定階段的速度與停頓次數。
4. 每個節點重複測試三輪，並留出間隔，避免把瞬間快取結果當成長期表現。

以下為示意紀錄，用來說明判斷方式，並非本站實測，也不代表特定節點的品質。兩個節點都完成 10 次探測，下載方式與檔案也保持一致。

在這組條件下，下載大型檔案應優先考慮節點乙。若主要用途是短請求互動，還需要比較實際網站的第一個位元組時間與失敗情況。沒有單一毫秒門檻能決定所有用途的體驗。

了解 url-test 自動選擇的限制

使用 mihomo 的 url-test 策略群組時，自動選擇仍是依據指定 URL 的探測結果，而非頻寬排名。以下是設定片段，需合併至既有設定；節點甲 和 節點乙 必須對應設定中已存在的實際節點名稱。

proxy-groups:
  - name: 自動延遲
    type: url-test
    proxies:
      - 節點甲
      - 節點乙
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

• interval: 300 表示每隔 300 秒檢查一次，不是測試逾時值。
• tolerance: 50 設定切換容差，減少因數十毫秒波動而頻繁更換節點；它不會限制下載速度。
• lazy: true 可讓未使用的群組略過定期檢查，但不保證閒置時一定保留最新結果。

這段設定適用於支援相關欄位的 mihomo 環境。用戶端可能透過覆寫、訂閱合併或介面設定變更最終設定；請以實際載入的設定與記錄為準。修改前先備份可用版本，避免下次更新訂閱時覆蓋本機調整。

若下載工作需要固定出口，可以使用手動選擇群組指定節點。降低切換頻率有助維持行為穩定，但無法保證所有長連線都不會中斷；節點本身的可用性、用戶端連線處理方式及目標網站狀態仍然重要。

依照問題症狀完成最後檢查

延遲低，網頁仍然卡頓

先核對瀏覽器連線的策略路徑，再查看開發人員工具中的網路面板。分辨 DNS、連線、等待回應及內容下載等階段。若只有一個資源網域耗時異常，檢查它是否因其他規則而使用不同出口；不要拿首頁網域的測試結果代替所有子資源。

延遲高，下載卻很快

先確認測試目標是否繞路，再觀察持續傳輸量。長距離線路的往返時間可能較高，但只要可用頻寬充足、封包遺失率低，持續下載仍然可以很快。對大型檔案下載來說，不必只因毫秒數較高就淘汰這類節點。

延遲忽高忽低，偶爾逾時

先在相同時段比較有線網路與 Wi-Fi，再暫停上傳工作並重複探測 10 次。若本機網路穩定，但所有候選節點同時波動，請檢查網路連線；若只有一個節點波動，再檢查相應的代理路徑。使用實際網站再次確認，避免把測試服務本身的異常誤判為所有節點故障。

記下三項結果即可：實際使用哪個出口、短請求是否穩定，以及持續傳輸速度是多少。先確認這三項，再決定是否更換節點、調整規則或檢查本機網路。延遲數值可用來縮小問題範圍，最後仍應依實際使用情況選擇。