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

在 Clash 或 mihomo 的代理群組中，節點旁通常會顯示延遲數字。這個數字適合用來快速排序，卻不能直接代表網頁開啟速度、影片緩衝表現或長連線穩定性。原因在於「延遲測試」只是測量本機到某個測試目標完成特定階段所需的時間，而實際存取還會經過 DNS 解析、代理握手、TLS 建立連線、目標網站處理及內容傳輸等步驟。

要理解測速結果，首先要區分測試方法，其次要確認測試目標是否接近實際使用情境。Clash 常見的延遲顯示可能來自節點健康檢查、URL Test 或用戶端自訂測試；不同用戶端、核心版本與設定檔的實作細節也可能不同。看到 80 毫秒與 120 毫秒時，不應只按數字選前者，還要綜合延遲抖動、封包遺失、出口地區、規則命中及目標網站回應來判斷。

測速數字究竟測量了什麼

代理節點的延遲測試通常不會下載完整網頁，而是向指定位址發出較輕量的請求。測試流程可能包含連線至代理伺服器、完成代理協定握手，再存取測試 URL。最後顯示的毫秒數取決於用戶端的計時方式：有些實作統計 TCP 連線建立時間，有些統計 HTTP 請求取得回應的時間，也有些會採用核心提供的健康檢查結果。

TCP 延遲與 HTTP 延遲

TCP 延遲關注傳輸層連線能否快速建立。用戶端向目標位址傳送 SYN，伺服器回傳 SYN-ACK，連線完成後才能繼續傳輸資料。這個階段主要反映網路路徑與連線建立過程，通常不包含完整的網頁處理時間。

HTTP 測試則會在建立連線後發出請求，並等待目標回傳 HTTP 回應。結果會受到目標伺服器負載、反向代理排隊、TLS 設定、重新導向及回應內容產生速度影響。因此，HTTP 測試結果通常比單純 TCP 建立連線更接近「存取網站」的感受，但它仍然只是測試固定目標。

如果使用 HTTPS，首次存取還可能包含 TLS 握手。啟用連線重用後，後續請求可以沿用既有連線，省去部分建立連線的成本。因此，同一個節點在首次開啟頁面與連續重新整理頁面時，使用者看到的耗時可能不同；測試工具是否重用連線，也會改變數字的意義。

測試目標決定結果的適用範圍

測試 URL 並不是衡量網路品質的絕對標準。目標網站與出口節點的地理距離、電信業者互聯品質、伺服器負載及 CDN 調度都會影響結果。某個節點存取測試網站很快，不代表存取正在使用的服務也快。如果測試目標位於某個地區，而實際存取的內容由另一地區的 CDN 提供，兩者結果出現明顯差異是正常現象。

此外，代理規則會決定請求是否真的經過目標節點。如果測試位址命中 DIRECT，顯示的可能是本機直連路徑；若命中某個代理群組，才會經過該群組目前選用的節點。排查時應先檢查連線詳細資訊或規則命中紀錄，確認測試流量使用了預期的策略群組。

URL Test、連線檢查與實際存取的差異

URL Test 的核心用途，是比較多個節點存取同一個 URL 的回應時間，並依結果選擇延遲較低的節點。節點數量較多時，它適合用來初步篩選，也適合為自動選擇類策略群組提供週期性參考。但它不是頻寬測試，更不是針對所有網站的綜合評分。

1. 連線檢查：只回答「能否連線至目標」，常見結果為成功或失敗，可提供的耗時資訊較少。
2. TCP 測試：著重連線建立速度，適合觀察路徑的基礎回應，但無法說明 HTTP 服務的處理速度。
3. URL Test：向固定 URL 發出請求並比較回應時間，結果會受到目標網站狀態及請求方式影響。
4. 實際存取：包含 DNS、規則比對、代理協定、TLS、頁面資源、API 請求及內容傳輸，連線路徑更長，變數也更多。

