url-test、fallback、load-balance 有什麼差異：策略組類型選擇指南

先看結論：三種策略組解決的不是同一個問題

Clash 與 Mihomo 設定中的策略組，不只是「把多個節點放進同一份清單」。組類型會決定客戶端如何探測節點、選擇出口，以及節點狀態變化後是否切換。url-test 追求目前探測延遲較低的節點，fallback 依設定順序尋找第一個可用節點，load-balance 則將不同連線分配給多個可用節點。

最常見的誤解，是把三者都視為自動選出最佳節點。實際上，最低延遲、最高優先順序與分散連線是三套不同的判斷標準。一個延遲 62ms 的節點可能被 url-test 選中，卻不一定會被 fallback 使用；下載工作經過 load-balance 後，也不會自動把同一條 TCP 連線拆成三份來疊加頻寬。

類型	核心判斷	切換條件	典型用途
`url-test`	探測結果中延遲較低的節點	重新測試後出現明顯更佳的節點，或目前節點無法使用	網頁瀏覽、API 請求、日常預設出口
`fallback`	清單中第一個通過健康檢查的節點	高優先順序節點失效或恢復	固定主要線路、備援線路、穩定地區出口
`load-balance`	依策略將連線分配給多個可用節點	建立新連線或節點健康狀態變化	多連線下載、並行請求、分散出口負載

url-test：定期探測並選擇低延遲節點

url-test 會讓組內節點存取同一個測試網址，記錄建立連線及取得回應所需的時間，接著選擇探測結果較佳的節點。它適合節點品質經常波動、希望減少手動切換的情境。測試結果反映的是客戶端經由節點前往測試目標的一次小型請求，不等同於尖峰時段的下載速度，也無法完整代表串流影音的跨網路品質。

基本設定與參數說明

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies:
      - 香港-01
      - 香港-02
      - 新加坡-01
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

url 是健康檢查目標。回應內容應小、服務應穩定，並且能透過代理存取。範例網址正常回應時會回傳 204，適合減少測試流量。
interval: 300 表示每 300 秒安排一次週期檢查，也就是 5 分鐘。它不是毫秒，也不是每次開啟網頁都重新測速。
tolerance: 80 表示延遲差不超過 80ms 時，通常保留目前節點，避免在 70ms 與 76ms 之間頻繁來回切換。
lazy: true 用於減少長時間未使用策略組的主動檢查。實際排程行為取決於核心版本，使用該組時仍會依健康狀態運作。

為什麼 tolerance 不該一律設為 0

假設一次測試得到香港-01 為 68ms、香港-02 為 75ms。若容差為 0，幾毫秒的網路抖動就可能改變結果；下一輪出現 79ms 與 72ms 時，策略組又可能切回香港-02。既有的 TCP 連線通常不會因此無縫遷移，但新連線會改走另一個出口，登入網站也可能觀察到 IP 變化。

家庭寬頻可先從 50～100ms 試起。節點都在同一地區且延遲接近時，80ms 是較穩定的起點；節點橫跨亞洲、歐洲與北美時，可將不同地區拆分成不同組別，避免單純依延遲把所有流量壓到最近地區。若確實需要快速追隨低延遲線路，可將 interval 設為 120～300 秒、tolerance 設為 30～50ms，但測試頻率越高，節點與測試站收到的探測請求也越多。

一次實際讀數該如何解讀

在 500Mbps 家庭寬頻的一組重複測試中，三個節點對 204 網址的中位延遲分別為 61ms、88ms、142ms，抖動範圍約為 9ms、34ms、18ms。url-test 會傾向選擇 61ms 的節點，但第二個節點在大型檔案下載時可能仍有更高吞吐量。選擇網頁預設出口時可以參考低延遲；選擇下載出口時，還應觀察 100MB 以上檔案的持續速度、封包遺失與尖峰時段表現。

fallback：依優先順序使用第一個可用節點

fallback 的重點是順序，而不是從所有可用節點中挑選延遲最低者。清單第一項是主要線路，第二項是第一備援，第三項是第二備援。只要第一項通過健康檢查，即使它的延遲為 160ms、第二項只有 55ms，該組仍會優先使用第一項。這種可預期的行為適合需要固定地區、固定電信商或固定出口身分的服務。

proxy-groups:
  - name: 主備線路
    type: fallback
    proxies:
      - 香港-專線
      - 香港-備援
      - 新加坡-備援
    url: https://cp.cloudflare.com/generate_204
    interval: 180
    lazy: false

何時會觸發故障轉移

