1 負載均衡解決的不是「誰延遲最低」
url-test 類型的策略組會對清單內節點做延遲測試，挑出當下 ping 起來最漂亮的那條線當唯一出口，適合「我只想自動選快線」的情境。相對地，load-balance 的目標是把連線／請求分散到多個節點上，偏向「頻寬與連線數分攤」與「避免單點塞爆」，並不保證永遠走延遲最低的那一個。兩者可以並存於不同策略組：例如一般網頁仍用 url-test 自動選優，下載或大量平行連線另走 load-balance。若您還在釐清 url-test 與 fallback，可先讀站內 url-test／fallback 專文，再回來對照本文。
在 Clash Meta 核心家族（含 Mihomo）裡，type: load-balance 通常還會搭配 url 與 interval 做健康檢查：節點若長時間對測速網址失敗，可能從輪詢或雜湊池中暫時剔除（實際行為依版本為準，升級核心後請以官方文件為準）。因此「負載均衡」並不是完全不管節點死活，而是在健康的候選之間做分配。
2 strategy：round-robin、consistent-hashing、sticky-sessions
官方文件將三種策略分得很清楚。round-robin 會在策略組內輪流分配連線到不同節點，最「平均」，但同一個目標網站的不同連線可能落到不同出口，最容易讓使用者感覺「怎麼一直換 IP」。
consistent-hashing 則依目標位址（target address）計算雜湊，把相同目標的連線導向同一個節點。白話說：對同一個 IP／主機的大量連線，較容易穩定從同一條代理出去，有助降低因 IP 跳動造成的登入驗證、風控或行為異常提示。文件特別提醒：當目標是網域名稱時，會以頂級網域層級做匹配——這會影響您對「同一站」的直覺，子網域可能被視為同一桶雜湊空間，細節請以實際核心版本說明為準。
sticky-sessions 則更進一步：相同來源位址與目標位址的組合會導向同一節點，並帶有約十分鐘的快取過期語意（文件描述）。若您有多裝置、區網內多客戶端同時上同一站，且希望「每台裝置各自黏在一條線上」，這個策略比單純 consistent-hashing 更貼近「會話」一詞的日常想像，但仍屬傳輸層／連線調度，不是瀏覽器 Cookie 層級的保證。
3 YAML 範例：load-balance 與健康檢查
下列範例示範 proxy-groups 中宣告 type: load-balance、列出多個節點名稱（請替換成您訂閱展開後的實際名稱），並設定 strategy: consistent-hashing。url 與 interval 沿用常見的健康檢查慣例；若您使用 proxy-providers，仍要確認此處字串與展開後節點名完全一致。訂閱格式若需轉換，可參考訂閱轉換與 YAML一文銜接。
# Example — replace proxy names with your subscription names
proxy-groups:
- name: LB-CONSISTENT
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，則改為對應字串（請以您核心版本文件所列枚舉為準）。lazy: true 可減少未被規則命中前的背景測試，與 url-test 段落的概念相近，是否啟用視您對「首次連線等待」與省電的取捨而定。
規則如何指向策略組
寫好群組名稱（上例為 LB-CONSISTENT）後，在 rules 內把需要分攤的流量指到該名稱即可，例如尾端 MATCH,LB-CONSISTENT，或依域名／規則集分流。請確認 mode: rule 時規則才會依序生效；若誤用 global，會以為負載均衡「沒作用」。自訂片段若需與訂閱產生檔合併，可搭配mixin 與訂閱覆寫，避免更新訂閱時覆蓋掉手改區塊。
4 「會話保持」在核心裡代表什麼、不代表什麼
搜尋「會話保持」時，許多人期待的是網站登入後永遠同一個 IP、或長時間下載不切線。在 Clash 系核心裡，consistent-hashing 與 sticky-sessions 處理的是連線如何映射到節點：在節點集合與雜湊演算法不變的前提下，對相同目標（與策略要求下可能的來源）傾向走同一出口。它不是應用程式層的「登入狀態保證」：若網站以 Cookie、裝置指紋或額外驗證控管，仍可能出現互斥行為。
另一個常見誤解是：節點清單新增、刪除或改名後，雜湊空間會改變，部分連線可能改映射到另一節點，體感像「突然斷會話」。維護時請盡量穩定節點名稱與順序，或在離峰時更新訂閱，並預期需要重新建立長連線的服務（例如部分即時通訊或金融風控較嚴的站）可能要求重新驗證。
把 consistent-hashing 想成「在一組健康代理之間，盡量讓同一目標長得像走同一條線」，而不是魔法般的全局 IP 鎖定。
5 多訂閱、雙機場：節點怎麼放進同一個 load-balance
實務上，您可能同時有兩套機場或一個自建節點加一個商業訂閱。只要這些節點在 proxies 區塊或提供者展開後各有唯一名稱，就可以全部列進同一個 load-balance 的 proxies 陣列。健康檢查會對每一個候選節點進行；若某一訂閱整批不可用，該批節點在測試失敗後較不會被選中，但不表示自動幫您挑「延遲最低的那家機場」——那是 url-test 的強項。
若您希望「兩家機場先備援、同一家裡面再負載均衡」，較乾淨的作法是巢狀策略組：外層 fallback 或 url-test 選池，內層 load-balance 分散連線。YAML 可讀性與除錯會比單一巨大 load-balance 清單好得多。命名上建議用前綴區分來源，例如 PROVIDER1-HK-1，避免訂閱更新時撞名。
6 常見坑與除錯順序
- 與延遲體感衝突：開啟負載均衡後，部分連線會走非最低延遲節點，屬預期現象；若您仍以「全站最快」為目標，應回到 url-test 或調整規則分流範圍。
- 測速網址與實站路由不一致：健康檢查只驗證對
url的可連性，與您實際造訪的網站路由可能不同；若某站頻繁驗證失敗，請一併檢查 DNS、TUN／系統代理與規則順序。 - UDP／QUIC 行為：部分服務會大量走 QUIC；若您發現影音或遊戲行為與預期不符，需查核心與節點對 UDP 的支援，並與 Sniffer、DNS 設定一併排查。
- 訂閱改名導致策略組失效：與 url-test 相同，
proxies內字串必須與實際節點名稱完全一致；emoji 或前綴變動都會讓載入失敗。 - 誤把 load-balance 當下載「頻寬疊加」：多數情境是客戶端多連線分攤到不同出口，並非單一 TCP 串流自動合併頻寬；單線下載速度仍受單節點上限限制。
7 總結
load-balance 策略組與 url-test 回答的是不同問題：前者在多節點之間分配連線，後者在同一批候選裡挑延遲最佳。consistent-hashing 以目標位址做雜湊，讓同一目標盡量走同一節點；sticky-sessions 則在來源與目標組合上再加黏著時間語意。理解「連線層」與「應用登入層」的邊界後，較不會把頻繁驗證或風控問題單純怪在負載均衡上。最後請記得：節點增刪、改名與健康檢查設定都會影響實際映射，維護時保持命名穩定、規則指向正確的策略組名稱，並在升級 Mihomo 後複核官方文件。
若您需要與站內教學一致的用戶端安裝包與更新節奏，建議從本站下載頁取得對應平台版本，再把本文 YAML 片段合併進設定。相較只在圖形介面手動切換節點，先把策略組與分流規則想清楚，長期維護成本會低很多。
