Clash 延遲測試原理：為什麼數值不等於網頁與影片體驗

Clash 用戶端裡的延遲數值，通常是選擇節點時最先看到的參數。兩個節點分別顯示 68 ms 與 126 ms，直覺上很容易認為前者「快了一倍」。然而，這個數值只代表某次特定探測在當下條件所花費的時間，既不等於下載速度，也無法完整反映網頁載入、影片緩衝、遊戲連線或大型檔案傳輸的實際體驗。

若要理解延遲測試，必須先將一次網路存取拆成幾個階段：網域名稱解析、連上代理節點、完成代理協定交握、透過節點連線至測試目標、建立加密連線、送出請求、等待回應，以及後續的資料傳輸。不同 Clash 用戶端、核心版本與測試入口可能計算其中不同的範圍，因此同一節點在兩個用戶端顯示不同數值並不罕見。

Clash 延遲數值測量了什麼

許多圖形化用戶端將這項功能稱為「延遲測試」或「測速」，但底層通常並非傳統的 ICMP Ping。Clash 或 Mihomo 較常採用的方式，是讓指定代理節點存取測試 URL，並記錄請求成功所需的時間。測試目標可能只回傳極小的 HTTP 回應，例如狀態碼 204，因此傳輸資料量很少，結果主要反映往返時間與連線建立成本。

若測試 URL 使用 HTTPS，一次探測可能涵蓋 TCP 連線、代理協定處理、TLS 交握與等待 HTTP 回應。連線是否重複使用、DNS 是否已有快取，以及測試目標能否快速回應，也都會影響結果。用戶端介面通常只顯示彙整後的毫秒數，不會逐一列出各階段。

因此，介面上的 80 ms 更接近「透過這個節點完成一次指定請求，大約花了 80 毫秒」。它既不是節點伺服器與本機裝置之間的純物理距離，也不是存取所有網站都會得到的固定值。更換測試位址後，節點出口至目標伺服器的路徑會隨之改變，排序也可能不同。

為什麼低延遲不代表網頁與影片一定更快

延遲與頻寬是兩個不同的面向。延遲描述請求往返需要多久，頻寬則代表單位時間內能傳輸多少資料。某個節點可能在小型請求測試中迅速回應，卻因出口頻寬有限、晚間尖峰壅塞或多人共用，在持續下載時只能提供較低的吞吐量。另一個節點雖然首次回應稍慢，卻可能擁有更穩定的可用頻寬。

網頁載入包含許多獨立步驟

現代網頁往往需要載入 HTML、指令碼、樣式、圖片、API 資料與第三方資源。首次開啟時還可能經歷 DNS 查詢、TLS 交握及多次連線建立。低延遲有助於縮短小型請求之間的等待時間，但頁面總耗時仍會受到資源數量、伺服器處理時間、瀏覽器快取、HTTP 連線重複使用及目標網站本身負載的影響。

某個節點存取延遲測試網站很快，不代表存取目標網頁所使用的內容傳遞節點也一樣快。測試目標與實際網站可能位於不同國家或地區、使用不同電信業者，或處於不同自治系統，節點出口通往兩者的路由品質也可能截然不同。

影片體驗更仰賴持續吞吐量與穩定性

影片播放器通常會分段下載內容，並依照近期下載速度調整畫質。只要節點能持續提供高於影片位元率的吞吐量，稍高的基礎延遲未必會造成明顯影響。相反地，延遲很低但吞吐量頻繁下滑的節點，可能出現畫質降低、緩衝時間增加或播放中斷。

測試請求的資料量很小，通常無法讓傳輸進入穩定階段，也難以觀察持續數十秒後的壅塞情況。對影片使用情境而言，持續可用頻寬、抖動與封包遺失，往往比單次最低延遲更具參考價值。

互動式應用程式更重視抖動與封包遺失

遠端終端機、語音通話與部分即時應用程式對延遲較為敏感，但平均值仍不足以描述實際體驗。連續結果為 70、72、75 ms 的節點，通常比在 45、180、60、260 ms 之間跳動的節點更穩定。後者雖然偶爾出現更低數值，卻可能因抖動與重傳造成明顯停頓。