核心會依健康檢查判斷目前高優先順序節點是否可用。主要節點連續無法完成探測後，新連線會轉向後方的可用節點。主要節點恢復並重新通過檢查後，策略組可以回到優先順序較高的節點。切換不保證正在進行的影片、SSH 工作階段或下載連線不中斷，因為原連線對應的出口與路徑已經失效。

interval: 180 代表一般檢查間隔為 3 分鐘，因此不是毫秒級熱備。實際發現故障的時間還會受到按需探測、逾時設定與核心排程影響。若服務要求更快發現故障，可將間隔降至 60～120 秒，但也要接受更多探測流量。一般家庭使用設定為 180～300 秒，通常能在回應速度與檢查成本之間取得平衡。

節點順序應該如何排列

先放地區、出口身分與可用性最符合服務需求的主要節點。
第二項選擇同一地區但不同伺服器或不同線路的節點，降低網站地區辨識變化。
最後再放跨地區備援節點，確保同地區線路整體故障時仍有出口。
不要只依某次延遲截圖排序；至少觀察平日晚間 20:00～23:00 的穩定性。

串流影音是 fallback 的常見用途。例如主要節點已確認能存取目標片庫，備援節點也位於相同地區，那麼故障切換時仍能維持地區一致。相較之下，將多個國家的節點放入 url-test，可能因延遲變化讓下一次連線切換到另一個地區，導致內容目錄或登入風控發生變化。

load-balance：分配連線，不是疊加單一連線頻寬

load-balance 會在多個健康節點之間分配連線。開啟網頁時通常會同時請求 HTML、指令碼、圖片與 API，這些請求可能被分配到不同節點；支援分段與多執行緒的下載器也可能建立多條連線，因此能利用多個出口。不過，一條已建立的 TCP 或 QUIC 連線通常仍由單一節點承載，無法把三個 100Mbps 節點自動合併成一條 300Mbps 的單一連線。

proxy-groups:
  - name: 並行下載
    type: load-balance
    proxies:
      - 下載節點-01
      - 下載節點-02
      - 下載節點-03
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    strategy: consistent-hashing

consistent-hashing 與 round-robin

Mihomo 中常見的負載策略包括 consistent-hashing 與 round-robin。一致性雜湊會依據目標等資訊，讓相近請求穩定映射到特定節點，減少同一網站在短時間內反覆更換出口 IP；輪詢則更直接，依序將新連線分配給可用節點，分布較平均，但對要求工作階段出口穩定的網站不太友善。

負載策略	連線分布	出口穩定性	適用情境
`consistent-hashing`	相同目標傾向映射到固定節點	相對穩定	網頁資源、API、需要降低 IP 跳變的並行存取
`round-robin`	新連線依序輪換節點	較容易變動	多來源下載、批次工作、對出口身分不敏感的並行請求

設定欄位應以目前 Mihomo 版本的支援狀況為準。部分舊核心沒有相同的 strategy 值，客戶端也可能在匯入時忽略未知欄位。修改後可進入客戶端的「設定」→「日誌」，將日誌等級暫時調為 debug，重新載入設定並檢查是否出現設定解析錯誤；確認正常後再恢復為 info，避免長期產生大量日誌。

為什麼登入、付款與串流影音不適合直接輪詢

部分服務會將工作階段與出口 IP、地區或風險評分關聯。登入頁面由節點 A 開啟，後續 API 由節點 B 請求，可能觸發重複驗證或工作階段失效。影片播放也可能先透過節點 A 完成地區辨識，分段內容卻從節點 B 請求，造成 403、重新驗證或畫質下降。這類流量更適合一致性雜湊、單節點選擇組，或單獨使用固定地區的 fallback。

interval、tolerance 與健康檢查如何配合

interval 控制週期檢查的大致間隔，單位通常為秒。數值越小，狀態更新越即時，但會增加探測請求。300 秒表示每個參與檢查的節點約每 5 分鐘存取一次測試網址；包含 20 個節點的組別，理論上每輪會產生約 20 次探測。若訂閱中有 100 個節點，又建立多個重複檢查組，就沒有必要把間隔壓到 30 秒。

tolerance 主要用於維持 url-test 的切換穩定性。它不是逾時值，也不會讓節點「多等 80ms」。設定為 80 的意思是，候選節點必須展現足夠明顯的延遲優勢，才值得取代目前節點。fallback 看的是順序與可用狀態，load-balance 看的是連線分配，因此通常不依靠 tolerance 決定主要邏輯。

三種實用參數起點

日常瀏覽：interval: 300、tolerance: 80，優先減少頻繁切換。
網路波動明顯：interval: 180、tolerance: 50，更快發現線路變化。
固定主備出口：使用 fallback，interval: 180，節點依服務優先順序排列。
大量並行下載：使用 load-balance，interval: 300，先排除吞吐量明顯偏低的節點。

