Clash 策略組裡負載均衡怎麼配：load-balance 與散列選節點分步操作

1. 負載均衡解決的不是「延遲最低」這件事

url-test 的核心是：在探測結果裡找當下延遲表現較佳的節點，並在容忍範圍內維持穩定，適合日常上網「自動跟著網路品質走」。相對地，load-balance 的核心是：在你指定的一組候選節點之間，依策略把連線或工作負載拆開，降低「所有連線都堆在同一顆節點」的機率，或讓特定來源的連線可重現地落到同一顆節點上。

因此，若你的痛點是「下載器開很多 thread，結果出口只有一條線在吃頻寬」，或「內網多台裝置希望分散到不同落地，但又不要完全隨機到無法預測」，load-balance 才會進入候選；若你的痛點純粹是「想永遠自動選 ping 最低」，仍應優先檢視 url-test 的探測與 tolerance。兩者可以並存：例如一般網頁仍走自動測速組，下載域名單獨指向負載均衡組。與 url-test／fallback 的專文可交叉閱讀：Clash 策略組 url-test 與 fallback：自動測速與故障轉移怎麼配。

實作面向上，本功能依賴 Clash Meta 核心（mihomo）及其相容用戶端；若你仍在極舊、未支援 load-balance 的分支，圖形介面可能根本無法選到該類型，或匯入後被忽略。若你不確定目前核心版本，建議以用戶端關於頁或日誌啟動行為為準，再對照官方說明。

2. round-robin 與 consistent-hashing 一句話與場景

在 mihomo 的 load-balance 策略組中，常見透過 strategy（或你使用的訂閱產生器所對應的欄位）在兩種模式間切換：

• round-robin（輪詢）：傾向在候選節點之間輪流分配新建立的連線，讓多連線應用程式比較容易「攤開」到不同出口，適合下載、多執行緒同步、或你希望宏觀上別全擠單點的情境。實際粒度仍以核心實作為準，重點是意圖為「分散」而非「黏著」。
• consistent-hashing（一致散列）：依連線的來源特徵（常見為來源位址等輸入）計算雜湊，把同一來源導向同一後端節點，不同來源則分散到各節點。適合「希望同一台內網電腦盡量固定同一落地 IP」，或避免過度跳線導致目標站點把你看成頻繁換 IP；也適合你想讓多裝置之間仍有一定分散度、但單一裝置內部行為穩定的折衷。

兩種策略都不保證「商業級 L7 負載平衡器」的精細度：代理核心做的是在多個上游代理節點之間分配，實際效果仍受節點品質、連線重用、應用程式行為（是否大量短連線、是否長連線單通道）影響。把它當成「在策略組層級多一個旋鈕」，比較務實。

3. 與 url-test、fallback、select 對照

選類型時，可用「決策依據」快速分桶：select 由你手動選；url-test 由探測延遲決定單一目前節點；fallback 由順序加健康檢查決定單一目前節點；load-balance 則在多節點同時扮演角色的前提下做分配或散列。換句話說，前三者典型輸出是「當下用哪一顆」；負載均衡典型輸出是「這一組裡怎麼拆連線」。

若你同時需要「故障時別死盯壞節點」，仍應依賴策略組上的健康探測（url、interval 等）讓核心標記不可用成員；細節與欄位名請以你所用的 mihomo 版本為準。不要假設負載均衡會幫你「自動挑全世界最優節點」——那是 url-test 的戰場。

4. 分步寫 YAML：節點清單 → 策略組 → 規則

下面用「三步驟」組裝，與多數教學一致：先確保 proxies（或 proxy-providers）裡真的有你點名的節點，再建立 proxy-groups，最後在 rules 把目標流量指到該策略組名稱。若你尚未匯入訂閱，可先完成 訂閱匯入教學，再回來替換節點名稱。

4.1 建立兩種負載均衡組（輪詢與散列）

將 proxies 陣列中的字串替換成你的真實節點名稱；名稱必須與清單完全一致，否則核心載入設定時會拒絕或略過該項。

proxy-groups:
  # Spread new connections across nodes (typical for multi-connection downloads)
  - name: "LB-ROUND"
    type: load-balance
    strategy: round-robin
    proxies:
      - "節點-A"
      - "節點-B"
      - "節點-C"
    url: "http://www.gstatic.com/generate_204"
    interval: 300

  # Sticky by source hashing (same client tends to same node)
  - name: "LB-HASH"
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - "節點-A"
      - "節點-B"
      - "節點-C"
    url: "http://www.gstatic.com/generate_204"
    interval: 300

4.2 讓規則指向負載均衡組

規則寫法與其他策略組相同：在域名、進程或最後的 MATCH 行，把動作目標設成 LB-ROUND 或 LB-HASH。更完整的規則思維可對照 規則分流指南。實務上常把「大檔下載域名」或「特定應用程式」指到 LB-ROUND，把「需要出口 IP 盡量穩定」的服務指到 LB-HASH，其餘仍走你原本的 url-test 或手動組。

rules:
  # Example: send a download domain to round-robin group
  - DOMAIN-SUFFIX,example-download.com,LB-ROUND
  - MATCH,LB-HASH

上列 MATCH 僅為示意：實際部署請依你現有規則鏈插入位置調整，避免不小心把全機流量改道。建議在圖形用戶端觀察「目前連線」或日誌命中，確認策略組名稱與規則一致。

5. 探測 url／interval 與節點可用性

負載均衡組內的節點若部分失效，使用者體感會是「偶發連不上、速度起伏」——因此多數設定仍會帶 url 與 interval，讓核心週期性確認成員健康。探測目標宜選輕量、對各出口公平的位址；若某節點對該 URL 特別不通，可能被誤判為不可用，這點與 url-test 組相同。

interval 過短會增加後台與節點負擔；過長則故障切換遲鈍。一般可從數百秒級開始，再依家裡或公司網路品質微調。若你的用戶端對 expected-status 等進階欄位有支援，也可在訂閱產生器開啟對應選項，減少「HTTP 回應特殊但實際可用」的誤判。

6. 常見誤區與排查

第一，以為開了 load-balance 就會讓「單一 TCP 連線」變成多線疊加速率。單一連線仍走單一路徑；分攤發生在「多條連線」層級。若下載器只開單線程，看到的效果可能與未開負載均衡差異不大。第二，consistent-hashing 不是 VPN 級的固定公網 IP：節點池變動、訂閱改名、候選增刪會改變雜湊環，長期「像固定 IP」仍應挑選提供穩定落地的商業節點並搭配 fallback 思維。第三，規則沒指到該組：圖形介面手動選了某節點，但域名規則仍把流量送到另一個 select 組，是最常見的「設定看起來對、行為不對」原因，請用日誌與命中顯示交叉驗證。

若你從訂閱自動產生的策略組改名、合併，請同步更新自訂規則與自訂組的引用字串；訂閱更新後節點名稱變動也會讓 proxies 清單失效。養成「匯入後檢查一次設定載入是否成功」的習慣，比事後猜測策略類型更省時間。