Clash 延遲測試原理：為什麼介面數值不等於實際瀏覽體驗

Clash 用戶端中的延遲數字通常被當成節點品質排名，但這個數字只描述一次特定探測。它反映指定測試網址、目前網路、DNS 狀態與當下線路負載，並不等於網頁完整載入時間，也不能直接代表下載速度、影片穩定性或長連線品質。了解測試流程後，延遲值仍然有參考價值，只是必須放在正確的範圍內解讀。

延遲測試測量什麼

Clash、Clash Meta（mihomo）及其圖形化用戶端通常會透過 HTTP 或 HTTPS 網址進行健康檢查。用戶端將測試請求交給指定代理節點，等待目標網址回傳符合條件的回應，再把過程耗時以毫秒顯示。實際測試 URL、逾時時間與實作細節由用戶端或設定檔決定，因此不同用戶端對同一節點測得的數字可能不同。

這類結果不是傳統意義上的 ICMP Ping。系統的 ping 指令通常會傳送 ICMP Echo 封包，而代理延遲測試會建立 TCP 連線，HTTPS 測試還會進行 TLS 協商。若節點使用 WebSocket、gRPC、QUIC 或其他傳輸方式，接入鏈路本身也可能增加握手步驟。兩種測試所使用的協定、連接埠、路由與伺服器處理流程不同，不能直接互相比較。

一次 HTTPS 探測可能包含的階段

1. 解析測試網域，或讀取既有的 DNS 快取。
2. 從本機連線至代理節點，完成節點協定所需的握手。
3. 由代理端連線至測試目標的 IP 位址。
4. 完成目標網站的 TCP 與 TLS 協商。
5. 傳送 HTTP 請求，等待回應標頭或指定內容。
6. 由核心記錄耗時，再透過控制介面交給用戶端顯示。

並非每次探測都會完整執行所有階段。DNS 快取、TLS 工作階段恢復、連線池與用戶端實作都可能縮短後續測試時間。第一次結果偏高、第二次明顯下降，常見原因是快取與連線預熱，不一定代表節點線路突然改善。

測試目標決定觀察到的路徑

若測試網址部署在距離節點出口較近的資料中心，結果主要反映本機到節點，以及節點到該資料中心的路徑。實際造訪的目標可能位於不同國家、電信業者或內容傳遞網路區域，後半段路由完全不同。因此，某個節點對測試網址回應很快，造訪特定網站時仍可能很慢。

為什麼同一個節點會出現不同數值

網路延遲不是固定屬性，而是某個時間點上多段鏈路狀態的總和。家用網路、接入電信業者、跨網互聯、節點入口、節點出口與測試伺服器中的任一段發生排隊，都會改變結果。只比較單次點擊得到的最低值，會放大偶然波動。

本地無線網路與接入鏈路

Wi-Fi 訊號微弱、同頻干擾、背景上傳與路由器負載都可能增加等待時間。尤其上傳頻寬接近滿載時，路由器緩衝區會堆積封包，輕量測試也可能從幾十毫秒升至數百毫秒。此時切換代理節點通常無法解決問題，因為壅塞發生在流量進入代理之前。

可以先暫停下載、雲端硬碟同步與影片上傳，再重複測試。如果所有節點同時下降，恢復背景工作後又一起升高，應優先檢查本地網路。在條件允許時，使用有線連線進行一次對照，也能排除部分無線干擾。

DNS 快取與解析路徑

測試網域第一次解析時需要額外時間。使用 fake-ip 模式時，核心會維護網域與虛擬位址的對應，再依連線還原目標網域；使用 redir-host 或直接回傳實際位址的模式時，解析鏈路又有所不同。上游 DNS 的回應速度、快取命中情況，以及是否經過代理，都會影響第一次探測。

需要注意的是，介面顯示的耗時是否包含 DNS 階段，取決於核心版本、測試介面與用戶端的呼叫方式。無法確認實作時，應將 DNS 視為潛在變數，而不是根據單一數值反推出某個階段的精確耗時。

連線重用與預熱效應

連續點擊測試時，底層可能重用已建立的連線，或利用系統快取、TLS 工作階段票證與已解析的位址。後一次測試省略了部分準備工作，因此結果較低。反過來，若用戶端強制建立新連線，數值會更接近新連線的啟動成本，但仍無法涵蓋網頁中的多網域資源與並行請求。

線路壅塞與抖動

節點在晚間尖峰、跨網結算點壅塞或出口負載升高時，延遲會週期性變化。假設五次結果依序為 65、68、210、72、190 毫秒，只看最低值會以為線路很快，只看平均值又可能掩蓋尖峰出現的頻率。更有效的觀察方式是同時記錄中位數、最大值與逾時次數。

為什麼低延遲不代表造訪速度更快

