延遲數值代表什麼：完成一次小型請求所需的時間

Clash 節點清單中的毫秒數，通常來自透過指定代理發出的 HTTP 或 HTTPS 探測，而不是對節點伺服器執行 ICMP ping。url-test 策略群組會利用這類探測判斷候選節點是否可連線及其回應速度，再依照核心的選擇邏輯、容差等條件決定使用哪個節點。手動點選「測試延遲」與策略群組的背景檢測可能使用相關功能，但測試網址、逾時時間與觸發範圍不一定相同。

延遲衡量的是回應時間，下載速度衡量的是單位時間內傳輸的資料量。探測請求只傳回少量內容，適合用來發現連線失敗、明顯繞路或回應緩慢，卻不足以推估持續下載的傳輸量。因此，延遲 80 ms 的節點下載速度只有 2 MB/s，而延遲 180 ms 的節點卻能達到 15 MB/s，在技術上完全有可能。

url-test 請求經過哪些步驟

以 HTTPS 測試網址為例，核心通常會透過待測代理連線至目標 URL，建立必要連線並等待 HTTP 回應。測得的是特定探測實作所耗費的時間，不是某段網路線路的純傳播延遲。

  1. 準備連線：讀取節點參數，必要時解析代理伺服器的網域名稱；是否命中 DNS 快取會影響這次操作所需的處理時間。
  2. 建立代理連線：連線至節點入口，並完成相關協定所需的傳輸、安全性或代理交握。不同協定可能使用 TCP、UDP 及不同的多工機制。
  3. 連線至測試目標：透過代理路徑連至測試網站；目標網域的解析位置取決於所用協定與 DNS 設定，不能一概而論，認為都是在本機解析。
  4. 取得回應並計時：透過 HTTPS 存取還會涉及與目標網站的 TLS 交握，之後核心會依據實作方式記錄結果並交由客戶端顯示。

上述步驟是用來理解連線流程的模型，並不代表每次測試都會從頭執行所有步驟，也不表示每種核心都會把所有準備時間計入顯示數值。DNS 快取、已建立的通道、工作階段恢復及連線重用，都可能讓後續探測比第一次更快。比較不同客戶端的數值前，應先確認測試 URL 與計時方式是否一致。

為什麼系統 ping 延遲低，Clash 延遲卻高？

在終端機執行 ping 測試節點入口，只能觀察本機到該入口的 ICMP 往返情形；ICMP 也可能遭到限速或封鎖。Clash 的 URL 探測還會連線至測試網站，節點出口到目標網站的路徑同樣會影響結果。兩者測量的對象不同，不能直接相減來推算「協定額外耗損」。

延遲、頻寬與壅塞：各自該看哪些指標

指標主要反映無法直接推斷
URL 延遲，單位 ms小型請求在目前路徑上的回應時間持續下載頻寬、所有網站的速度
傳輸量，單位 MB/s一段時間內的實際資料傳輸能力互動是否即時、其他時段是否穩定
多次探測的波動情形回應時間是否穩定僅憑少量樣本判定封包遺失的位置
逾時或失敗的次數指定探測條件下的可用性節點無法連線至所有目標

例如，節點 A 五次回應時間為 70、74、71、520、76 ms；節點 B 則為 145、149、146、152、148 ms。這組數據僅供說明，並非本站實測。A 多數時候的數值較低，但有一次明顯尖峰；若用途是遠端終端機，B 可能帶來更流暢穩定的操作體驗。只看最低值，就會忽略這項差異。

持續下載也會受到伺服器限速、節點共用頻寬、跨網壅塞、傳輸協定的壅塞控制及本機網路影響。100 Mbps 的網路連線速度，在不計耗損時約為 12.5 MB/s，但單一連線不保證能跑滿。即使一次傳輸 204 位元組的小型回應很快完成，大檔案傳輸也可能在幾秒後因佇列堆積或共用出口競爭而降速。

為什麼晚間尖峰時段會「延遲正常，影片卻卡頓」？

小型請求傳輸的資料量很少，即使線路只能提供有限的傳輸量，也可能迅速完成探測；影片則需要持續下載影音片段。若可用頻寬低於目前畫質所需的位元率，緩衝內容就會逐漸耗盡。這時應查看播放器的緩衝狀態、影音片段的實際下載速度及連線記錄，而不是反覆點選延遲測試。

測試網址決定結果適用的範圍

常見的測試網址會回傳 HTTP 204，也就是成功回應但不包含本文內容。例如 https://www.gstatic.com/generate_204 就可用於這類探測。網址應能長期連線、回應內容精簡且行為穩定；避免使用大型下載檔案、需要登入的頁面，或經常觸發驗證碼的介面。

  • 協定不同：HTTP 與 HTTPS 的連線流程不同，兩個網址的耗時不能直接放在一起比較。HTTPS 還能測到與目標網站建立 TLS 連線是否正常。
  • 目標位置不同：同一個網域可能經由 CDN 導向不同地區。節點的出口位置改變後，實際連線的伺服器也可能不同。
  • 網站策略不同：測試網站可能限制部分出口，或暫時發生故障。單次測試失敗，只能表示這條探測路徑未能如預期完成。
  • 用途不同：能連上公開測試網站，不代表影片平台、程式碼儲存庫或遊戲服務的連線路徑與存取權限也相同。

建議保留一個穩定的基本探測網址，用於日常自動選擇，再透過實際服務驗證結果。若經常存取程式碼儲存庫，應比較儲存庫頁面的連線情形與實際拉取速度；若主要用來看影片，則應查看目標平台的播放統計。不要將大型檔案的 URL 設為自動探測網址，再誤以為它是完整的頻寬測試。

