Once you have a lot of nodes, manually switching between them gets old fast. Clash's three automatic proxy-group types — url-test, fallback, and load-balance — each solve a different problem, and combining them well makes node failures and latency swings mostly invisible to you.
Three automatic group types at a glance
| Type | Node Selection Logic | Best For |
|---|---|---|
| url-test | Tests speed on a schedule, always uses the lowest-latency node | Chasing optimal speed, occasional switching is fine |
| fallback | Uses nodes in order, only moves to the next when the current one fails | You have a clear primary/backup priority |
| load-balance | Distributes requests across multiple nodes by algorithm | Spread load across nodes, avoid overloading any single one |
url-test: automatically pick the fastest node
This is the most commonly used group type. Clash tests all nodes in the group on a schedule and always uses whichever has the lowest latency.
tolerance (in milliseconds) prevents constant switching over a few milliseconds of test jitter: a new node only actually takes over once its latency is lower than "current latency − tolerance."
fallback: a clear primary/backup order
If you have one "primary node" and only want to switch to a backup when it fails, fallback is the right fit — it checks nodes in the order of the proxies list, and always prefers the first one that's still working.
load-balance: spread out the load
When you have several nodes of similar quality and want to spread connection load across them, use load-balance. It supports two distribution algorithms:
- consistent-hashing: the same destination address consistently lands on the same node — good for scenarios that need session stickiness.
- round-robin: connections are distributed in turn, more evenly, but the same destination address may land on different nodes.
Tuning health-check parameters
url, interval, and tolerance together control how often a group checks node health and how big a gap is needed before switching. Too aggressive or too conservative, either can cause problems.
| Field | What It Does | Tuning Advice |
|---|---|---|
| url | Target address for the speed test request | Use a lightweight, stable probe target — avoid large files or sites prone to fluctuation |
| interval | Seconds between speed tests | Too short adds load on the node side — around 300 seconds is usually a good balance |
| tolerance | Minimum latency gap needed to switch (ms) | Raise it if your network is naturally jittery, to avoid switching over trivial differences |
tolerance is set too low before blaming node quality.
Can proxy groups be nested
Yes. A group's proxies field can list either specific node names or the name of another proxy group, which lets you build layered structures like "auto speed-test by region, then manually pick which region." That said, don't nest too deeply — each extra layer adds another layer of logic to reason through when debugging. Two to three layers is usually enough to cover most use cases.
In practice: building a multi-region node pool
A common multi-layer structure: build several url-test sub-groups by region first (e.g. "HK Auto", "SG Auto"), then use one manual select group to let yourself make the final call — balancing automation with flexibility.
Routing different rules to different groups
Proxy groups really shine when combined with rules: different traffic types can be routed to different groups entirely, instead of dumping everything into one catch-all group. For example, streaming domains can route to a group of nodes known to unlock streaming well, gaming domains can route to a low-latency-first url-test group, and everything else falls through to a general auto-select group. That way each traffic type gets matched to the node-selection logic that actually suits it, rather than applying one standard to every scenario.
How to decide whether to split proxy groups
Not every scenario needs fine-grained splitting. The rule of thumb is simple: if a traffic category has a clearly different preference for "how to pick a node" (gaming is extremely latency-sensitive, streaming has hard regional-unlock requirements), it's worth splitting into its own group; for ordinary web browsing, a general auto-select group is plenty — there's no need to over-split just to "look more sophisticated," since that only adds maintenance and debugging overhead later.
Why existing connections aren't affected when you switch nodes
After manually or automatically switching the active node in a group, you might notice that already-established connections (a file mid-download, a video mid-playback) don't switch over immediately — instead, the new node only applies once that connection ends naturally and a new one is opened. This is by design: node switching at the proxy layer applies to new connections, not existing sessions, which avoids interrupting an in-progress download or call every time a node switches. If you really need every connection to switch immediately, you can manually close old connections in the panel's Connections tab to force new requests to be made.
Summary
No single group type is a silver bullet: use url-test for speed, fallback for a clear primary/backup order, and load-balance to spread load. In practice, nesting them together and backing them with a manual select group is usually the best way to balance automation with control.