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

Choose the selection behavior before configuring proxy-groups

Use url-test to automatically select a responsive proxy; use fallback to keep a primary route and switch only when it fails; use load-balance to distribute connections across proxies. All three can use health checks, but “automatic” does not mean they select proxies by the same criteria.

The client imports subscriptions, displays proxy groups, and applies the configuration; the core handles proxy selection. Clash and Clash Meta (now called mihomo) share many basic fields, but supported options and strategies may differ. The examples here target mihomo. Before saving, check the running core in the client’s core details or startup log, then validate the configuration.

url-test: select by latency and use tolerance to prevent flapping

url-test sends requests to the same test URL through candidate proxies and selects one based on health-check results and response time. This measures the time taken to reach the test service through the proxy route. It is not an ICMP ping to the proxy server or a download speed test.

Minimal configuration and parameter units

proxy-groups:
  - name: Auto Low Latency
    type: url-test
    proxies:
      - Hong Kong Daily
      - Japan Backup
      - Singapore Backup
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

• url: The health-check target. The example URL typically returns HTTP 204. Choose a small, reliable HTTPS endpoint that candidates can reach.
• interval: 300: Checks run every 300 seconds, or 5 minutes—not every 300 milliseconds.
• tolerance: 50: A switching tolerance of 50 milliseconds helps prevent frequent egress changes caused by small latency differences.
• lazy: true: Enables lazy checks, reducing periodic tests for groups that are not in use. Checks may still run when a group is first activated, when you test it manually, or when scheduled by the core.

Tolerance is not a fixed latency limit

Suppose one check reports 120 ms for the current proxy and 95 ms for another—a difference of just 25 ms. With a 50 ms tolerance, the group typically won’t switch for such a small advantage. If the other proxy drops to 60 ms, the 60 ms difference may meet the switching threshold. These figures are hypothetical examples, not measurements from this site. The actual selection also depends on proxy health and core implementation.

Don’t treat tolerance as a “reject anything over 50 ms” setting. It measures the latency difference that can trigger a switch; it does not impose a 50 ms pass/fail limit on every proxy. If the group keeps switching between regions, try increasing tolerance from 20 ms to 50 ms and observe the result instead of cutting the check interval to 5 seconds.

fallback: keep the primary route and switch to a backup only when it fails

With fallback, list order matters—not lowest latency. The first healthy proxy in the list is preferred; a later healthy proxy is used only when the earlier one fails. Once the primary recovers, it will typically become the preferred choice again.

proxy-groups:
  - name: Primary and Backup
    type: fallback
    proxies:
      - Hong Kong Daily
      - Japan Backup
      - Singapore Backup
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: false

In this example, the group still prefers “Hong Kong Daily” at 150 ms over “Japan Backup” at 70 ms, as long as the Hong Kong proxy is healthy. Put proxies for the preferred region or with more suitable traffic costs first, then add backups in other regions.

Failover does not migrate connections without interruption

• There can be a delay between checks before a failure is detected. A 300-second interval does not mean failures will be detected immediately, nor does it guarantee a recovery time.
• A group switch mainly affects new connections. Existing TCP sessions cannot be moved to another egress while keeping the server-side session intact, so video streams, SSH sessions, or downloads may need to reconnect.
• Here, fallback is not an application-level retry mechanism that immediately resends each failed request through another proxy.
• lazy: false keeps checking groups periodically even when they are not in use, so their status is more likely to stay current. It also generates more test requests and can wake mobile devices more often.

If your traffic needs a consistent region, keep primary and backup candidates in the same egress region where possible. A reachable test URL only confirms that the health-check request succeeded; it does not guarantee access to every service domain or the same content access on both proxies.

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

load-balance distributes connections among healthy candidates. It is not link aggregation and will not split one TCP download across three proxies. It is most useful for spreading multiple independent connections or destinations—not for multiplying the speed of a single download by the number of proxies.

proxy-groups:
  - name: Multi-Proxy Distribution
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - Hong Kong Daily
      - Japan Backup
      - Singapore Backup
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: true

Choosing between consistent-hashing and round-robin

For general browsing, start with consistent-hashing. It can reduce how often the same destination switches egress, but it does not bind a session at the account level: a service may use multiple domains, and destinations may be reassigned when a candidate becomes unhealthy. For logins, payments, or admin dashboards that require a consistent source IP, use rules to route traffic to a manual selection group or a stable primary-and-backup group.

Round-robin distributes connections, not bytes. Three proxies may each handle several connections, yet traffic volumes can still vary significantly if one connection sustains a large download. This basic example does not configure weights. Billing multipliers of 0.5x, 1x, or 2x are not automatically treated as cost weights by the load balancer.

