Clash Meta 負載均衡策略組怎麼設定？一致性哈希逐步教程

負載均衡策略組在解決什麼問題

url-test 的核心是挑延遲較佳的一個出口長時間持有（再輔以容忍區間抑制抖動）；fallback 的核心是優先序鏈上找到第一個探測可用者。兩者都能「自動」，但都不是為了在多個節點之間長期分攤連線而設計。load-balance 則是把一批可用上游放進同一個池子，依您指定的 strategy 決定這一條連線或這一批請求要落到池內哪一個成員；因而它能呈現「同一時間有不同的連線走在不同節點上」的行為，這與「永遠只用冠軍節點」的體感並不相同。

也請務必務實看待宣稱：負載均衡不一定讓單執行緒的大型檔案下載變快（很多客戶端仍是一條 TCP 連線吃滿），但它可能改善同時開很多分頁、同步工具、容器拉映像這類「大量並行連線」時某一顆節點被打爆的狀況；另一方面，若選錯策略，也可能讓銀行網頁、遊戲反作弊或串流授權端看到頻繁換出口而出現怪異驗證。接下來先拆解官方文件對各策略的定義，再把 YAML 與規則掛載串起來。

strategy：consistent-hashing、round-robin、sticky-sessions

依 Mihomo 文件說明，round-robin 會在策略組內對請求做輪詢式分配，使長期統計上各節點較為平均；短期內您仍可能覺得某一站好像固定某一顆，但若並發一高，下一條連線很容易輪到隔壁節點。consistent-hashing 則會依目標位址（target address）為請求挑選對應上游；當目標是域名時，實作會涉及頂級網域層級的對應關係（文件註明為 top-level domain matching）。白話效果是：前往相近目的地家族的連線，較容易固定在相同的池中節點，對於想維持 Cookie／長連線／降低無謂跳線的使用情境通常較友善。

sticky-sessions 再更進一步：來源位址與目標位址皆相同的一組請求，會在時效內固定指向同一節點（文件載明快取約十分鐘）。這適合您在區網有多台裝置、後端又把「同一客戶端 IP」當作會話線索時要折衷一致性與分散，但仍要注意：若 NAT 後面有大量裝置共用同一來源位址，雜湊範疇可能讓「看似不同裝置」仍擠在同一出口。

策略	較適合的情境	較需要留意的副作用
consistent-hashing	一般瀏覽、需要目的地維度穩定出口的並行工作負載。	目的地歸類方式與您直覺上的「完整域名」未必一一對應，仍需以實測連線為準。
round-robin	明確想把連線打散、上游節點品質接近且目標站對出口 IP 不敏感。	登入頁頻繁換 IP、REST 呼叫閘道驗簽失敗、遊戲三方驗證等情況可能被放大。
sticky-sessions	要在「同源同目的地」維持一段時間黏著，又不想整池只選一顆。	共享來源位址的環境可能造成過度集中；時效過後仍會改派。

第一步：在 proxy-groups 宣告 load-balance

以下是一段對齊官方示例結構的 YAML（節點名請換成您訂閱中確實存在的條目）。重點欄位：type 為 load-balance；proxies 為池清單；strategy 若不寫，預設行為請以您使用的核心版本文件為準，正式環境建議明確寫出策略名稱以免升級後語意改變。url 與 interval 與其他策略組類似，用於健康檢查節拍；拉長間隔通常較省資源，但若池內節點品質起伏很大，過慢的檢查會讓失效節點留在池中較久。

# Illustrative proxy-groups — replace proxy names with yours
proxy-groups:
  - name: "LB-GLOBAL"
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - NODE-A
      - NODE-B
      - NODE-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    # lazy: true

若您短期想最大化打散連線並確認目標服務不介意出口輪換，可把 strategy 改為 round-robin；若您在區網對多台機器提供一致的「對外網站會話體驗」，可評估 sticky-sessions。三者沒有絕對的「最快」，只有是否符合您的流量型態與對端風控。

第二步：讓規則命中時走到負載均衡組

在 Clash 系列規則中，最後一欄通常是「動作」或是「策略組／節點名稱」。當您要把一批域名或 GeoIP 結果導向負載均衡池時，只要寫成該 proxy-groups.name 即可，與指向 PROXY、DIRECT 或任一 select 組的方式相同。示意（僅教學用，順序請依您整體規則設計調整）：