測試網址也會影響結論。選擇距離過遠的目標，測到的主要是節點到目標網站的跨境路徑；選擇只有部分節點能存取的目標，又會把正常節點誤判為失敗。可以使用穩定的 204 服務作為通用檢查，再針對特定服務個別驗證。不要把下載大型檔案當作每幾分鐘執行一次的健康檢查，否則會持續占用流量與伺服器頻寬。

依情境搭配：日常瀏覽、串流影音與下載

日常瀏覽：url-test 搭配手動選擇

日常網頁與即時通訊通常更重視回應速度，可建立一個 url-test 自動組，再用 select 將自動組與常用單一節點組合。如此預設會使用自動測試結果，遇到網站風控或特定節點存取異常時，也能在客戶端的「代理」→「節點選擇」中手動固定出口。

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies:
      - 香港-01
      - 香港-02
      - 新加坡-01
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 80

  - name: 日常代理
    type: select
    proxies:
      - 自動選擇
      - 香港-01
      - 新加坡-01
      - DIRECT

串流影音：同地區 fallback

先依服務可用地區篩選節點，再建立同地區的 fallback。主要節點放入已驗證播放穩定、尖峰時段吞吐量足夠的線路，備援節點則放入同地區的另一台伺服器。在規則中將目標服務網域或對應規則集指向該組。重點不是追求最低的 204 延遲，而是維持地區一致，並在主要線路故障時切換。

多執行緒下載：品質相近的 load-balance

若下載器設定 8 或 16 個並行連線，負載組才有機會將不同連線分配給多個節點。瀏覽器單一連線下載、只建立一條連線的物件儲存請求，通常仍受單一節點上限限制。使用前還要確認訂閱服務的流量規則是否允許並行，以及不同出口存取同一個下載網址是否會導致臨時連結失效。

將策略組套用到規則

rules:
  - DOMAIN-SUFFIX,example-video.com,串流影音主備
  - DOMAIN-SUFFIX,example-download.com,並行下載
  - MATCH,日常代理

規則會由上到下比對，命中後便停止繼續尋找。具體服務往往涉及多個網域，只加入首頁網域可能漏掉影片分段、圖片 CDN 或登入 API。使用規則集時，應檢查其更新來源與實際內容；修改後在客戶端的「連線」頁面查看目標網域最後命中了哪條規則、使用了哪個策略組，比只確認瀏覽器能否開啟更準確。

常見設定錯誤與排查順序

所有節點都顯示 timeout

使用瀏覽器或命令列確認測試網址本身可以存取。
檢查 DNS 是否解析成功，以及日誌中是否出現 dns resolve failed。
將測試網址換成另一個穩定、回應內容較小的目標，重新執行延遲測試。
確認節點名稱與 proxies 清單完全一致，包括空格、大小寫與符號。
檢查訂閱更新後節點是否改名，導致策略組仍引用舊名稱。

url-test 頻繁切換節點

先將 tolerance 從 0 或 10 調高至 50～100，再將 interval 從 30 秒放寬至 180～300 秒。如果節點跨地區混放，應依地區拆分組別。也可以連續測試 10 次，記錄中位數與波動範圍；平均延遲低但波動超過 100ms 的節點，不一定比穩定在 90ms 的節點更適合作為預設出口。

fallback 沒有選擇延遲最低的節點

這是預期行為。fallback 會選擇清單中第一個可用節點，不會比較哪個更快。若想自動選擇低延遲節點，應改用 url-test；若希望固定使用主要節點、只有故障時才切換，就保留 fallback 並調整節點順序。

load-balance 後下載速度沒有提升

先確認下載工具是否真的建立了多條連線，再在客戶端的「連線」頁面觀察各連線使用的鏈路。如果只有一條連線，速度上限仍取決於單一節點。若連線很多但都指向同一個目標，一致性雜湊可能讓它們穩定落在同一節點；切換到輪詢前，應評估下載站是否允許出口 IP 變動。即使連線平均分配，來源站限速、本地頻寬與節點共用頻寬仍可能成為瓶頸。

最終選擇：先釐清服務目標，再選策略組類型

需要「誰回應快就用誰」，選 url-test；需要「主要線路不可用才啟用備援」，選 fallback；需要「讓多條並行連線分散到不同節點」，選 load-balance。三者沒有絕對優劣，關鍵在於判斷標準是否符合服務需求。

實用設定通常會同時使用多種組別：日常預設出口使用 url-test，固定地區服務使用 fallback，並行下載則獨立使用 load-balance，最外層再用 select 提供手動覆寫。搭配從具體網域到 MATCH 的規則順序，就能讓各類流量進入合適的策略組，而不是讓一個自動組承擔所有需求。