同一節點的延遲為何反覆變動

延遲不是節點的永久屬性，而是特定時間、入口、出口與目標共同形成的測量結果。短時間內連續測試出現數十毫秒的差異很常見；若變動幅度較大，則需要進一步確認本機網路、代理線路或測試目標是否不穩定。

1. 本機接取網路波動。 Wi-Fi 訊號干擾、行動網路切換、路由器排隊及其他裝置占用上傳頻寬，都可能讓探測請求等待更久。先在穩定的網路環境中重複測試，才能避免將區域網路問題誤判為節點問題。
2. 電信業者路由發生變化。 從本機到節點的路徑並非永遠固定。不同時間可能經過不同的中繼鏈路，晚間尖峰時段還可能出現排隊延遲與封包遺失。
3. 代理伺服器負載變化。 節點需要處理連線、協定交握與轉送。CPU 使用率、連線數量、出口頻寬及系統排程都會影響回應時間。
4. 測試目標狀態不同。 測試伺服器可能限制速度、被調度至不同位址，或針對不同節點出口回傳不同路徑。目標本身短暫忙碌時，所有節點都可能同時變慢。
5. DNS 快取與連線重複使用情況不同。 第一次探測可能包含解析與建立新連線，後續探測則可能使用快取或既有連線。用戶端及核心執行測試的方式，會影響前後結果能否直接比較。
6. 並行測試造成額外資源競爭。 同時向數十個節點送出請求，會占用本機連線、上傳頻寬與系統資源。批次結果適合初步篩選，對少數節點進行連續複測則更適合最終判斷。

url-test 策略群組如何使用延遲結果

在 Clash 與 Mihomo 設定中，url-test 是一種自動選擇策略群組。核心會依照設定的 URL 檢查群組內的代理，並優先選擇延遲較低且可用的節點。它適合在用途相近的一組節點間自動選擇，但自動選出的結果仍會受到測試目標影響。

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies:
      - 節點-A
      - 節點-B
      - 節點-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

interval 用來控制定期檢查的時間間隔，範例中的 300 表示每 300 秒檢查一次。間隔太短會增加探測請求與節點連線次數，間隔太長則可能無法及時察覺線路狀態變化。家用網路與日常瀏覽通常不需要每隔幾秒重新整理一次。

tolerance 用來設定切換容差。若目前節點與候選節點的延遲差距未超過設定範圍，策略群組可避免因微小的數值波動而頻繁切換。頻繁更換出口可能影響既有連線，也可能讓登入服務偵測到來源 IP 位址變更。設定適當容差，通常比持續追求低上幾毫秒的節點更穩定。

lazy 的具體行為應以使用中的核心版本為準，常見用途是在策略群組沒有實際流量需求時減少主動檢查。若設定由訂閱提供，不建議只看到參數名稱就隨意修改；訂閱更新可能覆蓋本機變更，用戶端也可能透過覆寫功能管理策略群組。

測試 URL 應保持穩定、回應本文很小，並且在路由上與主要使用情境具有一定關聯。若主要存取的目標與測試網站在網路位置上差異很大，自動選出的最低延遲節點未必能提供最佳實際表現。也要注意，使用 HTTP 與 HTTPS 可能得到不同結果，因為 HTTPS 測試還會包含加密連線的建立過程。

規則模式、TUN 模式與延遲測試的關係

延遲測試通常由 Clash 核心直接透過指定代理發起，不等同於瀏覽器流量完整經過系統代理或由 TUN 接管後的表現。用戶端顯示節點可用，只代表核心對測試目標的探測成功；若瀏覽器仍無法開啟網頁，還需要檢查系統代理、規則比對、DNS，以及應用程式是否略過代理等環節。

在規則模式下，實際存取會由上而下比對規則，第一條符合的規則會決定流量去向。測試節點時可能直接指定某個代理，但真實網頁請求可能套用另一個策略群組、直連規則或攔截規則。進行故障排查時，應查看連線紀錄或日誌，確認目標網域實際採用哪個策略，而不是只依策略群組頁面的延遲數值推斷。