網頁體驗由多個階段共同決定。延遲測試通常只造訪一個輕量網址，而現代網頁會載入主文件、指令碼、樣式、圖片、介面與第三方資源。這些資源可能分布在多個網域，並依不同規則交由不同策略處理。單一測試請求成功，無法涵蓋整個頁面的連線圖。

頻寬與延遲是兩個不同指標

延遲描述請求往返需要多久，頻寬則描述單位時間內能傳輸多少資料。一個延遲 40 毫秒但出口頻寬較小的節點，開啟輕量頁面可能很快，下載大檔案卻很慢；一個延遲 90 毫秒但頻寬充足且穩定的節點，首次回應稍晚，卻可能更適合高畫質影片與大型下載。

下載速度還會受到 TCP 壅塞控制、接收視窗、封包遺失重傳與目標伺服器限速影響。高頻寬線路一旦持續丟包，也可能因反覆重傳而無法達到預期吞吐量。介面上的延遲值通常不會直接顯示這些資訊。

抖動比單次最低值更影響即時業務

語音、遠端桌面與互動式連線更重視延遲穩定性。如果測試結果在 50 至 300 毫秒間反覆變化，即使最低值很漂亮，輸入回應與音訊播放仍會不連續。相較之下，穩定在 90 毫秒左右的線路通常更容易帶來可預期的體驗。

一般延遲測試也不等同於嚴格的丟包測試。請求逾時可以提示嚴重問題，但少量丟包可能只表現為某次結果突然升高。要分析即時業務，應增加連續觀測，並結合系統網路工具、應用程式記錄與實際工作階段，而不是只看用戶端卡片上的單一數字。

規則分流會改變實際出口

Clash 會依規則由上到下比對請求。測試某個策略組時，使用的是該組目前選定的節點，但實際網站可能符合另一個策略組、直連規則或兜底規則。例如主站網域走代理，靜態資源網域卻走直連，頁面體驗就會由多條路徑共同決定。

排查時應開啟連線清單或核心記錄，確認目標網域符合哪條規則、選用了哪個策略組，以及最後使用哪個節點。只在策略組頁面反覆測速，無法驗證規則是否將實際流量交給同一個出口。

TUN 模式不會自動降低線路延遲

TUN 模式用於接管更多系統流量，並將 IP 封包交給核心處理。它能涵蓋不遵循系統代理設定的應用程式，但不會縮短實體鏈路。啟用 TUN 後，DNS 劫持、路由規則、MTU 與系統防火牆設定都會參與資料路徑；設定不當時，反而可能出現部分網站變慢、連線建立失敗或大封包傳輸異常。

比較系統代理與 TUN 模式時，應保持節點、規則、測試目標與網路環境一致。若只有 TUN 模式異常，可以檢查 DNS 接管、路由排除範圍、IPv6 行為與 MTU，而不是直接認定節點品質發生變化。

url-test、fallback 與手動策略組如何使用延遲

Clash 設定中的策略組類型，決定健康檢查結果如何參與選擇。手動 select 組只提供候選項，不會因為另一個節點延遲較低就自動切換。url-test 組會依指定網址定期測試，並傾向選擇延遲較低且可用的節點。fallback 組更重視候選節點是否可用，通常會依設定順序選擇第一個通過檢查的節點，而不是單純追逐最低毫秒數。

proxy-groups:
  - name: AUTO
    type: url-test
    proxies:
      - NODE-A
      - NODE-B
      - NODE-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: BACKUP
    type: fallback
    proxies:
      - NODE-A
      - NODE-B
    url: https://www.gstatic.com/generate_204
    interval: 300

interval 控制週期檢查間隔。間隔過短會增加節點與測試目標的請求量，也容易讓策略頻繁受到短暫波動影響；間隔過長則可能無法及時發現線路變化。日常網路可先從數分鐘的間隔開始，再依節點穩定性調整。

tolerance 用於減少 url-test 在延遲相近的節點之間頻繁切換。不同核心版本在細節實作上可能有所差異，但設定目的相同：候選節點差距不大時保留目前選擇，避免每次細微抖動都觸發出口變更。長連線、登入工作階段與下載工作通常更需要這種穩定性。

啟用 lazy 後，核心可在策略組尚未實際使用時減少主動檢查。這適合降低閒置測試的開銷，但也表示長時間未使用的群組重新啟用時，可能需要等待新一輪結果。用戶端介面中的立即測試按鈕通常會主動發起檢查，不應與背景週期檢查混為一談。

建立可重現的節點測試方法

可靠的比較需要控制變數。測試過程同時更換節點、DNS 模式、TUN 設定與測試 URL，最後很難判斷差異來自哪裡。較合適的方法是固定環境，分階段記錄。

