Advanced Proxy Groups: Configuring Load Balancing and Failover

A Quick Recap of the Three Basic Group Types

url-test (Auto Select) runs periodic latency tests and always uses whichever node currently has the lowest latency; select (Manual Switch) leaves the choice entirely up to you. Those two cover most default setups. Once you have more nodes and more demanding use cases, load-balance and fallback solve two more specific problems.

load-balance: Spreading Traffic Across Multiple Nodes

A load-balance group distributes different connections across all the nodes in the group, instead of funneling everything through a single "best" node the way url-test does. That spreads bandwidth pressure across several nodes at once, which matters most when multiple devices are sharing the same subscription and pushing meaningful traffic. It supports two distribution strategies, set via the strategy field:

proxy-groups:
  - name: Load Balance
    type: load-balance
    strategy: consistent-hashing
    proxies: [NodeA, NodeB, NodeC]
    url: http://www.gstatic.com/generate_204
    interval: 300

• consistent-hashing — hashes the destination address so the same destination always lands on the same node, useful for anything that needs session persistence (some sites trigger extra verification challenges if the source IP keeps changing);
• round-robin — cycles through the group's nodes in request order for more even distribution, but doesn't guarantee the same destination hits the same node twice.

If you're not sure which to pick, default to consistent-hashing — it's the more stable choice for most use cases.

fallback: Automatic Backup When the Primary Node Drops

A fallback group checks node availability in the order you list them and always uses the first available node under normal conditions. The moment the active node fails its latency check (and is marked unavailable), it automatically switches to the next available node in line, and switches back once the primary recovers. This differs from url-test's "always use whoever's fastest" logic — fallback is about preferring a primary node and only falling back when it genuinely goes down:

proxy-groups:
  - name: Failover
    type: fallback
    proxies: [Primary, BackupA, BackupB]
    url: http://www.gstatic.com/generate_204
    interval: 300

Combining Group Types

In real configs, these group types are often nested — for instance, use url-test to pick the lowest-latency node from several within the same region, then wrap a handful of those regional url-test groups inside a select group so you can manually pick which region to use. If bandwidth needs to be spread out, set a batch of nodes as a standalone load-balance group, then place it alongside your other groups inside the final manual-switch menu so you can jump to it whenever needed.

Don't Overlook tolerance — It Cuts Down Pointless Switching

Both url-test and load-balance groups have another parameter that's easy to miss: tolerance (latency tolerance, in milliseconds). Without it, the client strictly follows "whoever's lowest wins," but latency measurements naturally jitter by a few milliseconds between runs — and without a buffer, that jitter alone can cause the group to flip back and forth between a couple of similarly-fast candidates, which actually hurts the experience (an active download or video call can hiccup briefly every time a switch happens).

proxy-groups:
  - name: Auto Select
    type: url-test
    proxies: [NodeA, NodeB, NodeC]
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

With tolerance: 50 set, a switch only happens once a candidate node is at least 50ms faster than the current one — otherwise the client sticks with what it's already using, even if the latest measurement came back slightly higher. You don't need to set this very high; 50–100ms is usually enough to filter out most of the meaningless jitter-driven switching.

Picking the Right Tool for the Job

Back to the original question: if switching is simply happening too often, adding tolerance alone usually fixes it — no need to reach for a more complex group type. If the goal is spreading multi-device traffic across nodes to ease pressure on any single one, that's what load-balance is for. If the concern is "will something automatically take over if my primary node goes down," that's fallback. Three distinct problems, three distinct tools — you don't need all of them at once, just whichever one matches the issue you're actually running into. For more on proxy group parameters, see the Advanced Configuration Docs.