例如，URL Test 回傳 70 毫秒的節點，開啟大型網頁時可能表現普通，因為頁面包含多個跨網域資源，其中部分資源被分配到較遠的 CDN。相反地，顯示 110 毫秒的節點若出口地區更接近目標服務、連線也維持穩定，實際首屏顯示與連續請求可能更順暢。對影片、遠端終端機或即時通訊而言，穩定性通常比單次測試中相差 40 毫秒更重要。

為什麼同一個節點的讀值會變動

節點延遲不是固定值。家用網路的 Wi-Fi 干擾、區域網路上傳頻寬被占滿、電信業者尖峰時段、代理伺服器的並行連線量，以及目標 URL 的瞬間負載，都可能造成波動。測試間隔較短時，連線可能被重用；間隔較長時，連線可能已關閉，重新握手便會增加耗時。同時執行多項測試，也可能讓本機或節點產生額外排隊。

用戶端的測試週期同樣需要留意。週期過短會產生頻繁請求，週期過長則無法及時發現節點狀態變化。自動選擇群組依測試結果切換節點時，切換本身會中斷部分連線；對下載工作與登入工作階段而言，頻繁切換未必比維持一個延遲中等但穩定的節點更合適。

延遲抖動、封包遺失與吞吐量如何改變體驗

平均延遲只描述一組樣本的中心水準，無法表達每次請求是否一致。延遲抖動是延遲隨時間變化的程度。例如連續測得 82、85、83、210、91 毫秒，平均值可能仍在可接受範圍，但那次 210 毫秒的突發等待便會影響互動。語音、遊戲、遠端桌面及持續 API 請求尤其容易受到延遲抖動影響。

封包遺失表示傳送的資料封包未在預期時間內抵達，或回應沒有返回。TCP 會透過重傳確保傳輸可靠，但重傳會增加等待時間，並可能觸發壅塞控制，降低傳送速率。少量封包遺失在一次短時間的 URL Test 中不一定會顯現，卻可能在大型檔案、長連線及持續播放影片時累積成卡頓。

吞吐量代表單位時間內可傳輸的資料量，會受到節點出口頻寬、共用使用者數量、壅塞控制、協定額外開銷及目標伺服器限速影響。低延遲節點不一定具備高吞吐量；某個節點可以很快完成小型請求，下載大型檔案時速度卻下降。反過來，延遲稍高但頻寬充足的節點，可能更適合系統更新、檔案同步及觀看高畫質影片。

從 Clash 設定與規則角度找出測速差異

同一台裝置上的不同應用程式，可能因規則命中不同而採用不同路徑。設定檔中的 DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP 與 MATCH 等規則會依序參與比對，最後將請求交給 DIRECT、某個代理群組或其他策略。測速時若只看代理群組名稱，卻未確認目標網域實際命中的結果，很容易把直連速度與代理速度混為一談。

DNS 也會影響測試與實際存取。網域解析可能在本機完成，也可能透過代理或設定中的 DNS 模式完成。解析結果會牽涉 CDN 調度；當解析器所在位置與代理出口位置不一致時，可能取得不理想的位址。Fake-IP 模式會為網域指派虛擬位址，並在後續連線階段由核心關聯原始網域；它改變的是網域解析與規則比對流程，不等於降低網路延遲。

TUN 模式會將更多系統流量導入虛擬網路介面，方便處理未遵循系統代理設定的應用程式。啟用 TUN 後，流量是否經過代理仍取決於路由、DNS 及規則設定。如果只在瀏覽器中測試，而問題出現在系統服務或其他應用程式，瀏覽器的 URL Test 結果無法涵蓋這些流量。排查時應記錄應用程式、網域、目標 IP、命中的規則及實際策略群組。

一套可重現的測試流程

