load-balance 解決什麼問題、和 url-test 差在哪

在 Clash 系列核心裡，策略組（proxy-groups）回答的是「這條流量最終交給哪一類出站邏輯」。select 把決定權交給你在介面裡點選的那一條；url-test 週期性對探針地址測延遲，試圖讓整組長期掛在相對更快的那條上；fallback 則按列表順序做健康檢查與主備切換。與此不同，load-balance 的語義是在池內成員之間分散連接負載：適合多線程下載、併發抓包、需要把連接鋪到多條中繼上的場景，而不是「每次打開網頁都希望毫秒數第一名」的路徑優化。

許多檢索詞會直接命中「負載平衡」四個字，但心裡想的其實是自動選最快——這時更值得讀 姊妹篇中的 url-test 段落。若你把兩者混用，會出現典型錯覺：配置了 load-balance 卻在抱怨「為什麼沒有永遠走延遲最低的節點」。反向情況也同樣成立：只用 url-test 去扛超高併發上傳下載，單體節點很快被提供商限速或拒絕大量並行會話，與其期待魔法，不如正視「分散連接」與「優選 RTT」是兩種目標。

在Windows 11 桌面場景中，常見於以下動機：你希望某個「下載專用」策略組名下的流量在三條線路間鋪開；或你希望工具鏈裡大量短時 TCP 會話不要都打穿同一 POP。做到這一點的最短路徑往往不是繼續堆更貴的單線，而是在Mihomo 核心裡把那一個proxy-groups條目的 type 改成 load-balance，並選對 strategy。下文預設你已在 CfW 中啟用 Meta／Mihomo 路線且配置能被目前核心解析；若仍在極舊構建上反覆報欄位錯誤，應優先升級核心或遷移到仍在發版的客戶端殼層。

ℹ 與站內文章分工：本文只講 Clash for Windows + YAML 核心編輯器 下的 load-balance；Win11 CfW 圖形介面測速與切組幫你建立 Proxies 心智模型；url-test／fallback 專文覆蓋自動選快與主備鏈；若你要 TUN、Strict Route 與 Party 殼的菜單路徑，請另讀 Mihomo Party 系列，不在此重複截圖級操作。

動手前：Mihomo 核心、Profile 與命名衝突

打開編輯器之前，先完成三件核對。第一，Profiles 裡正在使用的那份機場配置必須處於啟用狀態，且系統匣或主視窗顯示核心已運行；否則你改的是磁碟上的文字，卻未必是記憶體裡那份。第二，確認你的 Clash for Windows 實際載入的是 Mihomo（Meta）核心——load-balance 的 strategy 行為以官方說明與對應核心版本文件為準，舊版封閉原始碼核心若直接忽略未知欄位，會在介面上表現為「保存成功但行為像普通組」。第三，給新組起一個不與訂閱自動段落衝突的名字：許多遠端配置會生成諸如 PROXY、♻️ 自動選擇 之類條目，若你本地新增同名組，輕則合併失敗，重則覆寫順序難以排查。

還要提前接受一個事實：若你的整份 config.yaml 完全由訂閱 URL 每次拉取覆蓋，那麼你在本地手寫的 proxy-groups 可能在一次「更新訂閱」後消失。長期方案通常是：把機場下發當作基礎，再用 provider 覆寫、patch、或拆出本地 include 檔案做增量合併——這部分因機場工具鏈而異，不在此展開成品牌教程，但你在排障時要優先問一句：「我改的檔案是不是下一次更新還會被衝掉？」若答案是肯定的，應先把合併策略定下來，再談負載平衡細節。

最後，準備一份節點英文別名列表：YAML 的 proxies 小節裡每個 name 必須與 proxy-groups 中 proxies 陣列引用的字符串完全一致，包含大小寫、空格與 emoji。許多新手在這裡卡住，是因為複製了介面顯示名，卻與檔案裡的 name 差了一個不可見字符。若你不確定，可在編輯器裡全文搜尋該節點在 proxies: 下的定義塊，再原樣貼到組內。

Clash for Windows：從 Profiles 進核心編輯器的順序

經典 Clash for Windows 把「當前工作配置」掛在 Profiles 分頁。實測可在該列表裡選中你的機場 profile，然後使用與編輯相關的入口（不同小版本可能顯示為編輯圖示、右鍵選單或「在資料夾中打開」旁的文字編輯）進入核心可讀的同一份 YAML。若你更習慣外部編輯器，也可以從設定目錄直接開啟對應檔案，但務必保證 CfW 保存與重載時指向的是同一路徑，避免出現「磁碟已改、介面未載」的雙份真相。

