Clash Proxy Groups: url-test vs. fallback vs. load-balance

Clash Auto Groups: Choose the Right Selection Goal

Clash proxy groups are a configuration layer for selecting from existing proxies, not new proxy servers. Rules determine which group handles a request, and the group then selects a proxy. Adding an automatic group does not route all traffic through it: automatic selection affects only requests routed to that group by a rule or a parent group.

All three types can use health checks, but each optimizes for something different: url-test selects by probe latency, fallback follows a priority order, and load-balance distributes connections. For everyday browsing, consider the first two. Use load balancing only when you need multiple exits to handle separate connections.

url, interval, and lazy: How health checks work

url is a probe target, not a subscription URL

url specifies the address used for health checks. The core sends an HTTP probe to this URL through each candidate proxy and records whether it succeeds and how long it takes. It is not a subscription download link or a speed-test URL for downloading large files. This example uses https://www.gstatic.com/generate_204, a common lightweight probe endpoint, but whether it works well depends on your routes and target network.

For a fair comparison, use the same probe URL for every candidate in a group. Fast access to a probe site does not mean video sites or work services will be just as fast. Conversely, restrictions on the probe domain can mark otherwise usable routes as unhealthy. When troubleshooting, test probe failures separately from service access failures.

interval is in seconds, not milliseconds

interval: 300 schedules checks every 300 seconds, or 5 minutes. It is not a per-request timeout, nor does it guarantee that every application will detect a failure within 300 seconds. Lazy checks, scheduling, probe duration, and the state of existing connections all affect what happens in practice.

• For everyday browsing, start with 300 seconds and adjust after observing the results.
• If you need to detect primary-route failures sooner, consider 60 seconds, but expect more probe requests.
• With 20 proxies checked in a full cycle every 60 seconds, that works out to about 1,200 probes per hour in theory. At 300 seconds per cycle, it is about 240. Actual totals also depend on mechanisms such as lazy checks.

lazy controls periodic checks for idle groups

On cores that support this field, lazy: true reduces the overhead of checking proxy groups that are not in use. lazy: false allows idle groups to continue checking on schedule. If you want a backup group to stay up to date before it is selected, consider disabling lazy checks; with many proxies and groups, keep an eye on the extra overhead. This does not automatically retry a request that has already failed.

url-test: Choose low latency automatically; tolerance controls switching

url-test probes candidate proxies and automatically selects one based on the results. It works well when candidates serve similar purposes and changing exits is acceptable, such as several general-purpose routes in the same region. If candidates differ significantly in location, account risk controls, or service access, latency alone is often a poor basis for choosing between them.

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

These three proxy names must already exist under proxies in your configuration and match exactly. This is only a proxy-group snippet; it does not include server addresses, credentials, or complete rules, so it cannot be used on its own as a working subscription.

tolerance is measured in milliseconds

tolerance: 50 sets a 50 ms switching tolerance to reduce frequent changes caused by small latency fluctuations. For example, suppose the current proxy measures 120 ms and another measures 100 ms—a difference of just 20 ms. Switching just for that small gain is usually unnecessary. If the other proxy drops to 60 ms, the 60 ms improvement may meet the switching threshold. These figures are illustrative, not measurements from this site.

Tolerance is not a latency cap or a failure threshold. Setting it to 50 does not exclude every proxy above 50 ms. If the current proxy is unavailable, a large tolerance will not force it to stay selected. Check your core's implementation for the exact comparison and initial-selection behavior.

• Frequent switching: First check whether proxies are repeatedly timing out, then consider increasing the tolerance.
• Fast probe, slow downloads: Test the actual service separately and check throughput, packet loss, and network congestion.
• Accounts that require a fixed region: Limit candidates to that region or use manual selection instead of mixing locations.

fallback: Prioritize the primary route and switch to a backup on failure

fallback checks proxies in the order listed under proxies and picks the first available one. If the first proxy is healthy, a later proxy will not be preferred just because it has lower latency. Use it when you want a stable primary route with a backup for emergencies—not when you always want the fastest proxy.

proxy-groups:
  - name: Primary and Backup Routes
    type: fallback
    proxies:
      - Hong Kong Route A
      - Japan Route A
      - Singapore Route A
    url: https://www.gstatic.com/generate_204
    interval: 60
    lazy: false

This order means Hong Kong Route A is preferred. Japan Route A is considered only if its health check fails, followed by Singapore Route A if both earlier proxies are unavailable. If a higher-priority proxy recovers, new connections can switch back to it after a later check. As a result, a primary that repeatedly recovers and fails can cause the exit to change back and forth.

Failover does not migrate existing connections

A video stream, SSH session, or large download usually has an established connection. Changing the proxy group does not seamlessly move that same TCP connection to another server. The existing connection may fail, and the application may need to reconnect; new connections use the new selection. A backup can reduce recovery time for calls or remote terminals, but it cannot guarantee uninterrupted service.

load-balance: Distribute connections, not combine bandwidth

load-balance distributes traffic across available proxies. Its benefits usually come from routing separate connections through different exits, not from combining two routes' speeds for a single download. Even when an application supports parallel downloads, the outcome depends on server limits, the distribution strategy, route bandwidth, and the application's behavior.

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

