Most subscriptions default to select (pick manually) or url-test (auto-select the fastest node) proxy groups, and those two cover most day-to-day needs. But if you have a lot of nodes, or need better reliability, fallback and load-balance offer better fault tolerance and traffic distribution.
01The Four Proxy Group Types at a Glance
| Type | Selection logic | Best for |
|---|---|---|
| select | Fully manual — the core never switches automatically | You want precise control over which node is used |
| url-test | Periodically tests latency and auto-picks the fastest node | Everyday use, set-and-forget — the default for most subscriptions |
| fallback | Uses the first available node in list order, only moving to the next when the current one fails | You have a clear primary/backup priority and want to favor a specific node |
| load-balance | Distributes different connections across multiple nodes simultaneously, by algorithm | Multiple nodes, want to spread traffic and avoid overloading any single one |
02Fallback Configuration Example
Fallback tries nodes in the order you list them: as long as the first node is healthy, all traffic goes through it; only after a health check fails does it move to the next one. In other words, the order of the list is the priority.
proxy-groups:
- name: "Fallback-Group"
type: fallback
proxies: ["HK-Primary", "HK-Backup", "SG-Backup"]
url: "http://www.gstatic.com/generate_204"
interval: 300In this example, traffic keeps using "HK-Primary" for as long as its health check passes. Only when that check fails does it try "HK-Backup", then "SG-Backup", in order.
03Load Balance Configuration Example
Load Balance spreads different connections (not packets within the same connection) across multiple nodes in the group, distributing traffic and providing some fault tolerance along the way — if one node goes down, new connections simply get assigned to the healthy ones.
proxy-groups:
- name: "LoadBalance-Group"
type: load-balance
proxies: ["HK-01", "HK-02", "HK-03"]
strategy: consistent-hashing
url: "http://www.gstatic.com/generate_204"
interval: 300The Two strategy Values
- consistent-hashing: hashes based on the connection's destination, so the same destination is very likely to always land on the same node — useful for cases that need "sticky sessions" (some sites are sensitive to the source IP changing mid-session).
- round-robin: cycles through nodes in order, distributing more evenly, but doesn't guarantee the same destination always lands on the same node.
04Which One Should You Use
If you only have one or two reliable nodes, url-test is already enough. If you know one node is noticeably better and want it prioritized, with the rest as backup, use fallback. If you have several nodes of similar quality and worry a single node can't handle multiple devices at once, load-balance is the better fit. All three types can also be nested — for example, using a fallback group as one of the candidates inside another group — depending on exactly how your nodes are set up.
05Two Fields That Control Health Checks
Both fallback and load-balance rely on background health checks to decide whether a node is usable. That behavior is controlled by the url and interval fields — get these wrong and you'll either get slow failover or waste bandwidth on overly frequent checks.
- url: the address the health check hits — normally a lightweight endpoint (like http://www.gstatic.com/generate_204). A successful response just means the node is reachable; there's no need to point this at a real production site.
- interval: the check interval in seconds. Too small and the client fires off health checks constantly, burning extra bandwidth and battery. Too large and a failed node takes much longer to get noticed and swapped out. Around 300 seconds is a reasonable balance for most setups.
06FAQ
Q: Is there a limit on how many nodes a load-balance group can have?
No hard limit, but more nodes means more overhead from health checks. In practice, 3–6 nodes of similar quality usually gives good distribution — too many makes it harder to troubleshoot when something goes wrong.
Q: Does switching proxy groups drop existing connections?
fallback and load-balance only affect where new connections get routed — existing connections generally aren't force-closed. That said, if the original node has actually gone down, that connection was probably already failing anyway, and the client will need to reconnect regardless.