Home/Blog/Load Balancing & Failover

Hands-On Guide

Load Balancing & Failover: Building Stable Connections Across Multiple Nodes

Rely on a single node and sooner or later you'll hit throttling, flakiness, or a full dropout. The fallback and load-balance proxy group types exist specifically so that "one node has a problem" doesn't have to mean "your whole connection has a problem." This guide breaks down how each one decides what to do, how to configure them, and how to layer multiple strategies into a setup that's genuinely resilient.

🗓️ July 17, 2026 ⏱️ About 8 min read 🔗 Related: Advanced Configuration · Proxy Groups: Four Scheduling Strategies

Why a Single Node Isn't Enough

Nodes aren't static: "the provider is doing maintenance," "the upstream line is flaky," "too many people online at once causing throttling" — none of these necessarily take a node fully offline, but they all noticeably degrade the actual experience.

If your proxy group is a manual select, you're the one who has to notice a node acting up and switch it yourself — and every connection made in the meantime gets slow or times out. fallback and load-balance solve this from two different angles — "switch on failure" and "spread the load" — and you can use both at once, each covering a different scenario.

How fallback Decides When to Switch

A fallback group continuously health-checks nodes in the order you configured them, and only switches to the next one in line once the currently active node is judged "unhealthy":

config.yamlyaml
proxy-groups:
  - name: Failover
    type: fallback
    proxies: [Primary, Backup-A, Backup-B]
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    max-failed-times: 3

A few key fields:

  • url: the target for health-check requests — use a small, globally reachable test endpoint, so the check itself doesn't burn much traffic and doesn't get misjudged just because that particular URL happens to be restricted.
  • interval: how often the health check runs, in seconds. Too short adds unnecessary probe traffic; too long delays recovery from an actual outage. 300 seconds is a common middle ground.
  • max-failed-times: how many consecutive failures before a node is marked "unhealthy," so one random timeout doesn't trigger an unnecessary switch.
💡

fallback only switches when the currently active node is unhealthy — even if a backup node has lower latency, it won't proactively switch over as long as the primary passes its health check. That's the key behavioral difference from url-test, and it's exactly what you want when you'd rather keep a fixed "primary line" with everything else as pure emergency backup.

load-balance's Two Distribution Strategies

load-balance isn't about "picking the best one" — it actively spreads different connections across every node in the group, and the strategy field decides exactly how:

consistent-hashing

  • Hashes based on the connection's source address, so the same source is very likely to land on the same node consistently
  • Friendlier for anything needing "session stickiness," like sites/games sensitive to a connection suddenly changing
  • When one node is removed, only the small slice of connections mapped to it are affected — no global reshuffle

round-robin

  • New connections are handed to nodes in turn, giving a more even split
  • Doesn't guarantee the same source always lands on the same node — sessions can "jump" between nodes
  • Better suited to lots of short, independent connections where session stickiness doesn't matter
config.yamlyaml
proxy-groups:
  - name: LoadBalance
    type: load-balance
    strategy: consistent-hashing
    proxies: [Node-A, Node-B, Node-C]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

Unless you have a specific reason not to, consistent-hashing is usually the safer default, since it has less impact on connection stability.

In Practice: Layering Strategies Into a Stable Setup

These three strategies aren't mutually exclusive — a common real-world pattern is to nest them in layers: an outer select for a manual master switch, a middle layer of url-test or load-balance for automatic scheduling, and a fallback as the last line of defense for extreme cases:

config.yamlyaml
proxy-groups:
  - name: PROXY
    type: select
    proxies: [Smart, Manual]

  - name: Smart
    type: fallback
    proxies: [FastPool, Backup]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

  - name: FastPool
    type: load-balance
    strategy: consistent-hashing
    proxies: [Node-A, Node-B, Node-C]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

The effect of this setup: day-to-day, "FastPool" spreads connections across three nodes; if that entire layer has a problem (say, the data center it's in goes down), the outer fallback automatically switches to "Backup" — and at the very top, PROXY always keeps a manual override available.

Common Mistakes

  1. Using a low-traffic, ordinary website as the health-check URL: response times on sites like that vary a lot, which can get a perfectly healthy node misjudged as "unhealthy." Always use a lightweight, stable test endpoint.
  2. Mixing nodes with very different speeds inside a load-balance group: round-robin/hashing distribution doesn't account for node speed, so mixing them makes the experience inconsistent connection to connection. Try to keep nodes in the same load-balance group roughly similar in quality.
  3. Setting interval too low: frequent health checks consume node resources and your own traffic too — most scenarios don't need anything below 300 seconds.

If the switching behavior doesn't match what you expected after configuring this, cross-check each field's meaning against the Proxy Groups section of the Advanced Configuration guide, or open the Dashboard to watch each proxy group's current health status directly.

Read Next