建議的操作節奏是：先備份整份 YAML（複製為帶時間戳的副本），再在 proxy-groups: 段落附近動手。編輯時保持縮進用空格、列表項前短橫線後有空格，這是避免解析失敗的基本功。改完後不要急於關窗，先執行一次保存，再回到 CfW 主介面觀察是否有紅色報錯條；若核心拒絕啟動，優先回滾備份，再二分查找是哪一段 YAML 破壞了結構。

與「只點 Proxies」相比，這條路徑的心智負擔更高，但回報是：你能只改一個組的類型，而不被圖形殼的預設卡片限制。對於已經在 Win11 上穩定使用 CfW 的用戶，這是把高級策略落盤的最短通道；若你長期厭惡 YAML，可評估 Verge Rev 等殼層的覆寫 UI，但那就屬於另一條產品鏈的敘事，本文保持 CfW 口徑。

可照抄的 proxy-groups：type、strategy、proxies

下面是一段結構正確、需替換名稱的示例：把 MY-LB-POOL 換成你的組名，把 node-a、node-b 換成 proxies: 小節裡真實存在的 name。strategy 在 Mihomo 系常見選項包括 consistent-hashing 與 round-robin：前者更傾向「同一目標地址落在相對固定成員」，後者更傾向「在成員間輪換」；具體可用值以你目前核心版本說明為準，若保存時報未知欄位，應回去核對發行註記而非硬猜拼寫。

proxy-groups snippet 
proxy-groups:
  - name: "MY-LB-POOL"
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - node-a
      - node-b
      - node-c

若你更關心「把連接儘量均勻攤開」而不強調目標維度的一致性，可以把 strategy 換成 round-robin 做對照實驗。無論哪種策略，都要意識到：池裡若有一條品質差的成員，它仍會承接一部分連接，除非你在 health-check 語義或其他層把它摘掉——這與 fallback 那種「順位跳過失效項」的主觀體驗不同。實踐上很多人會先精簡池子，只留下延遲與丟包在同一量級的三至五條，再上負載平衡，而不是把整份訂閱上百節點無腦塞進來。

也可用同一模式嵌套：load-balance 組的 proxies 列表裡除了裸節點名，也能寫其它策略組名，從而先讓上游完成地區或手選，再在子層做會話分散。嵌套越深，偵錯越依賴 Connections 日誌；初學者建議先用「扁平池」驗證負載確實被鋪開，再加入嵌套以降低認知負荷。

把規則接到你的新組名上

光有組不會自動接管流量：rules: 裡的第三列必須出現你的組名字符串，或由上層的預設 MATCH 鏈路間接引用到它。最典型的寫法是把某個域名後綴或 Geo 規則指向 MY-LB-POOL。注意規則從上到下匹配——若前面早有更泛的條目把同類流量送去了別的組，你在後面新增的負載平衡規則可能永遠不會被執行。調校時建議對照 規則分流最佳實踐，先畫一條從域名到組名的路徑，再保存。

rules example 
rules:
  - DOMAIN-SUFFIX,large-cdn.example,MY-LB-POOL
  - MATCH,MY-LB-POOL

以上第二行僅作演示：把「兜底」用的 MATCH 直接綁到負載平衡池在真實機場配置裡可能過於激進，更多時候你會讓 MATCH 仍指向一個手動 select 組，只在下載或特定進程相關域名上使用 load-balance。關鍵原則是：業務上需要會話粘性的站點（登入狀態、金融、部分 API）不要與大雜燴負載池混在同一規則裡，除非你已理解哈希策略如何影響出口切換。

保存、重載與 Connections 驗證

保存 YAML 後，回到 Clash for Windows 觸發一次配置重載（具體按鈕隨版本在 General 或 Profiles 附近）。成功時，Proxies 裡應出現新組名，且類型行為符合「自動分散」而不是手動點選。若介面仍顯示為可選手動組，多半是你其實編輯了未被啟用的 profile，或核心未能解析該段 YAML 從而回退到預設呈現。

