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

Choosing Between the Three Automatic Proxy Groups

Clash proxy groups choose among multiple outbound proxies, while rules determine which group a connection uses. These settings operate at different levels: even a correctly configured automatic group won't be used if a rule sends the connection to DIRECT. This guide uses mihomo (formerly Clash Meta) configuration syntax. Support for options may vary across other cores and older versions, so check the core listed in your client's About or core information page before editing your configuration.

Choose a group based on what you need: use url-test to favor low latency, fallback to keep using a preferred proxy while it's available, or load-balance to distribute connections across multiple proxies. All three can check availability, but they use the results differently.

url-test Configuration: Automatic Selection and Switching Tolerance

This example assumes your configuration already contains proxies named "Hong Kong-01," "Hong Kong-02," and "Japan-01" in proxies or a proxy provider. These are references, not complete proxy definitions. Replace them with names that actually exist in your configuration. If you already have a proxy-groups section, merge these entries into its list instead of creating another top-level key with the same name.

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

What interval and tolerance control

• interval: 300: Runs a check every 300 seconds (5 minutes), not every 300 milliseconds.
• tolerance: 50: Sets a switching tolerance of 50 milliseconds to avoid frequent changes caused by small latency fluctuations. It is neither a probe timeout nor a latency limit.
• lazy: true: Enables lazy checks, which can skip periodic checks while the group is unused. Manual tests and first-use behavior also depend on the client and core implementation.
• url: The target URL used to test availability and latency. Choose a stable address with a small response body that represents the network path you care about.

For example, suppose the current proxy tests at 110 ms and another at 95 ms—a difference of just 15 ms. With tolerance set to 50 ms, don't expect the group to switch to the lowest number every time. Tolerance helps prevent flapping; it doesn't guarantee a specific switch time. If the current proxy goes offline, the core can't keep making decisions based only on these two latency readings.

These figures illustrate the parameters; they aren't results from a real connection test. TLS handshakes, network congestion, server response times, and connection reuse can all affect readings from the test URL. If web pages load with low latency but downloads are still slow, check throughput, packet loss, and peak-hour congestion rather than repeatedly setting tolerance to 0.

fallback Configuration: Set a Clear Priority Order

fallback prioritizes the first available proxy in the list, not the fastest one. If the primary is available, it usually stays selected even when a backup has a lower test latency. Use it when you have regional, cost, or egress preferences.

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

In this order, Hong Kong-01 has the highest priority, Hong Kong-02 is second, and Japan-01 is the last resort. If the first proxy fails the test and the second passes, the group selects the second. If a later check finds the first proxy is available again, it becomes the preferred choice.

Automatic failover doesn't seamlessly migrate existing connections

• A 120-second check interval doesn't mean every failure will be resolved within 120 seconds. Recovery also depends on when the check runs, how long the probe takes, and whether the app retries.
• A proxy that can reach the test URL may still fail to reach a service you need. Regional restrictions, blocks by the destination site, or routing problems affecting a single site may not show up in the test.
• Switching policies mainly affects new connections. Existing downloads, video streams, and WebSocket connections won't automatically move to another route.

load-balance Configuration: Distribute Connections, Not Single-Connection Bandwidth

load-balance is useful for workloads with multiple concurrent connections. This example uses consistent-hashing to keep the same destination mapped to the same proxy when the candidate set stays stable. This can reduce how often a site changes egress, but it doesn't guarantee a permanent IP address.

proxy-groups:
  - name: Load Balance
    type: load-balance
    proxies:
      - Hong Kong-01
      - Hong Kong-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true
    strategy: consistent-hashing

Choosing a load-balancing algorithm

• consistent-hashing: Uses destination information to distribute connections with consistent hashing. The result depends on whether the destination domain is visible and whether the candidate proxies have changed.
• round-robin: Assigns connections in rotation. It's straightforward, but a similar number of connections doesn't mean similar traffic volumes, and it doesn't guarantee that each route carries the same number of bytes.

For example, if an app opens eight download connections at once, load balancing may spread them across different proxies. If the server allows only one connection, throughput is still limited to the route used by that single connection. Browsers can also multiplex multiple requests over one HTTP/2 connection, so a page with many resources doesn't necessarily use every proxy evenly.

