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

1. Start with the difference: lowest latency, priority, or connection distribution

All three proxy groups can contain multiple proxies, but they solve different problems. url-test automatically selects a proxy based on measured latency; fallback selects the first available proxy in the list; load-balance distributes different connections across available proxies. Before choosing a group, decide whether you need automatic selection, primary-and-backup failover, or connection distribution.

The examples in this article assume a client running the mihomo core. Older versions of Clash and different forks may support extended fields differently, especially load-balancing algorithms. Check the core name in the client’s About or core information panel, then save the configuration and confirm that it loads successfully. Do not assume compatibility based on the client’s name alone.

2. url-test: Choose by probe latency and use tolerance to reduce switching

url-test works well for everyday traffic without a fixed-egress requirement. The core sends requests to a test URL through each candidate, records the results, and selects an outbound proxy based on availability, latency, and the switching threshold. This measures the time for a specific HTTP request—not an ICMP ping or a sustained download speed test.

Basic setup: probe every 300 seconds, with a 50 ms tolerance

Merge this snippet into your existing configuration. The example proxies “Hong Kong 01,” “Hong Kong 02,” and “Japan 01” must already exist under proxies, with names that exactly match your configuration. If you use a subscription provider, see the use example below.

proxy-groups:
  - name: Auto Low Latency
    type: url-test
    proxies:
      - Hong Kong 01
      - Hong Kong 02
      - Japan 01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

• interval: 300: Probe every 300 seconds, or 5 minutes—not every 300 milliseconds.
• tolerance: 50: Set a 50 ms switching tolerance to avoid frequent proxy changes when latency varies only slightly.
• lazy: false: Disable lazy probing so unused groups also refresh their health status on schedule, at the cost of additional probe requests.

For example, the current proxy measures 110 ms and another measures 95 ms—a difference of just 15 ms. With a 50 ms tolerance, that small gap should not be taken to mean the group must switch. If a candidate measures 45 ms, the 65 ms improvement is more likely to meet the switching threshold. These figures illustrate the parameter; they are not real-world measurements. Actual results also depend on probe timing, the current proxy’s state, and the core implementation.

Why does video still buffer when latency is lowest?

A small probe request is no measure of peak-hour throughput. A proxy may respond quickly to the test URL but throttle video services, or the route to the destination may be congested. Compare real-world performance and connection logs instead of changing interval from 300 to 5 in an attempt to increase bandwidth through more frequent tests.

If a low-latency proxy keeps switching between regions, a website may see your egress location change during a session. Consider increasing tolerance or creating separate groups for proxies in the same region. For services that need a consistently fixed egress, use manual selection or an explicit primary-and-backup setup.

3. fallback: Set up primary and backup proxies by order

With fallback, order is what matters. The first available proxy in the list has the highest priority; later candidates are tried only when earlier ones are unavailable. Once a health check marks the primary proxy available again, routing can return to it. In other words, switching to a backup does not mean the group stays there permanently.

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

In this example, “Hong Kong 01” remains the preferred proxy even if it measures 180 ms while “Hong Kong 02” measures 60 ms, as long as the first proxy is considered available. Putting a slower but more reliable connection first is a valid primary-and-backup setup—not a failed speed test.

Failover does not take exactly 60 seconds

interval: 60 sets the interval between scheduled probes; it does not guarantee recovery within 60 seconds. If a failure occurs between probes, the group may have to wait for the next check, which also takes time to complete. Additional checks triggered by connection failures, and their related settings, vary by core version and configuration.

• Put the proxy you want to use first; do not reorder the list just to match speed-test results.
• Where possible, avoid having the primary and backup share the same single point of failure. An upstream outage affecting both can take out every candidate.
• When the primary fails, existing TCP connections may drop and the application may need to reconnect. A proxy group does not migrate established connections.

4. load-balance: Distribute connections, not single-connection bandwidth

load-balance selects among available candidates, but it does not split one TCP connection across multiple proxies. A single-threaded download will usually still use one egress proxy. A multi-connection download may use different proxies, depending on the downloader, server, connection reuse, and distribution algorithm—so do not expect total speed to multiply.

consistent-hashing: Keep the same destination on the same proxy where possible

proxy-groups:
  - Multi-Proxy Distribution
    type: load-balance
    proxies:
      - Hong Kong 01
      - Hong Kong 02
      - Japan 01
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

