先釐清：負載均衡在做什麼，和 url-test 差在哪？
url-test 的核心是「對候選節點做探測，傾向選延遲表現較佳的那個」；load-balance 則是「在候選節點間分配連線」，目標不一定是挑最低延遲，而是分散或依目的地做可重現的指派。因此兩者常並存：例如外層仍用 url-test 先確保池子裡多半是「當下可用且不算慢」的節點，內層或另一條規則再用 load-balance 把長連線或大量並行連線攤開；或反過來，只在特定域名策略組上使用 consistent-hashing，其餘流量維持自動測速。
round-robin 偏向輪流派發：新連線依序輪換使用清單中的節點，適合想降低「所有人都擠在同一節點」時的尖峰，但要接受目標站可能觀察到多個出口 IP。consistent-hashing 則以雜湊把「某個連線特徵」對應到固定候選上，實務上常被說成連線級的粘滯：有助於同一服務端點盡量落在同一節點，但不是應用層 Session 的完整保證——若訂閱把節點順序或數量改掉，雜湊環路可能重算，粘滯會變動；HTTP／3、多路徑 Retry、短連線暴增時體感也會不同。
何時用輪詢，何時用 consistent-hashing？
若您的主要痛點是「單節點容易被打滿／晚高峰排隊」，且目標服務不要求長時間固定出口（例如靜態下載、只讀 API），round-robin 較直覺。若痛點是「同一網站頻繁跳出驗證、或長連線中途被視為換 IP」，可先試 consistent-hashing，並搭配 規則順序 讓該域名穩定命中同一策略組。若您同時需要不健康節點自動剔除，仍應回到 url-test／fallback 或拆出獨立池，不要把 load-balance 誤當成全自動延遲最佳化。
1設定 round-robin：輪詢分散新連線
在 proxy-groups 新增一組，type 設為 load-balance，strategy 設為 round-robin。proxies 內僅能引用已存在的節點名稱（或不含循環依賴的其他策略組）。撰寫完優先做一次設定重載，確認沒有「找不到名稱」或「策略組循環」錯誤。
# Snippet — round-robin; replace proxy names with yours
proxy-groups:
- name: LB-RR
type: load-balance
strategy: round-robin
proxies:
- NODE-A
- NODE-B
- NODE-C小結：輪詢改善的是連線層分散；並不幫您挑「全球最快」節點，也未必彌補單一節點頻寬瓶頸。
2設定 consistent-hashing：連線級粘滯語意
將同一組的 strategy 改為 consistent-hashing 即為常見的「粘滯」用法：核心會依內部演算法把連線映射到較固定的候選上，讓同一目標較容易反覆落在同一節點。這對部分銀行／大型站台的風控較友善，但請記住：若您只有兩三個節點又頻繁汰換，或訂閱每次更新都打亂名稱，體感仍可能像「一直換線」。運維上建議搭配穩定命名的 proxy-providers 或固定手寫別名，並在更新後驗收。
# Snippet — consistent hashing pool
proxy-groups:
- name: LB-STICKY
type: load-balance
strategy: consistent-hashing
proxies:
- NODE-A
- NODE-B
- NODE-C少數場景會與 relay 鏈路 疊加：鏈路越長，除錯時越要講究「每一跳是否支援實際協議」。若 UDP／語音異常，先單獨測節點與規則命中，再掛負載均衡，避免一次改太多變因。
3規則接到策略組：名稱對了才算數
與 url-test 相同：rules 最後一欄必須是策略組名（例如 LB-STICKY），不是訂閱內的原始節點字串。Clash 系規則由上而下先命中先贏；若 GEOIP 或寬鬆規則在前面把流量拉走，後面的負載均衡組不會生效。整理規則時可對照 規則順序與 MATCH 一文。
rules:
- DOMAIN-SUFFIX,corp.internal,DIRECT
- GEOIP,CN,DIRECT
- DOMAIN-SUFFIX,example.com,LB-STICKY
- MATCH,PROXY與外層 select／url-test 並存：常見接線
實務上常在 select 裡並列「手動節點」「url-test 自動池」「load-balance 池」，讓日常使用可切換；或讓 MATCH 指到外層 PROXY，由使用者在面板選 LB-RR。關鍵仍是：實際命中的那條規則，最終要能把封包送到您預期的策略組。圖形客戶端若保留舊的 GLOBAL 選擇，也可能蓋過 YAML 預設；請用連線日誌核對策略名稱。
proxy-groups:
- name: LB-RR
type: load-balance
strategy: round-robin
proxies:
- NODE-A
- NODE-B
- name: PROXY
type: select
proxies:
- LB-RR
- NODE-A
- DIRECT常見踩坑（與排除順序）
- 訂閱改名或洗牌：
proxies清單順序一變，consistent-hashing映射跟著變；長連線仍可能維持舊節點，新連線卻換出口，風控仍可能跳。 - 把不同用途節點混池：例如僅支援 TCP 的線與強 UDP 線在同一
load-balance，輪詢後應用隨機踩雷；應按協議／地區拆池。 - 以為能取代健康檢查：
load-balance預設語意是分配；懶得探測的壞節點仍可能被取中。要自動剔除請用url-test／fallback或手動維護清單。 - UDP／QUIC 體感：部分遊戲、語音或 HTTP／3 路徑對 NAT 與出口敏感；若輪詢造成斷斷續續，先改單節點或改
consistent-hashing，再談負載分散。 - 循環依賴：
LB-A引用LB-B、LB-B又引用LB-A會載入失敗；巢狀時畫出依賴圖較保險。
提醒：代理設定須符合所在地法規與服務條款；教學僅供合法合規的網路除錯與自用學習。
可併入現有設定的最小範例
下列片段示範兩個負載池並列，並讓最外層 select 可切換；註解使用英文以利部分解析器相容。請替換 REPLACE-* 為實際節點名，並與既有 dns、tun 合併調整。
# Minimal pattern — merge with your proxies / dns / tun
mode: rule
log-level: info
proxy-groups:
- name: LB-ROUND-ROBIN
type: load-balance
strategy: round-robin
proxies:
- REPLACE-A
- REPLACE-B
- REPLACE-C
- name: LB-CONSISTENT
type: load-balance
strategy: consistent-hashing
proxies:
- REPLACE-A
- REPLACE-B
- REPLACE-C
- name: PROXY
type: select
proxies:
- LB-CONSISTENT
- LB-ROUND-ROBIN
- REPLACE-A
- DIRECT
rules:
- MATCH,PROXY
若您希望「大部分自動測速、少數域名粘滯」，可把 MATCH 指到 url-test 組，並在前列為敏感域名加 DOMAIN-SUFFIX 到 LB-CONSISTENT；細部健康檢查參數仍以 該篇 為主。
開源資訊與安裝包取得方式
Mihomo 上游以開源方式維護，查核版本行為或提交 Issue 時適合前往公開程式庫。日常下載或更新圖形客戶端，建議優先使用 本站 Clash 下載頁，並搭配 設定說明文件；將「取得安裝包」與「閱讀原始碼」分開，可避免誤以為必須自行從 Release 頁拼裝環境。
結語
load-balance 讓 Clash Meta／Mihomo 有機會在多節點間做連線級分散：round-robin 求輪換，consistent-hashing 求對同一目的地的可重現指派。兩者都不能取代針對延遲與可用性的 url-test／fallback，而是常與之分工。把 rules 命中與策略組命名一次對齊，再用日誌確認「第一條規則→實際策略名」無誤，通常比盲目加節點更有效。
相較於只靠手動切換或訂閱預設排序，顯式寫出負載池可以長期與 relay、GEOIP、DNS 政策並存；遇到 HTTPS 只有 IP、域名規則不觸發時，再串接 Sniffer 與 DNS 相關文章即可，但策略組命名與順序永遠是第一道關卡。
相較於其他同類工具，Clash 系在「規則、策略組、日誌」之間的對照較一致，對要同時處理自動測速與多節點分攤的使用者較友善。完成上述負載設定後，建議保留一小段觀察期：訂閱更新前後各驗收一次粘滯是否符合預期。