Clash Proxy Groups: url-test, fallback, and load-balance Compared

How to Choose Between the Three Proxy Groups

Clash’s automatic proxy groups decide which node a connection uses—not how to give every app more bandwidth. url-test compares probe latency, fallback follows a priority order, and load-balance distributes connections across available nodes. First decide whether you need low latency, a fixed primary and backup, or connection distribution; then tune the relevant settings.

The core runs the proxy-group logic. The client imports subscriptions, displays test results, and applies your selections. Even when different clients use similar button labels, they may use different cores and support different settings. The YAML examples below target mihomo, the core name used after Clash Meta. For other Clash cores, check their configuration docs and startup logs to confirm which settings are supported.

url-test: Automatically Choose a Node by Latency

url-test sends a request to a specified test URL through each candidate node, records the probe latency, and selects an available candidate. This “speed test” measures the latency of a single request, not sustained download speed. Results depend on factors such as your local network, the route from each node to the test site, DNS, connection setup, and server response time.

What interval and tolerance control

• interval: 300: Run periodic health checks every 300 seconds (5 minutes). This is not a connection timeout.
• tolerance: 50: Set the latency switching threshold to 50 ms. This helps prevent frequent switches when another candidate is only slightly faster.
• timeout: 5000: Allow up to 5,000 ms for a single health check. A probe that exceeds this limit may be marked as failed.
• lazy: false: Keep periodic health checks running even when the group is idle, so you can monitor results over time.

For example, suppose the current node measures 120 ms and another measures 95 ms—a difference of just 25 ms. With a 50 ms tolerance, don’t expect the group to switch based on that small advantage alone. If the other node drops to 60 ms, the 60 ms difference exceeds the threshold. These figures illustrate the settings; they are not measured route results. The final choice also depends on node availability and core behavior.

proxy-groups:
  - name: Auto Latency
    type: url-test
    proxies:
      - Hong Kong-A
      - Hong Kong-B
      - Japan-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    tolerance: 50
    lazy: false

The test URL should be reachable through every candidate and return a small, consistent response. The example URL is for connectivity checks; it does not represent the quality of access to every site. If you mainly use a particular service, test requests to that service as well. Avoid using login pages, CAPTCHA pages, or large files as periodic probe targets.

fallback: Keep a Primary and Backup in Priority Order

fallback prioritizes the first candidate in the list that passes its health check, rather than the lowest latency. Use it when you want to keep the same route in normal conditions and switch to a backup only if the primary fails.

proxy-groups:
  - name: Primary and Backup
    type: fallback
    proxies:
      - Hong Kong-A
      - Japan-A
      - Hong Kong-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    lazy: false

Failover and failback order

1. When “Hong Kong-A” passes its health check, it takes priority—even if “Japan-A” has lower probe latency.
2. If “Hong Kong-A” is marked unavailable, the group selects the next available node, “Japan-A.” If that is also unavailable, it checks “Hong Kong-B.”
3. If a later health check confirms that “Hong Kong-A” is back, the group may prioritize it again, and new connections may return to the primary route.

So fallback selects nodes by priority; it does not mean “switch to the backup and stay there.” If you need manual approval before switching back, manage the route with a manual select group. An automatic primary-and-backup group alone cannot enforce that workflow.

Failures are not always detected the moment they happen. With periodic checks alone, a route can fail just after a successful probe, then remain undetected until the next check and timeout. Other failure triggers depend on the core configuration, so don’t treat interval: 300 as a guarantee of instant failover.

Ideally, backup routes should fail independently. Two differently named nodes that share the same upstream route may go down together. For critical tasks, check your local network, node availability, and the destination service separately to avoid mistaking an outage at the destination for a primary-node failure.

load-balance: Distribute Connections, Not Bandwidth

load-balance distributes connections across available nodes. Requests from multiple pages, downloads, or destinations can use different routes, but an existing TCP connection stays on its selected node. Whether your browser shows a higher combined download speed depends on concurrent tasks, server limits, and whether the nodes share bandwidth.

proxy-groups:
  - name: Distributed Connections
    type: load-balance
    proxies:
      - Hong Kong-A
      - Hong Kong-B
      - Japan-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    lazy: false
    strategy: consistent-hashing

consistent-hashing vs round-robin

Consistent hashing does not permanently pin a destination to a node. The mapping can change when the candidate list or node health changes. Domain availability and how the destination is identified also affect assignment. A single page may request resources from multiple domains, so “the same page” does not mean every request uses the same route.

mihomo also supports the sticky-sessions strategy, which keeps assignments sticky for a period based on source- and destination-related information. Before using it, confirm that your core supports it and check how it behaves. Don’t copy extended settings into an older core’s configuration without verifying compatibility.

Routing for logins and long-lived sessions

