節點延遲：先確認連線可用，再比較網速

延遲低不代表下載快，顯示逾時也不代表節點完全失效。Clash 用戶端的「測速」通常是一次簡短的 HTTP 請求測試，並非持續下載測試。這項測試適合找出目前無法完成請求的節點，也能作為自動選擇策略群組的依據；若要評估影片播放、下載或會議品質，還得觀察持續傳輸速度、穩定性，以及實際目標網站的表現。

例如，一個節點顯示 80 ms，另一個顯示 180 ms，前者未必更適合下載大型檔案。前者可能回應較快，但頻寬有限；後者建立連線稍慢，卻能穩定傳輸更多資料。這些數字只是情境示例，並非本站實測結果。

單位也很容易搞混。100 Mbps 理論上相當於 12.5 MB/s；實際下載速度還會受到通訊協定額外負擔、伺服器限速及連線狀況影響。節點清單中的 100 ms，並不代表某個下載速度等級。

url-test 原理：測量一次代理 HTTP 探測所需時間

url-test 是一種策略群組類型。核心會透過候選代理存取指定的測試 URL，記錄耗時，再據此選擇節點。用戶端中的手動延遲測試按鈕，也常透過核心控制介面執行類似測試；不過，按鈕和策略群組可能使用不同網址及逾時設定，因此兩處顯示的數字不一定相同。

一次測試會經過哪些步驟

  1. 讀取測試網址，確認要測試的代理或策略群組。
  2. 連線至代理伺服器，完成該代理協定要求的連線程序。
  3. 透過代理存取目標；使用 HTTPS 時，還會進行目標端 TLS 交握。
  4. 送出 HTTP 探測請求，並在核心設定的計時範圍內取得回應。

不同核心版本在連線重用、計時起點及請求實作上可能有所差異。這項測試不能完全等同於 ICMP ping，也不是嚴格定義的單次網路往返延遲。更精確地說，它反映當下透過該代理完成簡短 HTTP 探測所需的時間，其中包含連線、交握及等待回應等成本。

為什麼測不出頻寬

常見的 generate_204 網址只會回傳很小的回應，204 代表沒有回應內容。請求沒有持續傳輸足夠資料，因此無法觀察連線在數十秒負載下的吞吐量。單次回應很快，只能代表當時這條測試路徑完成得快，不代表下載大型檔案時不會遇到限速。

測試通常也不等於依照實際使用規則存取網站。這只是對指定代理進行探測，無法證明瀏覽器的請求確實經過同一個節點。若要確認實際路徑，請查看用戶端的連線記錄、比對到的規則及最終代理鏈。

測試網址：更換 URL 可能改變排名

測試結果同時受到「本機到代理入口」及「代理出口到測試網站」的影響。測試網站的位置、是否使用 CDN，以及目標網域的解析方式，都可能改變結果。某個節點存取測試網站很快，但連到你的服務主機很慢，完全有可能。

測試網址 適合觀察 限制
https://www.gstatic.com/generate_204 簡短的 HTTPS 請求能否完成 只代表通往該目標的路徑，不代表所有網站
https://cp.cloudflare.com/generate_204 另一條目標路徑的回應狀況 邊緣節點位置可能不同，排名也會跟著變動
實際服務頁面或檔案 目標服務的實際使用體驗 登入、重新導向、快取及限速都會影響結果

HTTP 與 HTTPS 不宜混在一起比較

HTTP 測試通常不包含目標端 TLS 交握，數字可能較低，但只能反映 HTTP 探測結果。HTTPS 更接近日常瀏覽加密網站的情境，也可能顯示憑證或系統時間問題。比較節點時，應使用相同的網址、通訊協定及逾時設定，而不是直接排列一個 HTTP 結果和另一個 HTTPS 結果。

  • 優先選擇回應內容小、長期穩定且不需登入的網址。
  • 若所有節點都逾時，先更換第二個測試網址交叉確認。
  • 不要讓大量節點自動測試存取限制嚴格的服務介面。
  • 修改前先記下原本的網址，避免更換後誤以為網路突然變好或變差。

自動選擇設定：interval 與 tolerance 各有用途

以下是適用於支援 include-all 的 mihomo 核心策略群組片段，並非完整訂閱設定。它會將完整設定中的代理節點及代理提供者納入候選項目；使用前必須先設定實際代理。傳統 Clash 或舊版核心不一定支援此欄位，請依照對應核心的文件，使用 proxies 或 use 明確指定現有項目。

proxy-groups:
  - name: 自動選擇
    type: url-test
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: 代理出口
    type: select
    proxies:
      - 自動選擇
      - DIRECT

片段中雖然定義了 自動選擇 和 代理出口，但它們不會自動接管所有流量。完整設定中的規則仍須引用相應的策略群組。保留訂閱原有的規則結構，先確認目標請求會進入哪個群組，再決定是否替換；不要只為了測試，就把整份規則改成全域代理。

設定項目 範例值 用途
interval 300 週期測試間隔，單位為秒，不是請求逾時時間
tolerance 50 切換容許差距，單位為毫秒，可避免因微小差距頻繁切換
lazy true 群組未使用時可略過週期測試，因此不保證隨時都有最新結果

容許差距並非「低於 50 ms 才能使用」，也不是固定替所有結果加上 50 ms。它會影響自動選擇時的切換判斷。例如目前節點約為 130 ms，另一個節點約為 110 ms，改善 20 ms 可能不足以觸發切換；最終行為仍取決於核心實作及節點可用狀態。

