A proxy group determines which specific node is used once a rule matches. Many people set up their subscription and never touch the proxy groups again, sticking with the default group given by their provider — but the default setup is usually just "functional," not "optimized." There's often plenty of room for improvement.
What Each of the Three Types Solves
| Type | What It Solves | Trade-off |
|---|---|---|
| select | Lets you manually pin a specific node, so behavior is fully predictable | Won't switch automatically on failure — requires manual intervention |
| url-test | Automatically picks the lowest-latency node, no manual speed testing needed | Testing itself uses a bit of traffic and time; bad parameters cause frequent switching |
| fallback | Automatically switches to the next available node in order if the primary fails | "Available" only means reachable — not necessarily the lowest latency |
| load-balance | Spreads connections across multiple nodes, reducing bandwidth pressure on any single node | Different concurrent connections may use different nodes — not suitable when you need a consistent IP |
url-test: Two Key Parameters for Auto Speed Testing
url-test is the most commonly used type, but many people only configure the proxies list and leave it at that. In reality, interval and tolerance are the two parameters that determine whether the experience feels good or bad.
proxy-groups: - name: Auto type: url-test proxies: [HK-01, HK-02, SG-01, JP-01] url: http://www.gstatic.com/generate_204 interval: 300 # Test speed every 300 seconds — too frequent wastes traffic tolerance: 50 # Don't switch if the latency gap is under 50ms, to avoid jitter-triggered flapping lazy: true # Pause testing when there's no active traffic, saving battery and data
tolerance is the parameter that's easiest to overlook but has the biggest impact. Set it to 0 and even a 1ms latency difference between two nodes will trigger a switch — over time it'll feel like you're constantly bouncing between nodes for no reason. A value of 50–100ms is a well-balanced choice: it filters out normal network jitter and only switches when the latency gap is genuinely significant.
fallback: Giving Your Primary Route a Backup
If you have a "primary node" that's usually low-latency but occasionally flaky, instead of manually watching for drops and switching yourself, wrap it in a fallback group: under normal conditions it always uses the top-priority node, and automatically moves to the next one as soon as the current one becomes unavailable.
proxy-groups: - name: Fallback type: fallback proxies: [HK-Premium, Auto, SG-01] url: http://www.gstatic.com/generate_204 interval: 180
The order here matters: HK-Premium is the primary node, listed first; Auto is the url-test group configured earlier, acting as a "smarter backup"; SG-01 is the final safety net. fallback checks each entry in order and only moves to the next one if the previous is unavailable — most of the time you won't even notice it's there, and it only proves its value when the primary node actually runs into trouble.
load-balance: When You Actually Need It
load-balance is often mistaken for a "speed boost" feature. What it actually solves is "a single node can't handle enough bandwidth" or "I want connections spread across multiple exit nodes" — the speed improvement for a single download task is limited, because one TCP connection always stays on one node. The load-spreading effect only shows up when you have multiple concurrent connections.
- If your use case is mostly streaming video and casual browsing, you probably don't need load-balance — url-test is already enough.
- If you have multiple client devices sharing the same set of nodes, or frequently run multiple concurrent downloads, load-balance can spread the load more evenly.
- load-balance supports two strategies: round-robin and consistent-hashing (which tries to keep the same destination address on the same node). The latter is better suited for cases where you need a consistent exit IP for a given site.
Putting It Together: A Practical Three-Layer Structure
In practice, it's better to stack all three types together rather than picking just one:
- At the bottom, use a url-test group to gather nodes from the same region and automatically pick the fastest one.
- In the middle, wrap it with a fallback group that prioritizes your "primary node" over the "url-test group," ensuring an automatic safety net on failure.
- At the top, expose a select group to your rules, with the fallback group plus a few manually selectable backup nodes in its candidate list — giving you the option to step in manually at any time.
Your rules should only ever reference the outermost select group. All the speed-testing and failover logic stays encapsulated inside its candidate list, so you can adjust the internal proxy group logic without ever touching your rules.