For banking, payments, enterprise authentication, or services sensitive to your public IP, route traffic through a fixed node or manual group. Load balancing may send different connections from the same account through different public IP addresses, triggering reauthentication. Even with consistent hashing, test all related domains together rather than checking only the home page.

Routing Rules and Subscription Overrides

Defining a group does not send traffic through it by itself. In rule mode, connections are matched against rules from top to bottom, and the matching rule specifies a node or proxy group. System proxy settings, TUN, and rule matching operate at different layers: the first two determine how traffic enters the core, while the group determines which route it takes afterward.

You can put all three automatic groups behind a manual entry and choose a strategy in the client. The snippet below assumes the three automatic groups are already defined. You can name the groups as you like, but references must match, and groups must not reference one another in a loop.

proxy-groups:
  - name: Route Selection
    type: select
    proxies:
      - Auto Latency
      - Primary and Backup
      - Distributed Connections

rules:
  - DOMAIN-SUFFIX,example.com,Primary and Backup
  - MATCH,Route Selection

example.com is a reserved example domain used to demonstrate the rule structure. This rule sends a specific domain through the primary-and-backup group; other connections are handled by “Route Selection.” It is not a recommendation to replace all the rules in an existing subscription. MATCH is a catch-all rule and should come after rules that need to match first.

Keeping Configuration Changes After Subscription Updates

• Direct edits to downloaded subscription YAML may be overwritten the next time the subscription updates. First check whether your client supports persistent overrides or configuration merging.
• When using client-side overrides, check whether arrays are replaced, appended to, or merged by name. Implementations vary between clients, so don’t assume the same behavior across apps.
• With proxy-providers, proxy groups typically use use to reference providers. Check both the provider’s health checks and how the group manages its candidates.
• If the subscription renames nodes, static proxies references may stop working. After updating, check the logs and the group’s candidate list.

For general settings and rule order, see the proxy groups section of the YAML guide. For how traffic enters the core, refer to the TUN setup guide. You don’t need to change every network setting just to switch proxy groups.

Troubleshooting Automatic Switching

Speed tests look good, but downloads are slow

First, distinguish latency from throughput. A health check requests a small resource, so it cannot measure peak-hour congestion, sustained transfer throttling, or single-connection bandwidth. Compare sustained speeds by manually selecting candidate nodes and using the same download target at the same time of day. Don’t assume a route with 80 ms latency downloads faster than one at 100 ms.

A node is down, but the group hasn’t switched

1. Check that the current mode is Rule, then use the connection log to confirm which rule matched and which route was ultimately selected.
2. Make sure the app’s traffic is actually passing through Clash. Terminal tools may need proxy environment variables set separately and may not follow the macOS system proxy.
3. Check whether url is reachable through the nodes, whether interval is too long, and whether lazy checks are preventing the group from probing as often as expected.
4. Start a new test connection to tell whether new connections have failed to switch or an existing connection is simply still using its original route.

url-test keeps switching nodes

First, record latency changes across several check cycles, then adjust the tolerance. Start by observing settings such as interval: 300 and tolerance: 50; there’s no need to reduce the interval to a few seconds. If candidate latencies fluctuate only slightly, increasing the tolerance may reduce unnecessary switches. If the test URL itself is unstable, choose a more suitable probe target first.

All nodes show as unavailable

Check whether the test URL is reachable, along with DNS resolution, your local network, and subscription credentials, before reinstalling the client. Test another known-reachable small page through the same node, then check the logs for timeouts, DNS failures, or refused connections. If every candidate fails, a shared dependency may be down; it doesn’t necessarily mean every remote route failed at once.

Validate the Configuration and Choose a Strategy

For browsing and interactive requests, start with url-test. Use fallback when you have a clear primary route and want a backup to take over. Consider load-balance when you need to distribute independent tasks across routes. For a single account that needs a stable public IP, a fixed node or manual selection is usually easier to control.

1. Save your original configuration. Keep a copy you can restore, and start by changing only the proxy groups—not DNS, the TUN stack, and every rule at once.
2. Confirm the configuration loaded. Check the client logs for errors such as unsupported settings, missing node names, or circular group references.
3. Verify the actual route. Send a new request and check the matching rule, proxy-group chain, and final node in the connection log—not just the group name.
4. Allow at least two check cycles. With a 300-second interval, give health checks enough time to run. A manual speed test shows only the result at that moment.
5. Test failover in a controlled setting. In a recoverable environment, simulate a primary-node failure and then restore it. Check how subsequent connections switch and fail back.

The goal of proxy-group configuration is to make routing decisions fit your needs. Latency, availability, route stability, and connection distribution are different metrics. Testing them separately is a more reliable way to find problems than repeatedly running speed tests or blindly shortening the check interval.