Clash proxy groups: how to choose between url-test, fallback, and load-balance

Choosing among the three automatic strategies

Clash automatic proxy groups decide which node receives a new connection; they do not rewrite your traffic routing rules. A rule first sends a connection to a proxy group, which then selects a node according to its own logic. In rule mode, if a domain matches DIRECT, changing the automatic group's test interval will not change that domain's egress route.

All three strategies can use health checks, but they use the results differently: url-test compares latency, fallback checks whether members are available in priority order, and load-balance distributes connections among available members. The examples below follow mihomo's configuration semantics. Older Clash cores and different clients may support only some fields, so check which core is actually running rather than relying on the app's name.

url-test: choose by latency and use tolerance to avoid flapping

url-test probes a specified test URL through candidate nodes and selects a node based on the results. This latency is not an ICMP ping or a download-speed test. It reflects how long the proxy route takes to reach the test address and can be affected by the node connection, the target site's response, and network conditions.

A starting configuration for everyday browsing

Place this snippet under the top-level proxy-groups key. The example assumes Hong Kong-A, Hong Kong-B, and Japan-A already exist under proxies; replace them with the exact names of your existing nodes. This is a proxy-group snippet, not a complete subscription with server credentials.

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

• interval: 300: Checks run every 300 seconds, or 5 minutes—not every 300 milliseconds.
• tolerance: 50: A 50 ms switching tolerance helps prevent frequent node changes over minor latency differences.
• lazy: true: Enables lazy checks, so an unused group is not checked continuously at the same pace as an active one. A configured interval does not mean probes run constantly in the background.
• url: Choose a lightweight address that all candidate nodes can reach reliably. The example URL typically returns HTTP 204.

What the tolerance means in practice

Suppose node A currently probes at 110 ms and node B at 90 ms—a difference of just 20 ms. With a 50 ms tolerance, the group should not switch to B just for that small advantage. If A rises to 180 ms while B stays at 90 ms, the 90 ms gap may be enough to trigger a switch to the faster node; the exact timing depends on when checks and selection run. These figures illustrate the behavior and are not measurements from this site.

Tolerance is neither an extra wait nor a timeout for deciding that a node is down. Setting it to 0 makes the group more sensitive to small latency changes, but does not guarantee faster browsing. For everyday use, start at 50 ms, watch for frequent switching, and consider 100 ms if needed.

fallback: keep a primary route and use a backup when it fails

fallback selects the first available member in the list. As long as health checks consider the first entry available, a second entry with lower latency will not replace it. Use it when you want a specific route by default and switch only when it becomes unavailable—not when you always want the fastest node.

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: 120
    lazy: true

How failure and recovery affect selection

1. When all three members are available, the first entry in the list, Hong Kong-A, is selected.
2. If Hong Kong-A fails its check while Japan-A is available, new connections use Japan-A.
3. Once a later check confirms Hong Kong-A has recovered, it takes priority again, so new connections may return to Hong Kong-A.

So fallback is not a sticky failover setup that stays on the backup forever. If the primary keeps switching between available and unavailable, traffic may switch back and forth. If you need to keep a particular route selected while working, a manual select group is usually clearer.

A 120-second check interval does not guarantee that a failure will be detected and recovered from within 120 seconds. Actual timing also depends on when the failure occurs, probe timeouts, lazy checks, and application retries. If the primary is heavily congested but can still reach the test address, fallback may keep using it: slow and unavailable are not the same state.

load-balance: distribute connections, not bandwidth for a single connection

load-balance distributes connections across available nodes. It can help when multiple tasks run in parallel, but it does not split a typical TCP download across three routes. Even if each of three nodes can deliver 10 MB/s, enabling this strategy alone will not give one download a speed of 30 MB/s.

consistent-hashing vs. round-robin

• consistent-hashing: Applies consistent hashing based on destination-related information, tending to send the same destination through the same member. This can help reduce egress changes for a given destination, although the mapping may still change when the set of available nodes changes.
• round-robin: Selects available members in turn, making it easier to spread new connections across them. It does not schedule based on real-time bandwidth, CPU load, or remaining traffic allowance.

proxy-groups:
  - name: Multi-Route
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - Hong Kong-A
      - Hong Kong-B
      - Japan-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

To use round-robin, change strategy in the example to round-robin, provided your current core supports that strategy field. Distribution happens per connection—not per click on a webpage or per request within an HTTP/2 connection. When a browser reuses long-lived connections, a page with many requests may still use only a few nodes.

Limits of interval, test URLs, and node providers