url-test 設定：檢測週期、容差與依使用情況檢測

以下是適用於支援相關欄位之 mihomo 核心的策略群組片段，需合併至現有設定。範例使用內建的 DIRECT 作為可解析的成員，目的是示範欄位結構；直接使用時只會測試直連，不會自動取得代理節點。實際設定時，應將成員替換為目前設定中已有的節點名稱，或依核心文件使用代理提供者。

config.yaml · 策略群組片段
proxy-groups:
  - name: 自動延遲選擇
    type: url-test
    proxies:
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
  • interval: 300 表示自動檢測間隔為 300 秒，也就是 5 分鐘；它不是請求逾時時間，也不代表每 300 毫秒測試一次。
  • tolerance: 50 是以毫秒為單位的切換容差，用來減少因延遲些微差異而頻繁切換，並非強制將節點延遲控制在 50 ms 以下。
  • lazy: true 可依使用情況減少對未使用策略群組的檢測；背景沒有持續出現新數值，不一定表示檢測失效。
  • proxies 是指向既有節點或支援之策略成員的清單。若只有一個成員，策略群組就沒有其他候選可供比較。

假設目前成員的延遲約為 120 ms，另一個成員約為 105 ms，設定 50 ms 容差就是為了避免因這類小幅差異而反覆切換線路。實際選擇也會受到成員可用性、檢測批次及核心實作影響，不應將容差視為精確的切換保證。策略群組切換成員，也不代表既有 TCP 連線會無縫轉移；新連線通常才會使用新的選擇建立。

逾時、失敗與「0 ms」該如何排查

逾時表示請求未能在規定時間內如預期完成，不代表延遲剛好等於逾時上限。假設測試逾時設為 5000 ms，顯示逾時只表示這次探測未能在 5 秒內成功回應；可能原因包括節點連線失敗、目標網站無法連線、DNS 異常或交握停滯。

客戶端手動測速、核心控制介面、策略群組自動檢測及代理提供者的健康檢查，可能各自使用不同的逾時設定。不要將某個 API 的 timeout 參數直接套用到所有 YAML 層級。請查閱目前核心對應欄位的文件，並從記錄確認檢測是否真的使用了修改後的參數。

  1. 先確認錯誤類型：連線遭拒、網域解析失敗、TLS 錯誤及請求逾時，分別指向不同環節。記下完整錯誤訊息與發生時間，比只記得「顯示紅色」更有幫助。
  2. 接著進行交叉測試：同一個節點改用另一個穩定的測試網址；同一個網址則改用另一個節點。一次只改變一個變數，判斷問題較可能出在節點還是目標。
  3. 確認流量是否經過預期的成員：測試某個節點，不代表瀏覽器目前也在使用它。請查看「連線」頁面中的實際命中規則、策略群組及出口成員。
  4. 確認本機流量接管狀況：瀏覽器可能遵循系統代理，終端機可能沒有設定代理，而 TUN 的接管範圍又不同。測速成功不等於所有應用程式都已經由代理接管。

遇到 0 ms、空白或異常偏低的數值時，也不要立刻認定它是「最快節點」。這類顯示可能與尚未測試、快取結果、數值取整或客戶端的顯示方式有關，應搭配記錄並重新測試確認。結果異常時先保留證據，再調整設定，避免同時重設 DNS、切換節點又更改模式，導致失去追查線索。

可重複執行的節點比較流程

比較節點時，關鍵在於維持測試條件一致。可依照以下步驟建立紀錄，不必頻繁修改整份設定。

  1. 固定測試環境：記錄客戶端版本、核心版本、測試 URL、逾時設定及網路類型。暫停大型檔案同步，並盡量避免在 Wi-Fi 與行動熱點之間切換。
  2. 記錄冷啟動結果：將第一次測試結果另外記錄，因為它較容易受到 DNS 解析及首次交握影響；不要與後續熱連線資料混在一起解讀。
  3. 重複取樣：每個節點測試 5 至 10 次，每次間隔約 10 秒，記錄中位數、最大值及失敗次數。所有節點都採用相同間隔，避免大量同時探測干擾本機網路。
  4. 驗證實際用途：先造訪一次實際目標，再進行約 30 秒的下載或播放測試；下載測試會消耗流量，請控制檔案大小及測試次數。
  5. 在不同時段重測：在平常使用的晚間時段再測一次，藉此區分偶發壅塞與長期表現，而不只保留離峰時段的最佳結果。

紀錄可以寫成：「節點 A，HTTPS 204 探測，中位數 92 ms，10 次測試失敗 1 次；目標下載平均 3.2 MB/s。」這些數值僅是紀錄格式範例。將延遲、失敗率及實際服務的傳輸量放在一起比較，會比只看單一綠色毫秒數更有參考價值。

依照用途挑選，不要只按最低延遲排序

  • 網頁與遠端終端機：優先考量回應穩定、尖峰較少及失敗率較低的節點。
  • 影片與大型檔案：在能夠連線的前提下，重點觀察持續傳輸量、緩衝狀況及尖峰時段的表現。
  • 遊戲與語音：重點觀察實際 UDP 路徑、封包遺失及延遲抖動。HTTP 探測無法取代遊戲伺服器或語音連線的測試。

url-test 適合從候選成員中挑出回應較快且可用的路徑，並不是頻寬排行榜。維持穩定的探測條件，再搭配實際用途與連線記錄判斷，就能理解「延遲低卻不快」的原因，也能減少沒有依據的反覆切換。