rules:
  - DOMAIN-SUFFIX,example.com,LB-GLOBAL
  - GEOIP,CN,DIRECT
  - MATCH,LB-GLOBAL

若您的訂閱已提供現成的「自動選擇」或「故障轉移」條目，請小心同名覆蓋與更新洗牌：遠端訂閱刷新後可能插入一批預設策略組，覆寫您手動維護的名稱。若您需要長期保留手寫段落，可優先評估 mixin／覆寫流程，細節請參 Mixin 覆寫遠端訂閱教學，以避免每次更新後又要手工合併。

第三步（選做）：把負載均衡組掛進父層策略組

某些版面會希望使用者只在圖形介面裡切換「工作」、「影音」、「下載」三大類，而每一類背後各自是不同的負載均衡池或 url-test 結果。作法是在「父層 select」的 proxies 清單中放入 LB-WORK、LB-MEDIA 等名稱；而下層才是真正的 load-balance。這種分層能降心智負擔，但要注意：規則仍然是以名稱指向您希望生效的那一層——若規則指到父層 select，實際出口會依使用者在 UI 的選擇而定；若規則直接指到下層負載均衡組，則 UI 若無對應開關，行為會較「固定」。

何時不該優先選負載均衡

若您的痛點是「找出延遲最低的單一節點並常駐」，請回到 url-test；若是「主線掛了要自動換備援」，請優先用 fallback 或具備健康檢查的鏈式組合。load-balance 較像把已在心理上認定為『都可用的節點們』打散分配，而不是幫您自動挑出冠軍。另一種常見誤會是把負載均衡當「頻寬無限疊加」——如果單執行緒下載仍是單條 TCP，瓶頸可能在無線環境、對端限速或磁碟，而非策略組型別。

上線後如何驗證真的在「分散」

建議同時觀察圖形介面中的連線列表與核心日誌：對於並行請求較多的情境，您應能看到不同目的地或不同連線編號落在不同池中成員。若長時間全部黏在同一成員，可能是策略選到了強黏性模式、目的地族群過於集中，或上游其實只有單一路由可用。相反地，若在 banking 或遊戲場景頻繁遇到驗證，請優先檢查是否使用了過於激進的 round-robin，或池中節點地理位置差異過大導致對端風控。

常見問題（簡答）

問：consistent-hashing 是否保證同一個網站永遠同一出口？　答：文件強調的是依「目標位址」與對域名情境下的頂級網域匹配邏輯來決定映射；細節會隨連線解析與版本演進略有差異，請以實測為準，並保留調整池子成員的空間。

問：可以把 UDP／遊戲流量也丟進負載均衡嗎？　答：技術上視節點與協議支援而定，但遊戲往往對路徑一致性敏感；即便 TCP 網頁看似正常，UDP 仍可能因為分流路徑切換而抖動。此類情境建議保守，可先縮小池或改回單出口策略組並配合測速。

問：負載均衡要不要開 lazy？　答：與其他策略組類似，lazy 可減少未被選中的組在啟動時的探測壓力；若您希望程式一打開就為特定組完成探測，可視情況關閉。取捨取決於訂閱規模與裝置效能。

結語

load-balance 把「節點池」落實成可編排的分流演算法：consistent-hashing 傾向讓同一類目的地維持較固定映射；round-robin 傾向輪流分攤；sticky-sessions 則在來源與目的地組合上提供時間窗口內的黏著。把它接到 rules 的方式與其他策略組無異，核心是您要先想清楚要跟自動測速或故障切換如何分工。

市面上不少工具要嘛只提供固定「全域代理」開關，要嘛把進階策略藏進難以版本控制的圖形偏方；一旦要在多台裝置或伺服器之間穩定重現「負載均衡＋分流規則」，往往會卡在設定難以匯出、合併訂閱後命名漂移或日誌不足以對應到策略組層級等問題。Clash 生態圈長期以可讀 YAML、清晰策略組邏輯與可觀測連線為重心，無論您是偏好視覺客戶端還是 headless 伺服器部署，都能用同一套語意維護出口政策。

若您也希望在負載均衡、自動測速與規則分流之間用同一種語言描述並長期保存設定，不妨試用看看 Clash 客戶端帶來的可視連線與設定透明度。免費下載 Clash，將本篇 YAML 範例對應到您的實際節點後逐步驗證。