Load Balancing and Failover: How Multi-Node Scheduling Works

Comparing the Four Proxy Group Types

Type	Behavior	Best Suited For
select	Manual selection — only uses the node you click	You prefer to stick with a fixed node
url-test	Periodically tests speed and auto-switches to the lowest-latency node	You always want the currently fastest route
fallback	Uses the first available node in list order, only switching to the next when the current one fails	You have a clear primary/backup node priority
load-balance	Distributes requests across multiple nodes by strategy to spread connection load	You have plenty of nodes and want to spread out bandwidth load

Swipe left/right to view the full table

url-test: Automatically Chasing Low Latency

url-test sends a speed-test request to all nodes in the group at a set interval and automatically switches to the lowest-latency one — no need to manually click a speed-test button.

url is the target address used for the speed test — typically one with a lightweight response; interval is the test interval in seconds. Testing too frequently adds unnecessary requests, so setting it to once every few minutes is usually enough.

fallback: Primary/Backup Failover

fallback prioritizes nodes in the order you list them under proxies. Once the currently used node fails a speed test (becomes unavailable), it automatically switches to the next available node in the list, until the primary recovers. Ideal when you clearly know which node has the better line and which is the backup.

load-balance: Spreading Out the Load

load-balance doesn't try to pick "the single best node" — instead it spreads different requests across multiple nodes. Common allocation strategies include consistent hashing by connection (the same destination always uses the same node, avoiding session interruptions) and round-robin. Ideal when you have several reasonably stable nodes and want to spread bandwidth and connection-count load.

Common Tuning Tips

Once you're using proxy groups, there are a few more details worth watching that keep automated scheduling closer to what you expect:

• Choose a lightweight speed-test target:The url field should point to an address with a tiny response body that barely uses bandwidth (e.g. a health-check endpoint returning a 204 status), so the speed test itself doesn't consume excessive traffic.
• Set a reasonable interval:Too short an interval bombards nodes with excessively frequent speed-test requests; too long delays detecting failures. Once every few minutes is a common compromise.
• tolerance margin:Some implementations support setting a tolerance value — a switch is only triggered when a new node's latency is lower than the current one by more than this margin, preventing repeated flip-flopping when latency hovers near the threshold.
• Number of nodes in the group:When a load-balance group has too few nodes, the load-spreading effect is negligible — you need enough nodes to truly realize the value of "spreading the load."

Common Questions

Why do nodes in a url-test group keep flip-flopping?

This usually happens when several nodes have very close latency — small fluctuations in each speed test are enough to change the "lowest latency" ranking. Increasing interval appropriately, or using a config with tolerance, can effectively reduce this frequent switching.

What if all nodes in a fallback group show as unavailable?

First check whether the speed-test address itself is reachable — if the target is blocked by a firewall, all nodes will be mistakenly judged unavailable. You can also try switching to a more stable, lower-traffic speed-test address.

Can select, url-test, and load-balance be combined?

Absolutely, and it's a recommended approach: group nodes by region into several url-test sub-groups (e.g. "HK Auto-Select," "JP Auto-Select"), then use an outer select group to manually choose the region. This keeps the flexibility of manual control while enjoying automatic optimization within each group.

Summary

If you only have one or two nodes, manual select switching is enough. Once node count grows, url-test saves you the hassle of manually testing and switching, fallback suits scenarios with a clear primary/backup relationship, and load-balance is better for spreading load across a batch of similarly-quality nodes.