為什麼「自動選節點」常常像沒作用

多數使用者的直覺是：訂閱裡有很多節點，介面又有「自動」「測速」字樣，理論上應該會幫我挑延遲最低的那條。實務上 Clash 先做規則命中，決定這次連線要交給哪一個策略名稱；若該名稱對應到 select，就只會用你手動選中的那一個出站，根本不會自動換。若名稱對應到 url-test，核心才會依健康檢查在候選列表中挑一個；但若規則其實把流量送到別的組、或測速目標與你真實造訪的網站路徑差太遠，你仍會覺得「顯示延遲很低卻還是卡」。

另一個高頻問題是名稱對不上：規則寫 ,Proxy，但你的 proxy-groups 裡只有 ♻️ 自動選擇 或 PROXY-US，YAML 載入階段就可能報錯或默默退回預設行為。還有一種情況是訂閱更新後節點改名，UI 仍顯示舊別名，實際引用已斷。這些都會讓「自動選節點」看起來失效。建議把除錯拆成兩句話：這條連線命中哪條規則？該規則指向的策略組 type 是什麼？

ℹ 名詞釐清：設定檔裡 DNS 區段也可能出現 fallback 作為解析備援伺服器列表，與 proxy-groups 裡 type: fallback 的代理主備鏈是不同層級的概念。本文若未加前綴，fallback 皆指策略組類型。

策略組 type 速覽：select、url-test、fallback、load-balance

在 proxy-groups 中，type 決定「這個組如何從 proxies 列表裡挑出站」：

若你的目標是自動選最快，首選通常是 url-test；若目標是優先用 A，壞了再換 B，首選是 fallback。兩者可以並存：例如一個組負責日常低延遲，另一個組專門做媒體解鎖，再在規則裡分流。

url-test 實配：測速 URL、interval、tolerance

下面是一段結構示意（欄位名與預設值請以你所用的 Clash／Clash.Meta 版本文件為準）。註解使用英文。

proxy-groups: url-test (illustrative) 
proxy-groups:
  - name: AUTO-BEST
    type: url-test
    proxies:
      - NODE-A
      - NODE-B
      - NODE-C
    url: "http://www.gstatic.com/generate_204"
    interval: 30
    tolerance: 50
    lazy: false

url：健康檢查請求的目標。常見做法是選回應極短、地理上對你業務有代表性的位址；若目標在你所有節點上都慢，測速結果會一起變差，但仍可能相對排序。interval：多久重測一次；過短會增加流量與節點負擔，過長則故障切換變慢。tolerance：只有當新最佳節點比目前選中的節點快超過這個毫秒門檻，才傾向切換，用來抑制抖動。lazy：若為 true，部分核心會在該組尚未被實際使用時延後測速；若你一開機就想看到完整延遲表，可視情況關閉 lazy。

部分版本支援 expected-status 等額外欄位，用來判定「什麼算成功」；若測速 URL 回非預期狀態碼，節點可能被標成不可用。若你發現全部節點突然一起紅燈，優先懷疑測速目標本身被攔截或阻擋，而不是整包訂閱同步失效。

fallback 實配：主備鏈與切換邏輯

fallback 組同樣會做健康檢查，但決策邏輯是「從列表頂端開始找第一個健康的」。因此排序就是優先級：把你最信任的主線放最上，備援、高價流量池、或「能用但不優先」的節點往後放。

proxy-groups: fallback (illustrative) 
proxy-groups:
  - name: PRIMARY-THEN-BACKUP
    type: fallback
    proxies:
      - NODE-PRIMARY
      - NODE-BACKUP
      - DIRECT
    url: "http://cp.cloudflare.com/generate_204"
    interval: 15

上例最後放入 DIRECT 代表「代理全掛時退回直連」（是否適合你的法規與網路環境請自行判斷）。若你不希望任何自動退回直連，就不要把 DIRECT 寫進 fallback 鏈。相對地，url-test 通常用於一群同級候選之間挑快的；fallback 則適合明確主備。兩者都依賴健康檢查，因此 url 與 interval 仍要認真選。

延遲測速 URL 要怎麼挑

測速的本質是「用一個小而穩定的 HTTP 往返，估計從節點到該目標的路徑品質」。因此沒有全宇宙唯一正解，只有「在你的網路與業務下是否具代表性」。實務上可遵循：