1. 固定測試裝置、網路連線與測試時間，暫停占用大量頻寬的同步或下載工作。
2. 確認測試 URL 可以存取，並記錄用戶端採用的測試方法、測試週期及目標位址。
3. 選擇 3 至 5 個候選節點，連續測試多輪，不只記錄最低值，也要記錄中位數、最高值及失敗次數。
4. 分別存取常用服務，觀察首屏等待時間、連線中斷、頁面資源載入失敗及持續下載速度。
5. 檢查記錄中的規則命中與 DNS 結果，確認比較對象確實使用相同的代理路徑。
6. 在不同時段重新測試。如果尖峰時段波動明顯，應優先考慮穩定性與備援策略，而不是繼續追求單次最低延遲。

測試紀錄建議：
節點 A | URL Test 中位數 86 ms | 最高 142 ms | 失敗 0/10 | 下載穩定
節點 B | URL Test 中位數 63 ms | 最高 310 ms | 失敗 2/10 | 波動明顯
節點 C | URL Test 中位數 118 ms | 最高 135 ms | 失敗 0/10 | 吞吐量較高

如何依使用情境選擇節點

瀏覽網頁通常要關注 DNS 完成、TLS 建立連線及首位元組時間。此時可以優先選擇延遲中等但抖動小、規則命中穩定的節點。如果頁面資源來自多個網域，還要確認相關網域沒有被錯誤分配至不合適的策略群組。

影片播放更依賴持續吞吐量及通往內容 CDN 的路徑。初始緩衝階段可能受到延遲影響，但播放穩定後，頻寬與封包遺失更關鍵。測試時應觀察一段時間的持續下載，而不是只依節點卡片上的毫秒數排序。

線上遊戲與遠端桌面需要較低且穩定的往返時間，同時對延遲抖動與封包遺失十分敏感。節點地區接近目標伺服器通常有幫助，但電信業者互聯品質同樣重要。遇到瞬間延遲升高時，應查看是否存在本地網路排隊、Wi-Fi 訊號變化或背景上傳，不要立即判定節點失效。

檔案下載與系統更新更重視吞吐量、連線維持時間及伺服器端限速。延遲多出幾十毫秒通常不會明顯影響大型檔案傳輸；如果節點頻繁切換，反而可能導致工作重新建立連線。可以使用固定策略群組，確認節點持續穩定後再開始長時間傳輸。

對自動選擇類策略群組而言，建議將 URL Test 作為篩選條件，而非唯一決策依據。合理的設定還應考量節點可用性、地區需求、倍率規則、服務相容性及備援順序。自動切換的目標是減少人工維護，不是讓所有流量永遠追逐最低數字。

常見誤判與排查結論

「延遲最低就是最快」

最低延遲只表示某次測試中的回應較快。節點頻寬不足、封包遺失較多或通往目標網站的路徑不佳時，實際下載與頁面載入仍可能很慢。應將中位數、波動範圍、失敗次數與實際業務測試放在一起判斷。

「測速成功就代表所有網站都能使用」

測速目標能夠回應，只能證明這條測試路徑當時可用。不同網域可能命中不同規則、DNS 結果與出口路徑，也可能受到目標網站的地區限制或伺服器策略影響。遇到單一網站異常時，應先查看該網域的規則命中及連線記錄。

「啟用 TUN 就會自動解決延遲問題」

TUN 解決的是部分應用程式無法使用系統代理時的流量導入問題，不會改變實際距離、節點頻寬或目標伺服器負載。啟用後還需要檢查系統路由、DNS 處理、權限及現有 VPN 衝突。設定正確時，它能讓流量路徑更完整；路徑錯誤時，也可能增加排查複雜度。

「測試一次就足以選擇節點」

單次結果很容易受到瞬間壅塞與目標網站狀態影響。至少應進行多輪測試，並在實際使用情境中再次確認。如果節點的最低值很漂亮，但最高值與失敗次數明顯偏高，應將它視為不穩定節點，而不是首選節點。

總結而言，Clash 中的延遲數字是實用的觀測起點，而不是體驗評分。先確認測試方法與目標，再檢查規則、DNS 及代理路徑，最後綜合延遲抖動、封包遺失、吞吐量與實際業務表現作出判斷。採用可重現的紀錄方式後，節點選擇便會從「只看一個毫秒數」變成可解釋、可複查的網路診斷流程。