consistent-hashing uses the destination address to distribute connections with consistent hashing, keeping traffic to the same destination on the same proxy where possible. The mapping may still change when the set of available proxies changes. This works well for distributing traffic across different destinations, but does not keep an entire browser on one egress proxy: a single page may use separate domains for sign-in, images, and APIs.

round-robin: Rotate new connections across proxies

Change strategy in the example above to round-robin to distribute connections in rotation. Round-robin does not split traffic evenly by bytes or allocate connections based on remaining data quotas. A long-running download can transfer far more data than a web request that finishes in seconds.

For sign-in, payments, or other services sensitive to egress changes, use a fixed proxy or a separate, stable group. Existing HTTP/2 connections may carry many requests, so refreshing a page a few times is not enough to tell whether round-robin is working. Check the connection panel to see which proxy new connections actually use.

5. Configuration limits: interval, tolerance, and proxy pools

Do not confuse proxies with use

proxies lists the names of proxies or other proxy groups; use references providers defined under proxy-providers. If your existing configuration has a provider named “Subscription Pool,” an automatic group can use it like this:

proxy-groups:
  - name: Auto Select from Subscription
    type: url-test
    use:
      - Subscription Pool
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

This is not a complete, standalone configuration; it assumes “Subscription Pool” already exists. A provider’s interval controls how often its proxy resources are updated, while health-check.interval sets the provider’s health-check interval. The group-level interval controls how often the proxy group probes candidates. These identically named fields apply at different levels and are not interchangeable.

The number of proxies also affects probe volume. A group with 30 candidates that probes all of them every 300 seconds will generate about 360 probe requests per hour. The actual count depends on lazy probing and other checks. Reducing the interval to 30 seconds greatly increases requests without necessarily improving everyday performance.

6. Apply rules and test the client: Verify the group, then the traffic

After creating a proxy group, you still need a rule or a parent group that lets you select it. The combination below makes it easy to compare all three behaviors. When merging it, add the groups to the same proxy-groups list instead of declaring duplicate top-level YAML keys.

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

rules:
  - DOMAIN-SUFFIX,github.com,Proxy Egress
  - MATCH,Proxy Egress

This snippet assumes all three automatic groups from above already exist. It demonstrates how to reference them; it is not a split-routing setup for mainland China and elsewhere. The final MATCH sends requests that did not match an earlier rule to “Proxy Egress.” Keep existing rules that serve a purpose; do not replace all direct-connection rules just to test this.

1. Back up your configuration. Export the current configuration first. Remote subscription updates may overwrite direct edits; to keep changes, use the client’s supported override, merge, or extension feature.
2. Load the configuration. Check the logs for unknown group names, unknown proxy names, or YAML indentation errors. Use spaces for indentation, not tabs.
3. Switch to rule mode. Make sure the client is using Rule mode. In Global mode, the rule list is not a reliable way to verify routing.
4. Select the entry group. Find “Proxy Egress” on the Proxies page, select each of the three automatic groups in turn, then run the client’s speed test or latency test. Button names vary by client.
5. Inspect connections. Open the Connections page and check the matched rule, proxy chain, and final proxy. A manual speed test runs immediately; it is not the same as observing scheduled health checks over a full interval.

To test failover, first back up your configuration, then temporarily remove the preferred proxy from the test copy. Reload it and check whether the next candidate takes over. To verify an egress change, create a new connection so the browser’s connection pool does not keep reusing an existing one. For help with traffic interception in TUN mode, see the troubleshooting guide and first confirm that traffic is reaching the core.

7. Choose a default for your use case

• Everyday browsing and general apps: Start with url-test, using a 300-second interval and 50 ms tolerance as a baseline. Adjust them based on actual latency variation.
• A preferred primary connection: Use fallback and order candidates carefully. A lower latency on the backup does not change its priority.
• Multiple connections for different destinations: Use load-balance, starting with consistent-hashing. Choose round-robin only if you specifically need rotation.
• Accounts that need a stable egress: Set up a separate manual-selection group and domain rules. Do not mix this traffic into an automatic group that changes frequently.

The key question is: which rule matched the request, and which proxy handled it in the end? Latency figures, the word “auto” in a group name, and the system proxy toggle cannot answer that. Test the logic with a small set of candidates before expanding the proxy pool. This usually makes problems easier to isolate than changing probe intervals, DNS, and TUN settings all at once.