Clash Proxy Groups: url-test, fallback & load-balance Explained

Choose a proxy group for your needs

Want to pick a node yourself? Use select. Want to automatically choose a low-latency node? Use url-test. Want to stick with a primary node and switch only if it fails? Use fallback. Want to distribute connections across multiple nodes? Use load-balance. Each solves a different problem—don’t choose based on whether the name sounds “automatic.”

A proxy group is a collection of nodes or other proxy groups. Rules first decide which group gets the traffic; the group then selects the actual outbound node. For example, MATCH,Proxy sends connections that didn’t match an earlier rule to “Proxy.” It’s not a speed-test command, and it doesn’t automatically route every rule through that group.

Check the core and node names before configuring

The client provides the interface; the core applies the configuration. Similar-looking controls can behave differently because clients may ship with different cores. Check the client’s “About” or core information page to see whether it uses a Clash-compatible core or mihomo, then consult the documentation for that version. The examples below use common Clash proxy group fields; the load-balancing example specifically uses mihomo’s consistent-hashing strategy.

1. Back up your current config file and any overrides saved separately by the client. An override adds to or modifies fields in the original subscription config.
2. Make sure proxies contains working nodes, and copy their full names exactly, including spaces, capitalization, and punctuation.
3. If your nodes come from proxy-providers, reference the provider with use in the group instead of treating the provider name as a node under proxies.
4. Find the client’s local config or override settings. Direct edits to a downloaded subscription file may be overwritten the next time it updates.

select: Switch strategies from one place

select doesn’t compare latency. It lists options in the interface and lets you choose one. Options can be individual nodes or other groups, such as a latency-testing group or a failover group. A practical setup is often a manually selected outer group with automatic groups nested inside.

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto Test
      - Failover
      - Load Balance
      - Hong Kong Primary
      - Japan Backup
      - Singapore Backup

These three subgroups are defined later. In your config, combine the entries for all four groups under a single top-level proxy-groups key. Don’t add the same top-level key repeatedly in one YAML file: duplicate keys can cause parsing errors or overwrite the earlier config.

On first load, the first item in the list is usually selected, but the client may restore your last saved choice. After reordering the list, check the selected item on the proxy group screen. For troubleshooting, temporarily select an individual node to rule out issues caused by nested groups.

url-test: How automatic testing and tolerance work

url-test probes a specified test URL through candidate nodes and selects an outbound route based on the results. It compares response times to that URL, not overall performance across all websites. A node that responds quickly to the test URL may still perform poorly with video sites, game servers, or large downloads.

  - name: Auto Test
    type: url-test
    proxies:
      - Hong Kong Primary
      - Japan Backup
      - Singapore Backup
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

interval is in seconds; tolerance is in milliseconds

• interval: 300: Run a probe every 300 seconds (5 minutes). This doesn’t switch nodes every 300 milliseconds.
• tolerance: 50: Allow a 50-millisecond difference before switching, helping prevent frequent changes when nodes have nearly identical latency.
• lazy: false: Run periodic probes regardless of whether the group has been used recently, which increases network activity while idle. On phones, you can change this to true if needed.

Here’s a hypothetical example of how tolerance works: the current node has 120 ms latency and another has 100 ms, a 20 ms advantage. With a 50 ms tolerance, the current node would usually remain selected. If the other node drops to 60 ms, its 60 ms advantage may trigger a switch. This illustrates the mechanism; it isn’t a real-world test or performance guarantee. The actual choice also depends on probe success, previous state, and the core’s implementation.

Tolerance isn’t a timeout. If a probe to the current node fails, it doesn’t mean “wait until it’s 50 ms slower before switching.” For everyday phone use, start with a 300-second interval and 50-millisecond tolerance, then observe. Reducing the interval to 5 seconds greatly increases the number of probes, but won’t guarantee more stable connections.

fallback: Fail over in priority order

fallback checks nodes in list order and uses the first available one. Its goal is to keep your preferred route, not always pick the fastest. The config below tries “Hong Kong Primary” first. It considers “Japan Backup” only if the primary is deemed unavailable, then “Singapore Backup.”

  - name: Failover
    type: fallback
    proxies:
      - Hong Kong Primary
      - Japan Backup
      - Singapore Backup
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

Suppose the primary route has 180 ms latency and the backup has just 80 ms. As long as the primary is still considered available, it will usually remain in use. Once a later probe detects that the primary has recovered, the group will prioritize it again. For setups that need a consistent exit region or login location, failover is often easier to manage than simply chasing the lowest latency.