Health-check traffic from automatic strategies passes through candidate nodes. With 30 nodes and a 30-second interval, assuming the group stays active and every check completes each round, that is about 30 × 120 = 3600 probes per hour; at 300 seconds, about 360. Actual counts depend on lazy checks and how the provider and core schedule probes. Shorter intervals have a cost—they are not always better.

Subscription updates vs. health checks

If you use proxy-providers, the provider-level interval usually controls how often the remote node list is refreshed; health-check.interval controls node health checks. Neither is the same as the identically named field in a proxy group. Setting the subscription refresh interval to 60 seconds does not automatically run speed tests every minute.

When using use to include a provider, check the provider's health-check settings. Adding a test URL to a proxy group does not guarantee that every provider member will be probed as expected. Avoid setting up frequent checks in multiple places without a clear reason. First verify the strategy with a few explicitly listed nodes, then add the provider and review its update logs and health status separately.

Use a reachable, consistent test address

If some nodes are on networks that block the test address, they may be marked unavailable even though they can reach other sites. Conversely, reaching the test address does not prove that every service will work. If the whole group times out, first try the same address through a known-good node to rule out a test-site outage, DNS error, or failed TLS handshake before blaming the nodes.

Apply and verify the configuration: make sure new connections reach the intended group

You do not need to enable all three automatic groups at once. To compare them in one configuration, put the three definitions above in the same proxy-groups list and add a manual entry point. Do not repeat the proxy-groups key multiple times at the YAML top level; this may overwrite existing content or cause a parsing error.

  - name: Proxy Entry
    type: select
    proxies:
      - Daily Auto
      - Primary and Backup
      - Multi-Route
      - Hong Kong-A

Add the example to the same list, using the same indentation as the other groups. In your existing rules, point the destinations you want to proxy to Proxy Entry. For example, to proxy example.com and its subdomains, put the rule below before broader matching rules. It is an example for specific destinations, not a recommendation to route all existing traffic through a proxy.

rules:
  - DOMAIN-SUFFIX,example.com,Proxy Entry
  - MATCH,DIRECT

This rule illustrates how matching works; the final line sends all other traffic directly, so do not use it to replace the complete routing rules in your subscription. Rules are matched from top to bottom, and an earlier rule may already capture your test traffic.

1. Save and validate the configuration. Check that the core reports no unknown strategies, duplicate group names, or missing nodes. Subscription managers may overwrite direct edits when they update; for lasting changes, use the client's override or configuration-merge feature.
2. Keep your current traffic interception setup. Continue using your working system proxy or TUN settings, and avoid changing DNS, ports, and strategies at the same time. None of these three strategies requires TUN to be enabled.
3. Select the target group from the entry point. Start with Daily Auto, run a check, and note the candidate latencies and current selection. Then switch to the primary/backup group and compare the selection order.
4. Check a new connection. In the connections panel, review the matched rule, proxy chain, and final node. Existing pages may reuse connections; if needed, close the page and its connections, then visit it again.
5. Test failures in a controlled way. In a local test configuration, temporarily remove the primary node or use a known-unavailable member, then observe subsequent checks and new connections. Do not test by running probes at high frequency or disrupting a working network.

Common symptoms and what to check

• url-test keeps switching between two nodes: Check whether the latency gap is near the tolerance, whether the test address is unstable, and whether the interval is too short. Change one setting at a time and observe before making further adjustments.
• fallback did not choose the lowest-latency node: That is expected; fallback follows priority order. If latency should determine the choice, use url-test instead of continuing to shorten interval.
• load-balance seems to use just one node: Check whether consistent hashing is enabled, whether you keep accessing the same destination, and whether the app has established only one long-lived connection.
• The egress IP did not change after switching groups: Confirm that the lookup site matched the intended group and establish a new connection. Also consider that multiple nodes may share the same public egress.
• Every node times out: Check the same test URL, node status, system time, and logs first. A manual speed test in the client panel may use a different test address and parameters from the automatic group.

How to choose: configure latency testing, failover, and connection distribution separately

For everyday browsing, start with url-test + interval 300 + tolerance 50. To keep a preferred region or route unless it fails, use fallback with members ordered by priority. For distributing connections across independent tasks, consider load-balance and start with consistent hashing to check compatibility with your services.

Automatic strategies choose nodes, rules determine where traffic goes, and the system proxy or TUN handles traffic interception. Testing these layers separately makes issues easier to isolate than changing the core, DNS, and proxy groups all at once. For supported fields and traffic-interception details, see the technical reference. If you first need to import a subscription and establish a basic connection, follow the user guide step by step.