TUN 模式可接管更多不遵循系統代理設定的流量，但不會自動改善代理節點的實體線路品質。啟用 TUN 後，DNS 處理、路由表、網路堆疊與防火牆權限都會參與實際連線；若節點延遲正常但應用程式無法使用，應分別檢查 TUN 是否已啟動、DNS 是否回傳可用結果、規則是否正確比對，以及目標應用程式是否使用特殊網路協定。

選擇節點時如何正確運用延遲資料

比較節點時，可先將延遲視為篩選工具，再搭配穩定性與實際工作驗證。沒有必要在 72 ms 與 79 ms 之間反覆切換，這類差距很容易被一次網路波動掩蓋。更值得關注的是節點能否持續使用、連續測試是否穩定，以及實際存取目標時是否出現明顯停頓。

1. 先進行批次初步篩選。 排除持續逾時及延遲明顯偏高的節點。逾時不一定代表節點完全無法使用，但表示它在目前條件下無法完成這項測試，應留待後續個別驗證。
2. 連續複測候選節點。 選擇三至五個候選節點，每隔一段時間重複測試。觀察結果的分布範圍，而不是只記錄最低的一次。
3. 使用實際目標驗證。 瀏覽常用網站、播放一段常用畫質的影片，或執行實際工作中的下載與連線工作。持續測試數分鐘，更容易發現壅塞與吞吐量波動。
4. 依用途分組。 網頁瀏覽、影片與低延遲互動對網路指標的著重點不同。可透過策略群組與規則，讓不同目標使用不同節點，不必要求單一節點涵蓋所有情境。
5. 保留穩定節點作為備援。 最低延遲節點發生波動時，穩定的候選節點比臨時重新搜尋更實用。使用 fallback 策略群組時，重點是可用性檢查與故障備援，而不只是選擇最低延遲。

延遲異常時的分層故障排查順序

當所有節點突然出現高延遲或逾時，應先檢查共用路徑，而不是逐一修改節點設定。所有節點共用本機裝置、區域網路、DNS 環境、測試目標與用戶端核心，其中任何環節發生異常，都可能讓整份清單同時無法取得結果。

第一層：本機網路

確認裝置能以直連方式正常存取常用網站，並檢查 Wi-Fi 訊號、行動網路狀態及路由器負載。暫停大型檔案上傳、雲端硬碟同步與區域網路內高流量的工作，再重新測試。若改用另一種接取網路後恢復正常，問題較可能出在原本的區域網路或電信業者路徑。

第二層：用戶端與核心

確認設定是否成功載入、代理節點是否顯示協定或參數錯誤，以及控制連接埠與核心程序是否正常。若更新訂閱後所有節點都出現異常，可切換回先前能正常啟動的設定備份，對照問題是否由訂閱結構、代理群組參照或覆寫設定變更所造成。

第三層：測試位址

若節點實際可以開啟網頁，但延遲測試全部逾時，應優先懷疑探測位址本身。改用穩定且只回傳少量資料的測試 URL 後再進行比較。不要頻繁更動多個變數；每次只調整一項條件，才能確認異常來自測試目標還是節點線路。

第四層：節點與線路

只有少數節點延遲偏高時，觀察它們是否位於相同地區、使用相同入口，或屬於同一條線路。若白天穩定、晚間持續升高，通常需要搭配長時間結果，判斷是否存在特定時段壅塞。單次恢復至低值，不能證明問題已經消失。

讓毫秒數回到正確的判斷位置

Clash 延遲測試提供輕量、快速且便於比較的網路探測結果。它可協助排除無法連線的節點、找出明顯高延遲的線路，並為 url-test 自動選擇提供依據。不過，網頁體驗還會受到 DNS、規則比對、目標網站路由及資源載入方式影響；影片與下載則更仰賴持續吞吐量、壅塞程度與封包遺失情況。

較穩妥的做法是：先用延遲進行第一輪篩選，再以連續測試觀察抖動，最後透過真實存取驗證頻寬與穩定性。面對幾個相近的數值時，不必追求絕對最低；連線穩定、實際目標可用，且策略不會過度頻繁切換，通常比短暫快上十幾毫秒更重要。