Combined example: keep a manual option and route rules to a proxy group

The example below puts all three automatic groups in a select group. Once enabled, choose “Proxy Egress” in the client’s proxy group panel, then select Auto Low Latency, Primary and Backup, Multi-Proxy Distribution, or an individual proxy. This gives you a way to bypass automatic selection and check whether a specific proxy works.

proxy-groups:
  - name: Proxy Egress
    type: select
    proxies:
      - Auto Low Latency
      - Primary and Backup
      - Multi-Proxy Distribution
      - Hong Kong Daily
      - Japan Backup
      - Singapore Backup

  - name: Auto Low Latency
    type: url-test
    proxies:
      - Hong Kong Daily
      - Japan Backup
      - Singapore Backup
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: Primary and Backup
    type: fallback
    proxies:
      - Hong Kong Daily
      - Japan Backup
      - Singapore Backup
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: false

  - name: Multi-Proxy Distribution
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - Hong Kong Daily
      - Japan Backup
      - Singapore Backup
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: true

rules:
  - MATCH,Proxy Egress

The final MATCH rule only illustrates how a rule points to a group. Keep your existing LAN, direct, and application-specific routing rules, and place the catch-all rule at the end. Replacing all rules with this single line would send traffic that should bypass the proxy through Proxy Egress.

Use use with subscriptions configured through proxy-providers

If your proxies come from an existing proxy-providers entry, you don’t need to list each proxy name in the group. For example, if the configuration defines a provider named Line Subscription, reference it like this:

proxy-groups:
  - name: Provider Auto Select
    type: url-test
    use:
      - Line Subscription
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

use references a provider name, while proxies references proxy or group names; they are not interchangeable. The provider update interval controls when the proxy list is fetched, while the health-check interval controls when availability is tested. Checking every 60 seconds does not update the subscription list every 60 seconds.

A provider can also have its own health-check. The core schedules checks for groups and providers; you cannot simply add the two intervals to predict failover time. Make clear which component is responsible for periodic checks, and avoid setting very short intervals on multiple providers and groups, which can generate unnecessary requests.

Validate and troubleshoot: check the actual egress before tuning test settings

Check the YAML and proxy references first

1. Back up the working configuration. Edit proxy groups through a persistent override or merge configuration option instead of modifying a temporary file that subscription updates may overwrite.
2. Use spaces for indentation, not tabs. Keep group names unique, match rule names to group names exactly, and avoid circular references between groups.
3. If the command-line core is available on PATH, run mihomo -t -f ./config.yaml to validate the configuration. Adjust the relative path to match the file’s actual location.
4. Reload the configuration, trigger a health check manually, then review the proxy group’s candidate statuses. Passing configuration validation does not mean a proxy can connect.

Verify a new connection through an explicit proxy endpoint

If your current configuration actually uses 7890 as its HTTP or mixed proxy port, you can test it with the command below. This is an example port, not a default for every client. Check the port settings or the configuration’s mixed-port value first.

curl -I --proxy http://127.0.0.1:7890 --max-time 15 https://cp.cloudflare.com/generate_204

Specifying the proxy explicitly means the command does not depend on whether the terminal uses the system proxy. An HTTP 204 response confirms that this test route works; also check the client’s connection log to confirm the matched rule, proxy group, and actual proxy. To verify a service, establish a new connection to that service—success with the test URL alone is not enough.

Common symptoms and what to check

• All proxies time out: First select a known-working proxy manually. If services work but the test fails, check the test domain, DNS, and reachability of the test URL. Don’t remove all proxies straight away.
• url-test keeps switching proxies: First check whether the test URL is stable, then increase the tolerance. Changing the interval from 300 seconds to 10 seconds usually magnifies short-term fluctuations and may also increase battery use.
• fallback doesn’t choose the fastest proxy: That is expected: it selects the first healthy proxy in list order. To compare latency, switch to url-test rather than rearranging the backup list to mimic latency-based sorting.
• load-balance traffic is uneven: Check whether there are only a few long-lived connections or many requests to the same destination. Neither consistent hashing nor round-robin guarantees equal byte counts across proxies.
• The group switched, but the site still shows the old egress: Establish a new connection first. Browser connection reuse, ongoing downloads, and long-lived connections may still use the old proxy. Closing connections can interrupt active tasks, so do so only when appropriate.
• Settings disappeared after a subscription update: Move custom proxy groups to a persistent override mechanism supported by your client, then check the final merged configuration—not just the snippet in the editor.