逾時設定：5000 ms 是等待上限，不是網速門檻

逾時代表探測未能在指定時間內完成。逾時設為 5000 ms，表示最多等待約 5 秒；調高至 10000 ms，或許能取得部分較慢請求的結果，但不會增加節點頻寬。也不要直接把 timeout 加進任何策略群組：欄位是否支援及應放置的位置，都必須查閱相應核心的設定文件。

透過控制介面了解逾時參數

支援 Clash 風格控制 API 的核心，通常會提供代理延遲測試介面。以下指令僅供本機診斷使用，假設控制介面已在 127.0.0.1:9090 啟用，且此範例介面不需要驗證。測試對象是內建的 DIRECT，用來觀察直連基準，並非訂閱中的節點：

curl --get "http://127.0.0.1:9090/proxies/DIRECT/delay" \
  --data-urlencode "url=https://www.gstatic.com/generate_204" \
  --data-urlencode "timeout=5000"

成功時可能會回傳類似 {"delay":186} 的結果，表示這次測得 186 ms；這只是格式範例。若要測試特定節點，須將路徑中的 DIRECT 換成實際代理名稱，並對名稱進行 URL 路徑編碼。中文、空格及斜線不可任意直接拼接。

若介面啟用了 secret，請求必須附上相應的 Bearer 驗證標頭；權限不足而出現的 401 並非節點逾時。請勿為了方便測試而將控制介面開放至公網。9090 也不是固定必用的連接埠，請以用戶端目前的執行設定為準。

所有節點都逾時時，依序檢查

  1. 確認核心正在執行，且訂閱中的節點已載入，不要只看舊的節點清單。
  2. 改用第二個測試 URL；若只有一個網址失敗，先確認目標是否可連線。
  3. 查看記錄中的 DNS、連線遭拒、TLS 及逾時訊息，判斷失敗環節。
  4. 確認系統日期與時間正確，排除 HTTPS 憑證的時間異常。
  5. 在相同逾時設定下測試兩個不同節點，必要時再與直連基準比較。

實際網速測試：固定節點、固定目標並重複測量

比較兩個節點時，先將自動選擇改為手動固定候選節點，或使用現有的手動選擇群組。測試期間頻繁更換出口，會讓結果難以判讀。瀏覽器重用連線、伺服器快取及背景下載，也可能影響比較結果。

一套可重現的測試流程

  1. 固定條件：使用同一台裝置、相同的 Wi-Fi 或有線網路，並暫停其他大量流量作業。
  2. 確認路由：在連線記錄中核對目標網域、比對到的規則及最終節點，避免下載實際走了 DIRECT。
  3. 重複簡短請求：每個節點測試 5 次，記下所有數值，不要只記最低值。
  4. 觀察持續傳輸：使用同一個獲准存取的大型檔案，持續觀察 30～60 秒，分辨剛開始的瞬間速度與穩定速度。
  5. 換個時段重測：例如分別在 10:00 和 21:00 測試一輪，記錄晚間是否出現吞吐量下降或逾時增加。

假設五次延遲分別為 82、85、87、91、680 ms，中位數是 87 ms，但最後一次的大幅波動仍值得注意。這組數值只是計算範例，並非實測報告。小樣本 HTTP 測試的失敗比例也不能直接稱為「網路封包遺失率」；問題可能出在 DNS、TLS、目標網站或連線逾時。

延遲低但下載慢，優先檢查這幾項

  • 代理出口壅塞：簡短請求仍能快速完成，但尖峰時段的大量流量會互相爭用頻寬。
  • 目標伺服器限速：不同檔案網站或 CDN，可能對同一個出口採取不同限制。
  • 本機無線網路：訊號不穩及資料重傳會拖慢持續傳輸；可改用有線連線進行對照。
  • 通訊協定與裝置負載：加密處理、CPU 使用率及用戶端資源限制都可能影響吞吐量。
  • 路徑不一致：測速按鈕和實際請求使用了不同節點，或應用程式根本沒有使用系統代理。

最後一種情況尤其常見。瀏覽器能正常使用代理，不代表所有應用程式都走相同路徑。未遵循系統代理設定的程式，可能需要在應用程式內設定代理，或由 TUN 接管；TUN 會改變流量進入核心的方式，並不會憑空增加出口頻寬。入門設定可參閱系統代理設定步驟，概念差異請見概念快速查詢。

節點選擇結論：依使用情境判斷，別只按毫秒數排序

瀏覽網頁時，優先看回應是否穩定及目標網站能否連線；下載大型檔案時，優先看持續吞吐量；觀看影片時，著重緩衝速度與播放中斷情況；語音會議及即時應用則還要觀察抖動、斷線及相應的 UDP 路徑。HTTP 延遲測試無法證明 UDP 轉送可用，也不能取代應用程式內的網路診斷。

  • 日常瀏覽：保留一個穩定節點，或使用容許差距設定合理的自動選擇群組。
  • 大型檔案下載：比較實際下載速度，開始下載後盡量維持出口穩定。
  • 特定網站異常：先確認比對到的規則，再比較該網站的實際連線表現。
  • 晚間卡頓：在相同條件下重新測試，別只看上午保存的延遲數字。

最實用的紀錄只需幾項：測試時間、測試 URL、逾時設定、最終節點、重複測得的延遲及持續下載速度。資訊完整，才能分辨問題出在探測目標、節點路徑或本機設定。若需要更換用戶端，先參閱用戶端比較，再依平台選擇，不必為了追求更低的延遲數字而反覆重新安裝。