1. 先依用途篩選，再比較延遲

Clash 用戶端顯示的節點，通常是一組連線至遠端代理伺服器的參數。節點連得上，不代表適合所有用途；延遲低，也不代表下載速度快。挑選前先確認需求：日常瀏覽重視回應時間，看影片要留意持續傳輸速度與地區可用性，遠距會議則要檢查延遲抖動、封包遺失及 UDP 連線。

建議依序檢查「目標服務可用 → 出口地區符合需求 → 倍率可接受 → 尖峰時段穩定 → 延遲較低」。先排除不符合必要條件的節點，再比較其他候選，會比直接挑毫秒數最低的節點可靠。

評估項目 實際檢查項目 無法據此判斷
延遲 使用相同測試網址重複測試，觀察延遲波動與逾時情況 頻寬上限、所有網站的連線速度
倍率 方案說明與用量面板上的實際扣量規則 線路一定比較快或穩定
地區 目標服務判定的出口 IP 地區 節點名稱與實體伺服器位置完全相同
協定 用戶端核心支援度、UDP 能力與目前網路狀況 某種協定在所有網路環境下都最快

2. 測試延遲：看多次結果，不只看最低值

HTTP 延遲不等於 ICMP ping

Clash 系列用戶端通常會透過小型 HTTP 或 HTTPS 網址檢查代理是否可用，並以毫秒顯示結果。這不只是對伺服器執行 ICMP ping。測試時間涵蓋哪些階段，會受到核心實作、連線重用、協定交握及測試網址影響；主要反映該次透過代理存取指定網址的狀況。

同一節點連線至不同網站，可能使用不同出口路由或 CDN。測試網址回應快速，只能表示這條探測路徑正常，無法保證影音平台、程式碼代管服務或遠距會議也同樣順暢。測速網址也可能無法連線；若整組節點都逾時，應先檢查測試目標，不要立刻刪除訂閱。

固定測試條件，記錄五輪結果

  1. 使用同一台裝置、同一個網路和同一個測試網址；暫停下載、雲端硬碟同步及其他會占用頻寬的工作。
  2. 挑出 3 個候選節點，每個測試 5 次，每次間隔約 10 秒，記錄延遲毫秒數與逾時次數。
  3. 優先比較中位數與波動範圍，再於常用時段複測，例如當地時間 20:00–23:00。
  4. 以實際用途驗證：連續開啟網頁數次、觀察影片播放數分鐘的緩衝情況，並在會議中留意聲音中斷與封包遺失。

例如，假設測得 A：45、48、220、逾時、190 ms；B：80、82、79、85、81 ms。A 的最低值較低，但 B 五次結果更集中。若用於互動式網頁或會議，B 通常更值得進一步測試。以上數字僅用來說明比較方式，並非任何線路的實測結果。

分別評估延遲、吞吐量與抖動

延遲 40 ms 的節點可能可用頻寬不高；延遲 150 ms 的節點也可能穩定傳輸大型檔案。下載速度會受伺服器負載、跨網壅塞、遠端限速及本地寬頻影響。測試吞吐量會消耗流量；先以小規模測試篩選，再觀察少數候選節點的持續速度即可，不必讓所有節點都下載大型檔案測速。

3. 流量倍率：依服務商規則計算用量

「0.5 倍」、「1 倍」、「2 倍」通常是訂閱服務商的計費標示，不是 Clash 核心通用的計費欄位。節點名稱中的倍率只是文字，重新命名不會改變扣量方式。實際用量以服務商規則及用量面板為準，也要確認是否合計上傳與下載、是否採用分時倍率，或設有獨立流量池。

計費用量 = 納入計費的傳輸量 × 節點倍率

範例：下載 8 GB、上傳 2 GB，依上下載流量合計計費
0.5 倍：10 GB × 0.5 = 5 GB
1 倍：  10 GB × 1   = 10 GB
2 倍：  10 GB × 2   = 20 GB

以上是簡化範例。統計週期、單位換算及協定額外負載，都可能造成用戶端統計與服務商面板的數字不完全一致。不要只憑一次小流量測試的差異，就認定計費有誤；可先記下用量面板數值，進行一段可控的傳輸，等面板更新後再核對。

  • 瀏覽網頁與即時通訊：總流量通常不大，可優先考量回應速度與穩定性。
  • 系統映像檔與大型更新：先確認是否需要代理，再比較低倍率節點的持續傳輸速度。
  • 長時間觀看影片：將每日觀看量納入用量預算，別只看單次播放是否順暢。

高倍率可能代表服務商定義的特殊線路，也可能只是產品定價方式，不能據此保證頻寬或穩定性。若要長期使用，應一併記錄相同時段的實際表現與扣量情況，才能評估成本是否合理。

4. 出口地區：以目標服務的判定為準

節點名稱中的「香港」、「日本」、「美國」通常表示預期出口地區，但名稱本身不能證明實際位置。中轉入口與最終出口可能位於不同地區，IP 資料庫也可能更新較慢。真正需要確認的是目標服務看到哪個出口 IP，以及該服務將這個 IP 判定為哪個地區。

地區符合需求，不代表服務一定可用

影音串流及其他地區限定服務，可能同時檢查 IP 地區、機房或住宅網路屬性、帳號地區、付款資料與風險控管狀態。節點能開啟登入頁，不代表所有內容都能播放；能播放某個節目，也不表示整個片庫都能使用。「解鎖」應以特定服務、特定內容及測試時間為準，不宜只看節點標籤。

  1. 在目標服務所使用的策略組中選擇節點，關閉舊頁面或中斷舊連線後再重新開啟。
  2. 查看用戶端連線記錄，確認該服務的請求確實套用預期策略並連至指定節點。
  3. 確認出口 IP 所在地區，再於目標服務進行實際操作，例如播放指定內容。
  4. 若結果不一致，請檢查帳號地區、應用程式的位置權限、IPv6 路徑，以及相關網域是否有直連。

