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

Choosing the right proxy group

Use url-test to automatically select a low-latency proxy, fallback to maintain a fixed primary-and-backup order, and load-balance to distribute separate connections across multiple proxies. All three are proxy groups, not proxy protocols, and none creates new proxies. Each group must reference existing proxy nodes or compatible proxy groups.

Clash is a common name for a family of rule-based proxy cores and their client ecosystem. Clash Meta is now maintained under the name mihomo. Similar-looking clients do not necessarily use the same core. The YAML examples in this guide target mihomo; older Clash cores may support different options and load-balancing algorithms. Check the documentation for your core and validate your configuration.

url-test: Select a proxy by probe latency

url-test sends a request to a specified URL through each member, records the results, and uses them to select a proxy. It works well when proxy performance changes over time and you want to avoid switching manually. The measurement is the time taken for a request to reach the probe target—not a simple ICMP ping from your device to the proxy server.

interval and tolerance use different units

• interval: 300: Run an automatic health check every 300 seconds (5 minutes), not every 300 milliseconds.
• tolerance: 50: Set the switching threshold to 50 milliseconds to avoid frequent changes in response to small latency fluctuations. This is not a probe timeout.
• url: The HTTP or HTTPS address used for health checks. Choose a stable URL with a small response that all group members can reach.
• lazy: false: Disable lazy health checks to keep observing results during validation. With many proxies, this increases background probe traffic.

Suppose the current proxy has a measured latency of 120 ms and another member measures 95 ms—a 25 ms improvement. With a tolerance of 50 ms, do not expect an immediate switch. If the other member measures 60 ms, the 60 ms improvement exceeds that threshold. This example illustrates how the settings relate; it is not a measured result. Actual selection also depends on member availability, probe completion time, and core implementation.

Do not set a very high tolerance to “improve stability.” For example, a value of 500 ms accepts a substantial latency difference. Start by observing the results with interval: 300 and tolerance: 50, then adjust based on network fluctuations. If video buffers or downloads are slow, also check packet loss, bandwidth, and the route to the destination—not just the lowest number in the dashboard.

fallback: Switch between primary and backup in list order

fallback selects the first healthy member in the list. List order determines priority: the first member is preferred while available; if it becomes unavailable, the group tries the second. The goal is not to find the lowest latency, and no tolerance setting is needed.

1. Put your usual first-choice proxy at the top of proxies.
2. List backup proxies in priority order, and avoid relying on members that all depend on the same failure-prone route.
3. Use the same probe URL for all members and start by checking availability at 300-second intervals.
4. Once the primary proxy recovers and passes a health check, subsequent connections can prefer it again.

Suppose the first member probes at 180 ms and the second at 80 ms. As long as the first member is still considered available, fallback will not switch just because the second is faster. If the primary can reach the probe URL but is slow for your actual websites, the group may continue using it.

load-balance: Distribute connections by algorithm

load-balance assigns separate connections to available group members. It suits workloads with multiple concurrent requests where different requests can use different proxy routes. Three lines with their own bandwidth do not give a single download the combined bandwidth of all three.

Common mihomo load-balancing algorithms

This example uses consistent-hashing. How destinations are grouped depends on factors such as whether the domain is visible; it does not mean “one account always uses one proxy.” For payment services, admin logins, or business verification that depend on a stable exit IP, use a fixed proxy or create a separate manual-selection group.

With round-robin, rotation happens when connections are assigned; packets from one TCP connection are not sent through different proxies. Browsers may reuse HTTP/2 connections, so refreshing a page several times may not show strictly alternating public IPs. To verify load balancing, check the client’s connection log and open multiple independent connections.

proxy-groups configuration example

The following proxy-group snippet can be merged into a mihomo configuration. It assumes the proxies section already contains three proxies named “Hong Kong 01,” “Japan 01,” and “Singapore 01.” Replace these names with your actual proxy names, and keep each proxy’s existing server, protocol, and authentication fields.

proxy-groups:
  - name: Proxy Selection
    type: select
    proxies:
      - Automatic Latency Test
      - Failover
      - Load-Balanced Egress
      - DIRECT

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

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

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