For online banking, account management, and services that require a consistent region, prefer a fixed proxy or a policy tied to a specific region. Even with consistent hashing, the egress can change if a proxy goes offline, the candidate list changes, or the destination domain changes. For services involving authentication, don't expand the candidate regions just to "balance" traffic.

Combine Proxy Groups and Keep a Manual Option

For everyday use, put all three automatic groups in a select group: use automatic selection by default, switch to primary/backup when you need a fixed priority order, and choose load balancing for concurrent tasks. Add this snippet to the existing proxy-groups list above. The rules section is a separate example showing a catch-all rule; don't use it to replace your full set of routing rules.

proxy-groups:
  - name: Egress
    type: select
    proxies:
      - Auto Select
      - Primary and Backup
      - Load Balance
      - Hong Kong-01

rules:
  - MATCH,Egress

The MATCH rule above catches any connection that reaches it without matching an earlier rule. Put specific rules for your LAN, sites in mainland China, or business services before it. Rules are generally evaluated from top to bottom, so don't put the catch-all first and expect later routing rules to take effect.

Group references must match names exactly and must not form a loop. For example, if "Egress" references "Auto Select," then "Auto Select" must not reference "Egress" in turn. When troubleshooting, start with one manual selector and one automatic group; deep nesting makes it harder to trace test results and the final egress.

Keeping custom changes after a subscription update

1. Back up your current configuration and note the proxy names, group names, and related rules.
2. Check whether your client supports overrides, merging, or extended configuration. Direct edits to a file generated from a subscription may be overwritten the next time it's updated.
3. If you use proxy-providers, you can reference a provider with use if your client supports it. Don't mistake a provider name for a proxy name and put it under proxies.
4. After updating the subscription, check for renamed proxies and changes to the candidate list, then validate the configuration and run a manual test.

Troubleshooting an Automatic Proxy Group That Isn't Working

First confirm that the configuration loaded, then trace the actual connection. Don't change DNS, TUN, the group type, and the test URL all at once. Change one setting at a time so you can tell what's having an effect.

Step 1: Check YAML Syntax and References

Use spaces, not tabs, for indentation; keep the - before list items; and avoid duplicate top-level proxy-groups keys in the same file. If the mihomo command-line tool is installed locally, run the configuration test below. The filename in the command is config.yaml in the current directory; it doesn't mean you need to rename your subscription file.

mihomo -t -f config.yaml

If you see an error saying a proxy or group can't be found, fix the name reference first. Passing a syntax check only means the configuration can be parsed; it doesn't confirm that a remote proxy is reachable or that the test URL is working.

Step 2: Confirm Traffic Reaches the Intended Group

Find the destination domain in your client's connection list and check the matched rule, policy chain, and final proxy. The system proxy usually affects only apps that read that setting. TUN takes over matching traffic through a virtual network interface. Neither changes the priority logic of fallback. If an app's traffic isn't reaching the core, changing proxy group settings won't change its egress.

If your configuration actually sets mixed-port: 7890, use the command below to explicitly send a web request through the local proxy. Here, 7890 is an example listening port; use the port in your configuration. Don't use the external controller's port by mistake.

curl -x http://127.0.0.1:7890 -I https://example.com

Step 3: Separate Test Failures from Service Failures

• Every proxy times out: Check your local network, proxy credentials, and access to the test URL first. Don't assume every route failed at the same time.
• The automatic group reports latency, but the site still fails: Check the site's DNS, matched rule, and connection logs. Confirm whether the problem is limited to that site.
• The group keeps switching every few minutes: Keep the same test URL and try increasing url-test tolerance—for example, from 20 ms to 50 ms—then review the next test results.
• Existing tasks don't change after a switch: Retry with a new connection. If necessary, close only the affected connection rather than interrupting everything in progress.

Keep the final choice simple: use url-test to prioritize latency, fallback to prioritize order, and load-balance to distribute connections. Define where traffic enters with rules and keep a manually selectable egress; this is usually easier to maintain than stacking multiple automatic groups. Check the full syntax in the protocol reference, and start with the installation and configuration guide if this is your first setup.