驗證階段不要只看延遲數字：打開 Connections，用瀏覽器或下載工具製造多個並行連接，觀察若干秒內不同 TCP 會話是否落在不同成員上。若所有連接仍釘死在同一條出口，優先檢查規則是否真的命中該組、是否有下游組再次覆蓋、以及應用是否走了系統代理/TUN 以外的旁路。若只有部分應用異常，還要懷疑分流對象是否繞過了 Clash（見 mixed-port 與系統代理 相關說明）。

這一驗證思路與 圖形介面教程裡強調的「看日誌再下結論」一致，只是本文目標從「選節點」換成了「確認分散是否發生」。對於需要科學對照的人，可以臨時把組改回 select 單點，確認業務本身無獨立故障，再切回 load-balance，避免把應用層 TLS 問題誤判為策略組類型無效。

常見坑：訂閱覆寫、髒節點、UDP 與加密站點

第一類坑是遠端配置把本地修改衝掉，上文已提。第二類是髒節點混池：負載平衡不會替你「自動避開慢的那條」，只會按策略分配份額；若成員之間延遲差一個數量級，體感可能是「忽快忽慢」而不是「整體更快」。第三類與 UDP、遊戲或語音相關：不同節點對 UDP 支援差異很大，分散後可能放大丟包感知，必要時為遊戲單獨保留 select 或 url-test 組，勿與下載池共用規則。

第四類與安全站點有關：銀行、企業 VPN、以及對出口 IP 漂移敏感的 SAML 登錄，往往假設客戶端 IP 在長會話內相對穩定。哈希策略能減少一部分抖動，但不等於合同級別的「固定出口」。若你為此類域名誤配了負載平衡，很容易出現偶發跳轉登錄或風控提示——這不是 Clash 「壞了」，而是你把它用在了不匹配的風險模型裡。

⚠ 合規提醒：請只在你被授權的網絡與賬號環境中使用代理與負載策略；本文為技術說明，不涉及任何繞過管控或侵犯他人權益的用法。提供商條款、公司法務要求與當地法規始終優先於個人調參偏好。

常見問題

介面裡還能看到 load-balance 組裡面的「當前節點」嗎？

可視化客戶端通常仍會顯示某種「代表項」或子成員列表，但語義上它不是純手動鎖死。要以 Connections 實測為準，而不是死記卡片高亮。

可以把機場自帶的「自動選擇」直接改成負載平衡嗎？

技術上可以改寫同名組的 type，但若該組由訂閱每次重生，你的改動無法持久。更穩妥是新建一個獨立組名，再在規則裡顯式引用它，避免與提供商命名更新打架。

負載平衡能否提升單線程測速條上的「 Mbps 數字」？

單線程往往仍受單條 TCP 路徑限制；負載平衡更多改善的是多連接疊加時的總吞吐或把壓力攤到多條會話上。若你只有單連接測速需求，優先期待線路品質本身，而不是策略組類型魔法。

安裝與訂閱 baseline：Windows 11 安裝 Clash for Windows；圖形測速與模式：延遲測速與策略組介面教程；自動選快與主備：url-test 與 fallback 實配；日誌排障：timeout 與 TLS 入門。五篇文章串聯成「能裝、會點、會寫、會查」的 Win11 CfW 學習鏈。

結語

把 Windows 11 上 Clash for Windows 的某一個 策略組切成 load-balance，本質是承認：你要的是連接級分散而不是延遲榜第一名。按 Profiles → 核心編輯器 寫入 proxy-groups、選對 strategy、用 規則第三列把目標流量導進該組，再用 Connections 做多連接複核，這條鏈路就閉合了；需要 url-test／fallback 精細欄位時回到姊妹篇即可，不必在一篇裡混寫所有類型。

停更或閉源的舊桌面殼層，常見痛點是：YAML 露出不完整、與新版 Mihomo 欄位脫節、以及把「策略類型」藏得太深，用戶只能在外圍點按鈕卻改不了底層語義。相較之下，Clash V.CORE 所強調的發行思路，是把可持續更新的核心與清晰可得的客戶端對齊到同一套規格與術語語彙裡——你在 CfW 裡學會的 load-balance 寫法，可以遷移到仍在維護的殼與規則鏈路上，而不是鎖死在一份歷史遺留的二進位檔裡。

→ 到本站統一下載入口獲取與當代 Mihomo 生態對齊的客戶端，在繼續寫規則、負載與分流時，先有可驗證的底座，再迭代你的 Win11 桌面臨場配置。