consistent-hashing: Keep destinations on a more stable exit

In mihomo, consistent-hashing generally hashes on the registrable portion of the target domain; when no domain is available, the destination IP may be used. It tends to route the same destination through the same proxy, but does not permanently bind an account to one exit. Changes to the available proxies, destination domain, or other routing conditions can change the result.

A webpage often loads resources from multiple domains for sign-in, APIs, images, and static files. Opening the same website therefore does not guarantee that every request uses the same exit. For sign-in sessions, payments, or region-sensitive services, a safer option is to route related domains through a fixed proxy or a dedicated, controlled group.

round-robin: Distribute new connections in turn

On cores that support this strategy, set strategy to round-robin to distribute new connections in turn among available candidates. It does not alternate packets, and it does not guarantee an even split by bytes: one connection might transfer 2 GB while another transfers only 2 KB. Similar connection counts do not mean similar traffic volumes.

Older Clash cores may support a different range of strategy values. Do not copy every mihomo strategy value into an archived client. If a field is rejected or behaves unexpectedly, check the core name and version, then consult the matching documentation. A setting being saved in the UI does not prove that the core applied it.

Connect automatic groups to your rules: Add a select entry point and reference it

Adding proxy-groups alone does not automatically replace your existing rules. One convenient approach is to add a parent select group for manual selection, list all three automatic groups as options, and point the rules that need a proxy to this entry point. This lets you switch strategies in the UI without rewriting the rules each time.

proxy-groups:
  - name: Proxy Entry
    type: select
    proxies:
      - Auto Low Latency
      - Primary and Backup Routes
      - Multi-Route Distribution
      - DIRECT

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

This is also a configuration snippet and must be combined with the automatic groups above. example.com is a domain used to demonstrate rule syntax, not a speed-test site. This rule sends the domain and its subdomains to Proxy Entry; other requests go direct through the final MATCH,DIRECT rule. Do not mistake this example for a complete set of rules for everyday traffic.

1. Keep the original subscription configuration intact and add the proxy groups to a test copy, so subscription updates do not overwrite your changes.
2. Check every proxy name, group name, and rule reference. Capitalization, spaces, and non-ASCII characters must match exactly.
3. Keep exactly one top-level proxy-groups and one top-level rules in the full configuration. Merge the list items into them instead of pasting duplicate top-level keys.
4. In Clash for Windows, select the test configuration under Profiles. Then open Proxies, choose Rule mode, expand Proxy Entry, and select the automatic group you want to test.
5. In Global mode, traffic is handled by the global policy, so existing rule references no longer determine where it goes. Direct mode also cannot verify how automatic groups behave in everyday rule-based routing.

To keep changes long term, use an override, Mixin, or configuration-merging feature supported by your current client, then inspect the final generated runtime configuration. Clients may replace or merge arrays differently, so do not assume that adding a few lines will preserve every group in your subscription.

Automatic proxy group not working? Troubleshoot in four steps

Step 1: Check that the core accepts the configuration

Check Logs for YAML parsing errors, missing proxies, or unsupported strategy values. YAML uses spaces for indentation, not tabs; align each list item under proxies. If a proxy name contains special sequences such as a colon followed by a space, quoting the whole name is safer.

Step 2: Test proxies and the probe URL separately

Manually select a single proxy and test the actual destination, then run the group's latency test. If only one probe URL fails, check that the address is reachable and that the HTTPS handshake succeeds before removing proxies. If the proxy itself cannot connect, changing tolerance or the load-balancing strategy will not fix authentication, server, or network problems.

Step 3: Check which policy handles the request

In Connections, inspect the rule and proxy chain for a new request to confirm it went through the intended group. If an earlier direct rule matched, or the application bypassed the client, the automatic group will have no effect. If the browser uses the proxy but another application does not, also check the system proxy, the app's own proxy settings, and the scope of TUN routing. Proxy groups do not replace traffic-ingress configuration.

Step 4: Verify the change with a new connection

After switching groups or waiting for checks to run, send a new request instead of continuing to watch an existing connection. To test fallback, make the primary temporarily unreachable in a controlled environment and record the check time, first failure, and recovery time. For url-test, record latency across multiple checks rather than comparing a single result. For load-balance, inspect the proxy chains for multiple connections instead of refreshing a page that may reuse a connection.

• Everyday browsing: Pair url-test with proxies in the same region. Start by evaluating a 300-second interval and 50 ms tolerance.
• Fixed primary route: Use fallback, order proxies by business priority, and test what happens when the primary recovers.
• Multiple-connection workloads: Use load-balance only if changing exits is acceptable, and test both hash-based and round-robin strategies.
• Sensitive sessions: Prefer a fixed proxy or dedicated selection group rather than relying entirely on automatic latency comparisons to keep the exit stable.

The key is not which proxy group is more advanced, but what you need to optimize: latency, primary-backup priority, or connection distribution. Narrow down the candidate proxies first, set check parameters next, and then test with real services. This is usually more effective than continually shortening the check interval.