The generate_204 URL here is only for health checks; it is not a subscription link or a proxy server. It typically returns HTTP 204. If your network or proxy cannot reach it reliably, use a lightweight probe URL you have verified. Avoid pages that require sign-in, involve complex redirects, or return large responses.

Route traffic through a proxy group

After defining a group, add rules that reference it. The rules below illustrate the syntax; they are not intended to replace your entire rule set. Keep your existing LAN, direct-connection, and service-specific rules, and put the final catch-all rule last:

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

example.com is a sample domain for rule syntax. Replace it with the domain of the service you want to route. MATCH applies to connections that have not matched an earlier rule, so it must come after more specific rules. Set the client to rule mode, then select “Automatic Latency Test,” “Failover,” or “Load-Balanced Egress” under “Proxy Selection” to apply that group to matching traffic.

Combining subscriptions and providers

When loading proxies through proxy-providers, groups usually reference the provider with use rather than listing its name under proxies. These are separate namespaces. The example below assumes your configuration already defines a provider named “Subscription Proxies”:

proxy-groups:
  - name: Subscription Latency Test
    type: url-test
    use:
      - Subscription Proxies
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

This snippet does not include the provider’s download URL, cache path, or update settings, so it is not a complete configuration on its own. If your subscription already supplies a working proxy group, check how it behaves before creating a duplicate. Putting dozens of proxies in several automatic groups can increase probe traffic and make troubleshooting harder.

The provider’s health-check.interval and a proxy group’s interval are separate settings in different parts of the configuration. Changing one does not necessarily change every health-check schedule. Probe coordination and reuse depend on the core implementation. When troubleshooting, check both provider and group settings, and consult the logs.

Subscription updates may overwrite direct edits to the configuration file. To keep custom groups, use the client’s supported override, merge, or extension mechanism. The menu names vary between clients. Start from the “Subscription” or “Configuration” page, open the current configuration’s actions, and confirm whether you are editing a persistent override or a temporary downloaded file.

Validate the configuration and troubleshoot issues

Validate in order—don’t rely on latency numbers alone

1. Back up your current configuration. Keep a working copy and note the core name. For command-line installations, run mihomo -v to check the version.
2. Check syntax and references. In a command-line environment, run mihomo -t -f ./config.yaml. If the configuration uses relative-path resources, validate it from the actual runtime directory and environment.
3. Reload the configuration. Use the client’s reload feature or restart the core according to your deployment method. Saving the file alone may not change the running configuration.
4. Run a health check. Test the group from the proxy-groups page and confirm that at least one member is available. Do not judge the selection by stale latency results before the first check finishes.
5. Check which rules match. In the connection log, inspect the destination domain, matched rule, proxy chain, and final proxy to confirm that traffic is actually using the new group.
6. Retest with a new connection. Close existing connections in the test app and try again. Compare probe status, group selection, and actual access—not just a refreshed page on the same long-lived connection.

Common symptoms and their causes

• “Proxy not found” error: Check that the proxy name matches exactly, including spaces and capitalization, and that a subscription update has not renamed it. If you use a provider, check the use reference.
• Automatic latency-test group does not switch: Check the current mode, whether a rule matches the group, and whether the latency difference exceeds tolerance. Make sure you are not mistaking a similar group with the same name for the active proxy.
• All members time out: Test one proxy on its own, then check the probe URL, DNS, and network reachability. A problem with the shared probe target can make multiple healthy routes appear unavailable.
• fallback always uses the first member: If the first member is still healthy, that is expected—the group follows list priority. To select a lower-latency proxy, use url-test.
• load-balance causes sign-in problems: Check whether the group uses round-robin and whether the service depends on a consistent exit IP. Routing that service through a fixed proxy is more direct than repeatedly changing the balancing algorithm.
• Custom groups disappear after a subscription update: Check whether the changes were made in a file that the update overwrites, and move persistent changes to a client-supported override mechanism.

Choose a configuration that fits your needs: use url-test for everyday browsing, fallback for a fixed primary-and-backup order, and load-balance only when you need to spread multiple connections across proxies. Before changing rules or DNS, see the configuration reference. For installation and import steps, see the client setup guide.