负载均衡与故障转移实战

节点再多，不会调度也白搭：高峰期一个个手动换节点，或者半夜挂机时节点挂了没人管。这篇教你用三种自动化策略组把调度全交给我，目标是——快的时候更快，挂的时候无感。

三种自动策略组回顾

类型	调度逻辑	最适合
`url-test`	定时全员测速，永远走最快的那个	日常浏览，追求低延迟
`fallback`	按列表顺序检测，第一个存活的顶上	有明确主备偏好的场景
`load-balance`	把不同连接分摊到多个节点	多线程下载、防单节点限速

url-test：加上 tolerance 防抖

默认配置下 url-test 有个恼人的问题：两个节点延迟接近时会反复横跳，每次切换都可能断开正在进行的连接。解法是加 tolerance：

防抖动的 url-test

proxy-groups:
  - name: "自动测速"
    type: url-test
    proxies: [香港 01, 香港 02, 东京 01, 新加坡 01]
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50   # switch only if 50ms+ faster than current

意思是：新节点必须比当前节点快 50ms 以上才切换。数值按需调，越大越稳定、越小越激进。

fallback：主备线路的正确姿势

如果你有一条高质量专线和几条普通线路，fallback 是最佳选择——平时永远走专线，专线故障时自动降级，恢复后自动切回：

主备 fallback

proxy-groups:
  - name: "主备切换"
    type: fallback
    proxies: [香港-IEPL 专线, 香港-普通 01, 美国-备用]   # priority order
    url: "http://www.gstatic.com/generate_204"
    interval: 120    # check more often for faster failover

注意 proxies 的顺序就是优先级顺序，检测间隔建议比 url-test 短一些，故障转移才够快。

load-balance：两种散列策略

load-balance 示例

proxy-groups:
  - name: "负载均衡"
    type: load-balance
    proxies: [香港 01, 香港 02, 香港 03]
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    strategy: consistent-hashing   # or: round-robin

consistent-hashing：同一个目标网站固定走同一个节点，登录态不会乱，日常推荐。
round-robin：连接轮流分配到各节点，多线程下载提速明显，但部分网站可能因 IP 跳动要求重新登录。

组合拳：嵌套出一个"既快又稳"的体系

策略组可以引用策略组。下面这套三层结构是社区口碑很好的方案：

嵌套组合方案

proxy-groups:
  # Layer 1: user-facing switch
  - name: "节点选择"
    type: select
    proxies: [智能调度, 香港专线, 手动选择]

  # Layer 2: auto scheduling with failover
  - name: "智能调度"
    type: fallback
    proxies: [低延迟组, 负载均衡组]
    url: "http://www.gstatic.com/generate_204"
    interval: 120

  # Layer 3: workers
  - name: "低延迟组"
    type: url-test
    proxies: [香港 01, 香港 02, 东京 01]
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

  - name: "负载均衡组"
    type: load-balance
    proxies: [新加坡 01, 新加坡 02, 美国 01]
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    strategy: consistent-hashing

日常流量走「低延迟组」自动测速；整组不可用时 fallback 自动降级到「负载均衡组」；你想手动接管时，在「节点选择」里一键切换。三层各司其职。

性能提醒 每个带 url 的策略组都会定时发测速请求，组太多、interval 太短会产生可观的后台流量。普通用户 3~5 个自动组、300 秒间隔完全够用。

三种类型到底该怎么选，一句话版

看完前面的参数细节，如果还是拿不准该选哪种，记住这个简化判断法：不在乎走哪个节点、只要最快→ url-test；心里有明确的主备优先级→ fallback；想把带宽压榨到极限、不介意偶尔重新登录→ load-balance。绝大多数人日常使用只需要一个 url-test 组就够了，fallback 和 load-balance 更多是"有明确诉求"之后才补上的进阶玩法，不必一开始就追求配置得多复杂。

排查策略组不生效的几个方向

配好之后发现调度好像没起作用？按这个顺序查：

先看 rules 有没有真的引用这个组：策略组定义了不代表它在用，得有规则（或者最终的 MATCH）指向它才会生效，这是最容易漏掉的一步。
打开控制面板的代理页确认组内节点状态：如果组内节点全部超时或掉线，url-test/load-balance 自然"看起来没用"，其实是没有可用节点可选。
检查 url 测速地址本身是否可达：默认的 generate_204 地址在个别网络环境下可能被拦截，导致测速结果全部超时，可以换成同类的其他检测地址试试。
fallback 的 interval 是否太长：如果检测间隔设置成了 600 秒以上，节点故障后要等很久才会被发现并切换，体感上就像"没生效"。

调度这件事没有一次到位的标准答案，建议先用最简单的单层 url-test 跑一段时间，观察真实使用中的痛点，再针对性地叠加 fallback 或 load-balance，比一开始就搭三层结构更容易维护。

什么时候值得投入时间做多层嵌套

不是所有人都需要文章前面那套三层结构，投入精力搭建复杂调度之前，先问自己几个问题：家里/公司有没有多条不同质量的线路需要区分主备？是否经常需要多线程下载、单节点带宽明显吃不满？是否已经遇到过"节点突然挂了却没人第一时间发现"的情况？如果这几个问题的答案大多是"没有"，那么一个简单的 url-test 组完全够用，没必要为了"看起来更专业"去堆砌配置。反过来，如果你是给全家或者团队提供网络出口，多层调度带来的稳定性提升是实打实的，值得花时间打磨。

另外提一句，策略组的名字尽量起得直观（比如"香港专线""负载均衡-新加坡"），半年以后你自己再打开配置文件，也能一眼看懂当初为什么这么设计，而不是对着一堆 select/fallback/url-test 面面相觑。

小结

三种策略组各司其职：url-test 追求"永远最快"，适合绝大多数日常场景；fallback 追求"主备分明"，适合有明确线路优先级的用户；load-balance 追求"压榨带宽"，适合多线程下载或防单节点限速的场景。别小看 tolerance 和 interval 这两个参数，调对了能省去很多莫名其妙的"节点抖动"和"切换太慢"的困扰。先从一个简单的 url-test 组开始用起来，等真正遇到需求再逐步叠加，比一次性搭出复杂结构更符合大多数人的实际使用节奏。