Also, “the test URL is reachable” only means that probe succeeded. If a node can reach the test URL but not the service you want, the group may still consider it available. Check the service’s regional restrictions, DNS resolution, and rule matching rather than just shortening the probe interval.

load-balance: Distribute connections, not combine bandwidth

load-balance assigns different connections to candidate nodes according to an algorithm. The example uses consistent-hashing, which maps destinations to routes so that the same type of destination tends to use a consistent exit. mihomo typically maps using information such as the destination’s registrable domain; exact behavior depends on the core version.

  - name: Load Balance
    type: load-balance
    proxies:
      - Hong Kong Primary
      - Japan Backup
      - Singapore Backup
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

Another common option is round-robin, which assigns new connections in rotation. It doesn’t switch nodes every time an established connection sends another chunk of data. For sites where a stable login session matters, connections coming from different regions may trigger extra verification, so don’t apply load balancing indiscriminately to all traffic.

• A single TCP connection downloading one file won’t get three times the speed just because the group contains three nodes.
• Separate downloads or connections to different destinations may be assigned to different nodes, but the distribution isn’t guaranteed to be even by byte count.
• If multiple nodes ultimately share the same constrained upstream route, distributing connections won’t overcome that bottleneck.
• Whether UDP works also depends on the node protocol, server capabilities, and how traffic is routed; the group type alone doesn’t tell you.

Route traffic to these proxy groups with rules

After defining the groups, rules still need to direct connections to them. The two rules below show where they fit in an existing rule set. The example.com domain is for illustrating targeted routing, not a requirement for any real service.

rules:
  - DOMAIN-SUFFIX,example.com,Failover
  - MATCH,Proxy

Rules are checked from top to bottom, and processing usually stops at the first match. Put specific domain rules before the final MATCH. If your existing config includes rule sets, LAN direct routes, or region-based routing, keep them and change only the proxy targets that need updating. Don’t reduce your entire rule set to these two lines just to test a group.

Also make sure the client is in Rule mode. Global mode uses the global proxy, while Direct mode won’t select a proxy route using the rules above. Whether Android traffic is routed through VpnService or desktop traffic through TUN doesn’t change the basic routing logic of these four group types. TUN is a way to capture traffic, not a fifth speed-testing algorithm.

Load, validate, and troubleshoot the config

1. Check the syntax first. YAML uses spaces for indentation, not tabs. All four groups should be under the same proxy-groups list, and group names must be unique.
2. Reload the config. Enable the modified config on the client’s config screen and check for errors such as missing nodes, invalid group references, or unsupported fields.
3. Run a manual test. Start a latency test on the proxy group screen and check that all three nodes return results. Note whether the interface shows results for the group or a separate set of health checks from the subscription provider.
4. Check which rule matched. Open the connection log and inspect the destination domain, matched rule, and final node. Seeing “Proxy” selected doesn’t tell you which member of a nested group was ultimately used.
5. Test failures in a reversible way. Temporarily remove the primary node from a test config, reload it, and start a new connection to see whether the backup works. Restore the original config afterward; don’t alter a live server to simulate a failure.

Proxy groups reverted after a config update

First check whether a subscription update overwrote your local changes. Put custom strategies in an override or merge mechanism supported by the client, and check whether it appends, replaces, or processes them with a script. Clients handle groups with the same name differently, so “saved successfully” doesn’t prove the final config is correct. Inspect the config that’s actually running.

Latency looks fine, but webpages still won’t load

First use select to pin traffic to a known working node, then check the connection log. If the destination domain was incorrectly routed directly, changing the group’s test settings won’t help. If the test URL works but the service doesn’t, check DNS, regional restrictions, and protocol support. Retest after switching between Wi-Fi and mobile data; results from the previous network don’t reflect the new one.

Several groups are probing; phone battery drains faster

If three automatic groups each contain three nodes and probe every 300 seconds, running them separately could mean nine probes per cycle. The provider may also run its own health checks. This is a simplified request-count estimate: the core may schedule or reuse probes, so it can’t be used to calculate battery drain directly. On a phone, one main automatic strategy is usually enough. Consider setting lazy: true for idle groups, and avoid overly frequent provider health checks running at the same time.

A simple starting point for everyday use: keep manual control with an outer select group, and put just one url-test or fallback group inside it. Add a separate load-balance group only when you need to distribute traffic across multiple nodes. Verify that the rules and nodes work before tuning probe settings; troubleshooting is easier than stacking multiple strategies at once.