1. 固定本地連線。在同一台裝置、同一個 Wi-Fi 或有線網路下測試，暫停大量上傳、下載與系統更新。
2. 確認訂閱已更新。檢查節點名稱、協定參數與策略組引用，避免測試已失效或已被訂閱刪除的項目。
3. 固定測試目標。先使用用戶端預設網址完成一輪，再使用與實際業務區域相關的穩定網址進行對照。
4. 重複測試，不要連續狂點。每個節點測試多次，並在測試之間保留合理間隔，記錄中位數、波動範圍與逾時次數。
5. 檢查實際規則。造訪目標網站後查看連線清單，確認網域、規則、策略組與最終節點符合預期。
6. 加入實際工作。分別觀察網頁首次開啟、影片緩衝、大檔案下載或遠端連線，避免用一種測試取代所有情境。
7. 分時段重測。在常用時段與晚間尖峰各記錄一輪，判斷節點是否存在週期性壅塞。

記錄結果時，不必追求實驗室等級的精確度。一張簡單表格就足夠：節點名稱、測試時間、三至五次延遲、逾時次數、目標網站首次開啟的感受與持續下載速度。持續幾天後，通常可以分辨穩定節點、只在閒置時段表現良好的節點，以及更適合特定目標路徑的節點。

為什麼優先查看中位數

平均值容易被單次極高結果拉高，最低值又過於樂觀。將五次結果排序後取中間值，可以降低偶發尖峰的影響。例如 62、64、66、70、420 毫秒的中位數是 66 毫秒，更接近多數請求的狀態；但 420 毫秒仍應保留作為抖動風險，不能直接刪除。

如果多個節點的中位數只差十幾毫秒，應優先比較穩定性、逾時次數與實際目標表現。對一般網頁而言，這種差距往往小於 DNS、頁面指令碼執行與伺服器回應造成的波動。

延遲異常與全部逾時的排查順序

當介面顯示逾時、失敗或異常高延遲時，先判斷是單一節點問題、所有節點問題，還是只有某個測試網址異常。先界定範圍，比立即修改設定更重要。

只有一個節點異常

• 檢查訂閱是否剛更新，以及節點協定、連接埠、傳輸路徑與伺服器名稱是否完整。
• 查看核心記錄中的握手失敗、連線遭拒、逾時或憑證相關資訊。
• 確認該節點沒有因策略組名稱重複、同名覆蓋或提供者篩選規則而被排除。
• 切換至同一訂閱的其他節點，判斷是單一入口故障，還是整個伺服器區域異常。

所有節點同時異常

• 先確認裝置能正常連線網路，並檢查系統時間是否準確。
• 暫停占用上行頻寬的工作，排除本地緩衝區膨脹。
• 檢查測試 URL 能否透過直連存取，以及是否發生重新導向、流量限制或區域封鎖。
• 確認 DNS 上游可用，尤其留意 TUN 模式下的 DNS 接管與防火牆權限。
• 重新啟動核心後再測試，避免只重新整理介面而核心狀態尚未恢復。

測速正常但目標網站異常

此時應從目標連線著手。查看它符合的規則與出口，檢查目標網域是否解析至異常位址，必要時比較系統代理與 TUN 模式。若網頁只有圖片或介面載入緩慢，還要檢查這些資源使用的獨立網域。測速網址正常只能表示該探測路徑可用，不能證明所有目標路徑都正常。

依使用情境選擇節點

節點選擇沒有統一的最低數值標準。瀏覽資訊與處理文件時，穩定性和規則正確命中通常比幾十毫秒的差距更重要；即時語音、雲端遊戲與遠端桌面更重視低抖動與低丟包；影片與大型下載則需要持續吞吐量與較少重傳。

網頁瀏覽

留意第一次連線、DNS 穩定性與目標網站路徑。可在延遲接近的候選節點中，選擇逾時較少的節點。

即時互動

留意連續延遲、抖動與丟包。穩定的次低延遲通常優於偶爾取得最低值的線路。

影片與下載

留意持續頻寬、晚間壅塞與連線中斷。輕量健康檢查只能作為可達性參考。

多策略分流

分別驗證業務對應的策略組與規則，不要用一個自動選擇組的結果代表所有出口。

日常設定可以保留一個手動策略組和一個自動測試策略組。自動組負責在可用節點中提供基本選擇，手動組則用於固定重要工作階段或處理目標路徑差異。若自動組頻繁切換，可適度增加容差或延長檢查間隔；若節點故障後恢復過慢，再縮短間隔以取得平衡。

最後應將延遲數字理解為診斷訊號，而不是品質結論。先確認測試對象與測試路徑，再觀察連續結果，最後透過實際業務驗證。如此既能運用 Clash 與 mihomo 的健康檢查能力，也能避免因單次最低值而頻繁切換節點，造成長連線中斷、登入狀態變化或體驗反覆。