DNS 查詢所在的地區與最終出口地區是不同概念。更換 DNS 伺服器，不會自動讓代理出口切換至其他國家。若部分請求採用直連，或透過 IPv6 繞過預期路徑，應先修正流量接管與分流設定，再檢查節點地區。若要了解相關欄位，請參閱完整文件。

5. 協定類型：先確認核心支援與傳輸條件

Shadowsocks、Trojan、VMess、VLESS、Hysteria2 和 TUIC 分別代表不同協定或協定體系，並非固定的速度等級。實際表現取決於協定參數、傳輸層、伺服器實作、網路壅塞及本地網路限制。同一種協定換一台伺服器，造成的差異可能比更換協定還大。

  • Shadowsocks：確認加密方式及核心支援範圍。使用額外外掛的節點，也要確認用戶端支援相應功能。
  • Trojan：常見部署會使用 TLS，伺服器位址、連接埠、驗證參數及 TLS 設定都必須相符。
  • VMess / VLESS：除了協定名稱，也要核對傳輸方式與 TLS 等參數；WebSocket、gRPC 等設定不能任意互換。
  • Hysteria2 / TUIC：使用 QUIC，仰賴 UDP 連線。若網路限制 UDP，可能無法連線；其他 TCP 節點可用，不代表這些設定也正確。

Clash 是用戶端生態系中常見的稱呼，實際支援的協定取決於使用的核心及版本。原版 Clash 與 Clash Meta（現稱 mihomo）支援的功能不同。匯入時若出現「不支援的代理類型」，應先確認核心，而不是把 YAML 中的 type 改成其他值；改名稱不會轉換伺服器協定。

6. url-test：在合格節點中自動挑選低延遲節點

完成地區、倍率及實際用途的篩選後，再用 url-test 比較候選節點的延遲。不要把不同地區、成本或使用限制的所有節點放進同一個自動策略組，否則延遲最低的節點可能不符合目前的用途需求。

以下範例適用於 mihomo。假設現有設定的 proxies 中已有名為 HK-01、HK-02 的節點，而且兩者都已通過相同用途的驗證。這些名稱僅用來示範引用方式；實際使用時必須與現有節點名稱完全一致。

proxy-groups:
  - name: HK-AUTO
    type: url-test
    proxies:
      - HK-01
      - HK-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
  • interval: 300：檢查間隔為 300 秒，不是 300 毫秒。
  • tolerance: 50：設定 50 毫秒的切換容差，減少因細微延遲差異而頻繁切換。
  • lazy: true：啟用延遲檢測；策略組未使用時，不應將它視為會持續依照間隔探測。
  • url：使用回應快速且穩定的測試網址。範例網址通常會回傳 HTTP 204，但仍須確認目前網路及節點能夠連線。

這不是完整設定。請將策略組項目合併至現有的 proxy-groups 清單，不要在 YAML 頂層重複新增同一個鍵。如果節點來自 proxy-providers，應依照提供者結構使用 use 及適當的篩選條件，不要假設前述靜態節點引用可直接取代提供者設定。

7. fallback：依序保留可用的備援節點

fallback 與 url-test 的用途不同：前者依候選順序選擇可用節點，後者則比較探測延遲。若希望平時固定使用首選線路，探測失敗時再切換至備援，可以使用 fallback。但它不保證遇到所有實際服務故障時都能立即切換。

proxy-groups:
  - name: HK-FAILOVER
    type: fallback
    proxies:
      - HK-01
      - HK-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

  - name: PROXY
    type: select
    proxies:
      - HK-AUTO
      - HK-FAILOVER
      - HK-01
      - HK-02

這段設定與上一節共用同一份 proxy-groups 清單；HK-AUTO 必須已經存在。接著讓需要代理的規則引用 PROXY，並在用戶端選擇自動組、備援組或單一節點。若原設定已有相同名稱的策略組，請修改原有項目，不要再新增同名項目。

例如，以下規則會將符合 github.com 及其子網域的請求交由 PROXY 處理。規則應放在可能先行匹配這些流量的廣泛規則及最終 MATCH 規則之前；不要為了套用範例而覆蓋所有既有分流規則。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  # 保留現有規則，最終 MATCH 仍放在末尾

如果首選節點仍能連上探測網址，但目標影音服務發生錯誤，fallback 可能會繼續使用首選節點。這是因為探測目標與實際服務不同。切換節點主要影響新建立的連線；已開始的下載、影片播放或長連線不一定會自動轉移，可能需要讓應用程式重新連線。

8. 日常挑選節點檢查清單

  1. 確認連線路徑：目標應用程式已透過系統代理或 TUN 連線，且連線記錄顯示套用預期策略。
  2. 確認必要條件：目標地區及特定服務可用，UDP 等必要功能也已實際驗證。
  3. 核對使用成本：在服務商面板確認倍率、上傳是否計費及剩餘流量，不要只看節點名稱。
  4. 比較穩定性：在相同條件下測試五輪，再於常用時段檢查延遲波動、逾時及持續速度。
  5. 建立候選策略組：將用途相同的節點放入自動組，並保留一個已驗證的手動選項。
  6. 儲存變更：先備份設定，再檢查設定檔並查看記錄；訂閱更新後，確認自訂策略組未遭覆蓋。

挑選節點的重點，不是找出一個永遠最低的延遲數字，而是為特定用途保留一組條件明確、成本可控且能重複驗證的候選節點。線路狀況會隨時段與網路環境改變。發生異常時，先釐清流量接管、規則、探測網址與實際服務，再決定是否切換節點。