先確認用途，再比較四項指標
先從訂閱中挑出兩、三個候選節點，不要直接把延遲測試排名第一的節點設為長期預設。日常瀏覽、長時間下載、地區限定服務和遠端連線，對網路的需求各不相同。節點能快速開啟測速網址，不代表連到所有目標網站時都一樣順暢。
Clash 客戶端負責顯示設定與切換策略，Clash 或 Clash Meta（mihomo）核心則負責建立代理連線及比對規則。訂閱中的節點名稱、倍率和地區說明由服務提供者提供；核心不會自動驗證標籤是否正確，也不會依照你的方案餘額，自動挑選最省流量的線路。
| 指標 | 優先檢查項目 | 常見誤判 |
|---|---|---|
| 延遲 | 多次測試結果、失敗次數、實際使用反應 | 單次最低值不代表整天都穩定 |
| 倍率 | 服務商計費規則與剩餘流量 | 倍率高不代表速度快 |
| 地區 | 實際出口 IP 與目標服務的判定結果 | 節點名稱不一定代表實際出口地區 |
| 協定 | 核心支援度、網路限制、伺服器端實作 | 不能單憑協定名稱判斷效能高低 |
怎麼看延遲：觀察波動，不只看最低毫秒數
客戶端測速不等於下載頻寬測試
常見的節點延遲測試，是透過代理連線存取指定 URL，測量完成請求所需的時間。測試網址、連線重用、DNS 快取、核心實作方式和客戶端的呈現方式，都可能影響結果。這不等於直接對伺服器執行 ICMP ping，也不能把面板上的 80ms 換算成每秒可下載多少資料。
比較節點時，請使用相同的測試 URL、逾時門檻和本地網路。先測一輪，間隔約 30 秒後再測，至少記錄五次結果。測試期間不要同時下載大型檔案；本地 Wi-Fi 壅塞或上傳頻寬用滿，也會讓節點的表現看起來忽快忽慢。
- 看中位數：將五次結果排序後取中間值，避免被單次異常低值誤導。
- 看波動：延遲從 70ms 跳到 900ms 的節點，互動體驗可能不如穩定維持在約 180ms 的節點。
- 看失敗次數：逾時不能當成 0ms。請記為失敗，並另外統計失敗次數。
- 看測試時段：平日白天和當地晚間尖峰時段各測一次，並保持測試條件一致。
用具體紀錄取代「感覺很快」
以下紀錄僅用來說明計算方式，並非本站對實際線路的測試結果。節點 A 五次測試結果為 62、65、71、680、逾時；節點 B 則為 165、172、178、181、190ms。A 的成功測試延遲較低，但有一次逾時和一次明顯飆高。若用於網頁表單、遠端桌面或頻繁呼叫 API，B 通常更值得進一步測試。
接著用實際服務確認：開啟三個常用頁面、登入一次、連續看十分鐘影片，或維持十五分鐘遠端連線。若測速網址能連通，實際服務卻無法使用，可能是目標網站限制、出口 IP 信譽、規則路由或地區判定問題，不應直接歸因於「節點延遲太高」。
流量倍率怎麼算：先確認方案的扣量規則
倍率通常是服務提供者用於計費的標記，不是 Clash 核心的標準效能參數。如果服務商依實際計費流量乘以倍率扣除方案流量，使用 2 倍節點傳輸 1GB 計費流量，就會扣除約 2GB 額度；使用 0.5 倍節點則約扣除 0.5GB。前提是服務商確實採用這種計算方式。
方案扣除流量 = 服務商統計的計費流量 × 節點倍率
計費流量 10GB × 0.5 倍 = 扣除 5GB
計費流量 10GB × 1 倍 = 扣除 10GB
計費流量 10GB × 2 倍 = 扣除 20GB實際扣除流量還可能受到上傳流量、協定額外負載、統計更新間隔，以及 GB 和 GiB 單位差異影響。請以方案管理後台的規則和紀錄為準，不要直接把客戶端的連線統計當成帳單。「標準」、「專線」、「高速」等名稱也不是統一的計費標準。
大量使用時可選低倍率，但仍須確認穩定性
- 影片、系統更新、雲端硬碟下載：優先測試低倍率線路，確認持續傳輸速度符合需求。
- 網頁、訊息、程式碼代管：流量較少，可優先考量連線成功率與互動延遲。
- 地區限定服務：先確認出口符合條件，再比較倍率，避免省下流量卻無法使用。
假設某條 2 倍線路速度可達 12MiB/s，而 1 倍線路可達 8MiB/s，這是速度與流量額度之間的取捨，不代表前者一定比較好。用於背景下載時，若能接受較長的完成時間，選擇低倍率可能更划算；若要臨時取得急用檔案，高倍率線路也可短時間使用。測速下載本身同樣會消耗流量，不必反覆下載數 GB 的測試檔案。
怎麼選節點地區：確認出口位置，別只看名稱
節點名稱中的「香港」、「日本」、「美國」可能指出口位置，也可能只是產品分類。連線入口、跨境傳輸線路和最終出口可能分別位於不同地點。入口離你近，不代表出口也在附近；連到入口的延遲低，也不代表到目標服務的整段路徑都很短。
- 手動選擇候選節點，並在連線面板確認檢測網站確實經過該節點，而非 DIRECT 或其他策略組。
- 透過該連線查詢公開出口 IP，記錄 IP 位址、地區資料庫的判定結果和網路營運商資訊。
- 開啟實際要使用的服務，確認內容、地區提示和登入結果；資料庫標示僅供參考。
- 重新連線後觀察出口是否改變。動態出口適合部分日常瀏覽情境，但可能觸發帳號的異地登入檢查。
地區限定服務通常也會檢查 IP 類型、帳號所屬地區、付款資料或裝置定位。某個 IP 資料庫顯示「日本」，不代表所有服務都會判定為日本，也不保證該出口具備存取資格。切換客戶端地區，只是改變網路出口的其中一個條件。
怎麼比較協定：先確認核心支援度與網路條件
協定會決定連線方式和部分傳輸特性，但節點效能也會受到伺服器負載、入口頻寬、路由、壅塞控制和客戶端裝置效能影響。不要把協定名稱當成速度等級。同一種協定用在兩條線路上的體驗差異，可能比不同協定之間的差異更大。
| 協定 | 確認事項 | 選擇時的重點 |
|---|---|---|
| Shadowsocks | 加密方式、外掛程式與核心支援度 | 設定相符，實際線路穩定 |
| Trojan | TLS、伺服器名稱與憑證設定 | 交握成功，憑證驗證正常 |
| VLESS | 傳輸方式、TLS 或 REALITY 參數 | 使用支援相應功能的核心 |
| Hysteria2 | UDP 可連通性、驗證與 TLS 參數 | 在受限網路下能否建立連線 |
| TUIC | UDP 可連通性，以及伺服器端與客戶端的相容性 | 工作階段穩定性與裝置資源使用量 |
Hysteria2、TUIC 使用以 QUIC 為基礎的傳輸方式，仰賴底層 UDP。在限制 UDP 的公共 Wi-Fi 或企業網路中，可能完全無法連線；這不代表訂閱中的所有節點都故障。可以保留一條使用 TCP 傳輸的候選線路，在相同網路環境下交叉測試。
VLESS、Hysteria2、TUIC 等節點需要確認所用核心是否支援。客戶端介面顯示節點名稱，不代表目前的核心能正確載入所有協定參數。請檢查核心名稱、設定載入記錄與錯誤訊息；舊版 Clash 與 mihomo 的支援能力不可混為一談。若要升級，可先參考客戶端選擇指南，再備份現有設定。
協定層級使用 UDP 傳輸，和應用程式是否透過代理傳送 UDP，是兩回事。例如遊戲的 UDP 流量，還取決於節點能力、規則和流量接管方式。啟用 TUN 也無法自動解決伺服器不支援 UDP、出口限制或線路壅塞問題。
依照相同步驟測試節點，避免測錯代理路徑
第一步：固定策略組與測試入口
在客戶端的節點面板中，將相關策略組切換為手動選擇；如果仍由 url-test 自動選擇，測試期間記錄的節點可能會改變。在連線面板查看目標網域、比對規則和代理鏈，確認這次請求確實經過候選節點。可以維持規則模式，但測試網域必須符合預期的策略。
系統代理只會影響讀取該設定的應用程式。終端機指令不一定會跟隨瀏覽器的代理設定，因此可以明確指定本機 HTTP 或 mixed 連接埠。以下假設客戶端監聽 127.0.0.1:7890；請先確認目前設定中的 port 或 mixed-port，如果實際連接埠不同，請相應修改指令。
curl --proxy http://127.0.0.1:7890 \
--connect-timeout 10 \
--max-time 20 \
--output /dev/null \
--silent --show-error \
--write-out "HTTP=%{http_code} TTFB=%{time_starttransfer}s TOTAL=%{time_total}s\n" \
https://www.example.com/以下是常見 Unix shell 的指令範例，網址使用文件專用的範例網域。實際比較時，請改成你常用且可正常存取的 HTTPS 網頁。Windows PowerShell 可使用 curl.exe，並將指令寫成單行，把輸出目標改為 NUL。明確指定代理只能確保請求進入本機代理連接埠；最終出口仍由核心規則決定，務必同時檢查連線面板。
time_starttransfer 是從開始請求到收到第一個位元組的時間，包含建立連線等階段；time_total 則是整個請求所需的時間。這些數值並非客戶端節點測速結果的完全重現，而是用來補充驗證實際請求路徑。若回應 HTTP 403，代表請求可能已抵達目標網站，只是遭到拒絕；不要把所有非 200 回應都當成代理斷線。
第二步：完整記錄一輪比較結果
- 使用相同裝置、網路和測試網址，並暫停其他大量傳輸工作。
- 每個節點測試五次，記錄延遲、失敗次數、倍率和實際出口地區。
- 使用相同服務測試十分至十五分鐘，記錄卡頓、重新連線和登入異常。
- 晚間尖峰時段再測一次，保留穩定通過測試的節點，不要只依單次最佳值排名。
如果所有候選節點都無法使用，請先確認訂閱餘額、設定是否已啟用、本機監聽連接埠和網路連線，再檢查 DNS 與規則。如果只有瀏覽器或只有終端機無法連線，請優先排查代理入口；也可參閱故障排除。不要同時修改 DNS、TUN、規則和節點，否則很難判斷是哪項修改解決了問題。
保留日常、地區限定與備用三類節點
測試完成後，通常不必收藏數十條線路。日常預設節點選擇一條尖峰時段穩定、倍率合適的線路；有地區需求時，保留一條通過實際服務驗證的出口；備用節點則選擇不同入口或網路路徑，並確認在目前網路環境下能獨立使用。
- 日常瀏覽：優先選擇回應穩定、倍率適中的節點，不要為了幾十毫秒的差距頻繁切換。
- 影片與下載：優先考量持續傳輸速度和流量扣除量，不要只看短時間請求的測速結果。
- 遠端工作：優先考量長連線穩定性和固定地區，進行重要操作前先確認目前的出口。
- 受限網路的備用方案：保留經測試可用、採用不同傳輸方式的線路，不要只複製同一線路並改用另一個名稱。
若要自動切換，url-test 會依測試結果選擇節點，fallback 通常依清單順序尋找可用節點；兩者都仰賴測試 URL 可連通，無法判斷流量倍率、帳號地區限制或服務登入狀態。load-balance 會依設定策略分配連線，也不代表單次下載能加總所有節點的頻寬。對出口位置敏感的服務，手動固定節點更容易掌控。
訂閱更新後，請再次確認節點名稱、倍率和策略組選擇。原有節點可能遭到刪除、更名或更換出口。最後留下的不是「延遲最低」的唯一優勝者，而是一組用途明確、成本可估算、路徑可驗證的節點。使用體驗改變時，依相同流程重新測試，才能分辨影響來自本地網路、線路負載還是目標服務。