規則列與 DIRECT、REJECT、MATCH 怎麼接策略組

規則列（rules:）每一行最後一欄是策略，可以是內建 DIRECT（直連）、REJECT（拒絕），或是你在 proxy-groups 定義的名稱。命中規則後，流量就交給該策略；若策略本身是 url-test／fallback，核心再在該組內挑實際出站。

rules fragment (illustrative) 
rules:
  - DOMAIN-SUFFIX,corp.internal,DIRECT
  - DOMAIN-SUFFIX,ads.example,REJECT
  - GEOIP,TW,DIRECT
  - MATCH,AUTO-BEST

重點是最後一欄名稱必須存在。若你寫 MATCH,AUTO-BEST，就一定要有一個叫 AUTO-BEST 的策略組或代理。許多範本把境外流量丟到名為 Proxy 的組，但你實際檔案裡若叫 🚀 手動選擇，就會對不上。另記：REJECT 與廣告規則常放在較前位置，避免先被寬鬆的代理規則接走。

想深入規則排序與 Rule Provider 維護，請延伸閱讀 規則分流最佳實踐。訂閱更新與節點汰換節奏則可對照 訂閱與節點維護指南。

load-balance 與「自動」的常見誤解

load-balance 關注的是負載均衡：把連線分散到多個節點，以降低單點壓力。它不保證每一條連線都走延遲最低的那個，也不等於「智慧選最快」。若你的訴求是瀏覽網頁體感順，通常仍以 url-test 或精簡的 select 更直觀。只有在你明確希望多線程下載、大量并行連線時，才值得評估 load-balance 的取捨與相容性。

踩雷點與建議除錯順序

  1. 規則沒指到自動組：MATCH 仍指向手動 select，導致怎麼測速都不影響主流量。
  2. 嵌套過深或名稱循環：策略組 A 的成員包含組 B，B 又指回 A，可能造成無法預期的解析錯誤。
  3. 測速全紅：優先檢查測速 URL 是否被 ISP、公司防火牆或另一層代理攔截。
  4. 訂閱與本地覆寫打架：GUI「覆寫」與實際 YAML 不同步；應以核心載入後的設定為準。
  5. 把 UDP 體感誤判成 HTTP 測速問題：遊戲、即時通話對 UDP 路徑敏感，HTTP 延遲低不代表 UDP 也好；可對照本站 Steam／UDP 與 TUN 專文的思路分層排查。
⚠ 合規提示：請在合法授權的網路環境下使用 Clash，並遵守在地法規與服務條款。本文僅說明技術設定，不鼓勵規避合規管控。

自檢清單

  1. 在連線日誌確認：目標網域命中規則與策略組名稱是否與預期一致。
  2. 打開該策略組定義，核對 type 是否為 url-test 或 fallback，而不是誤用手動 select。
  3. 檢查 proxies 列表是否仍含有效節點；訂閱更新後是否出現空白或重名。
  4. 調整 interval、tolerance、url 其中一項並觀察 5～10 分鐘，避免同時改太多變數。
  5. 確認沒有循環代理：本機 Clash 出口又指回自己，導致健康檢查失真。
  6. 若使用 TUN，確認系統路由沒有與其他 VPN 互相覆蓋；必要時參考 TUN 模式深度解析。

結語

讓 自動選節點與主備切換真正生效，關鍵不在多裝幾個外掛皮膚，而是三件事：規則有沒有把流量交給對的組、該組的 type 是否與你的意圖一致、以及健康檢查參數是否與實際網路環境匹配。url-test 與 fallback 解決的是不同問題：前者偏「在同級候選裡挑快的」，後者偏「按優先級找第一個可用的」。把這層關係寫進自己的設定註解，幾個月後回頭維護也不會迷失。

相較於手動在長列表裡試節點，一套結構清楚的核心搭配能呈現命中規則與測速狀態的客戶端，通常能把試錯成本壓低；這也是許多使用者從「能連就好」走向「可解釋、可驗證」的分水嶺。

→ 立即免費下載 Clash，開啟流暢上網新體驗，用可讀的規則與策略組，把時間花在真正要上網的內容，而不是猜測當下到底命中哪一個出口。