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

The three proxy groups: start with how you want traffic routed

For everyday browsing, use url-test to automatically pick a low-latency node. For a primary connection with a backup that takes over only when it fails, use fallback. To distribute different connections across multiple nodes, use load-balance. All three are proxy-groups, but they choose nodes differently—don't rely on whether your client labels a group “automatic.”

Proxy groups choose an outbound; they don't automatically route app traffic through Clash. The system proxy or TUN captures traffic, and under rule mode, rules route each connection to a specific proxy group. If a rule points to DIRECT, changing these groups' health-check settings won't affect that connection's route.

Group type	How it selects	Best for	Main limitation
`url-test`	Measured latency and switching tolerance	Web browsing and automatic routing	Low latency doesn't mean high throughput
`fallback`	List order and node health	Primary connection with a standby	A faster standby won't take priority
`load-balance`	Balancing strategy and node health	Multiple connections and destinations	Doesn't combine bandwidth for a single connection

url-test: choose by latency and use tolerance to limit switching

url-test sends requests to a test URL through candidate nodes, then picks a node based on the results. The measurement is the time taken to reach that test endpoint—not download speed or the average experience across all websites. A node's route to the test site may be good without being equally good to a video service or code repository.

A good starting point: a 300-second interval and 50 ms tolerance

This is a group-definition snippet, not a complete subscription. The example nodes “Node-A,” “Node-B,” and “Node-C” must already be defined in your existing proxies list, with names that match exactly. Add this to your existing proxy-groups list; don't create a duplicate top-level key.

proxy-groups:
  - name: Auto Low Latency
    type: url-test
    proxies:
      - Node-A
      - Node-B
      - Node-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

interval: 300: Runs a health check every 300 seconds (5 minutes). This is not the timeout for app requests.
tolerance: 50: Sets a 50 ms switching threshold to avoid switching repeatedly for a marginally faster node. It isn't a latency limit and doesn't exclude nodes over 50 ms.
lazy: false: Runs checks at the configured interval even when the group isn't in use, making results easier to monitor. With many nodes, this generates more test requests.
url: Choose a lightweight, consistently reachable test endpoint. The example endpoint typically returns HTTP 204. Avoid pages that require sign-in, redirect frequently, or trigger bot checks.

For example, with all other selection factors equal, suppose the current node measures 120 ms and a candidate measures 105 ms. A 15 ms difference usually isn't enough to trigger a switch with a 50 ms tolerance. If the candidate drops to 60 ms, switching becomes more likely. These figures illustrate how the setting works; they aren't measurements from this site. The actual choice depends on the current core state and logs.

When latency alone isn't enough

Large downloads, long video streams, and remote desktops also depend on bandwidth, packet loss, and jitter. Use an automatic group to find available nodes, then compare throughput against the same destination at the same time. For sessions that require a fixed exit IP, choose a node manually or use a group with an explicit primary-and-backup order.

fallback: choose the first available node in the list

fallback is about priority. If the first node in the list passes its health check, it stays in use. A later available node is selected only when the one ahead of it is unavailable. Put the primary node first, followed by backup nodes in priority order.

proxy-groups:
  - name: Primary Failover
    type: fallback
    proxies:
      - Node-A
      - Node-B
      - Node-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

Suppose Node-A measures 180 ms and Node-B measures 75 ms. As long as A is healthy, the group still prefers A. Adding tolerance here won't make this a latency-based group. If you want the fastest node, use url-test instead.

Recovery and failure behavior

Once the primary node passes its health check again, subsequent routing will prefer it. Failure detection and recovery depend on the checks and core behavior, so they may not happen immediately.
Group switches mainly affect new connections. An established TCP connection won't move to another node; after the original connection drops, the app will usually need to reconnect.
A reachable test endpoint only means that the health check passed. If a specific site is unreachable, the primary node may still be marked healthy. Check the destination or the rules in that case.

For ongoing sessions such as calls or remote terminals, failover is a recovery path—not seamless migration. Before deploying, you can temporarily disable the primary node's test, check whether new connections use the backup, then restore the primary and verify its priority. Avoid changing DNS and TUN settings at the same time, or it will be harder to tell which layer caused the change.

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

load-balance distributes traffic across available members according to strategy. It doesn't combine multiple routes to speed up a single file transfer. A single TCP connection still uses one selected outbound. Multiple nodes may be used when the app itself opens multiple connections.

proxy-groups:
  - name: Multi-Connection Balancer
    type: load-balance
    proxies:
      - Node-A
      - Node-B
      - Node-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

consistent-hashing vs. round-robin

Strategy	How it distributes traffic	When to use it
`consistent-hashing`	Uses destination information for consistent hashing, so the same destination usually maps to the same node	Consider this when you want to avoid frequent exit changes for the same destination
`round-robin`	Assigns new connections across available members in turn	Works for independent connections that can use different exit nodes

With round-robin, multiple new connections to the same website may use different exit IPs. Avoid it for services with strict login risk controls, payment pages, or APIs that require a consistent IP. Consistent hashing reduces changes, but can't guarantee a fixed exit if member health changes or the node list is updated.

If all three nodes share the same upstream bottleneck, distributing connections won't create extra bandwidth. To evaluate the result, check the actual node shown in the connection panel, throughput to the destination, and failure rate—not just whether all three members show a test latency.

Connect automatic groups to your rules while keeping a manual selection option

You can keep all three automatic groups and use a select group to choose which strategy is active. This lets you switch between everyday browsing, primary-and-backup routing, and multiple connections without repeatedly editing rules. Combine the snippet below with the three group definitions above; it isn't a complete configuration on its own.

proxy-groups:
  - name: Proxy Outbound
    type: select
    proxies:
      - Auto Low Latency
      - Primary Failover
      - Multi-Connection Balancer
      - Node-A
      - DIRECT

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

Here, MATCH only demonstrates how a catch-all rule can reference a proxy group; it isn't a complete split-routing setup for traffic inside and outside mainland China. Existing subscriptions often include rules for local networks, sites in mainland China, and rule sets. Keep your current routing logic and change only the targets for rules that need a proxy to “Proxy Outbound.” Rules are checked from top to bottom, so a broad rule placed too early can prevent later rules from matching.

Back up a working configuration and make sure the core recognizes all three automatic groups and their member names.
In the client's Proxies or proxy groups page, select a target group such as “Auto Low Latency” for “Proxy Outbound.” Names and menu locations vary by client.
Use rule mode, visit a test website, then check the matched rule, proxy chain, and final node in the connection details.
Select another proxy group and verify it with a new connection. Existing connections may keep using the original node, so don't draw conclusions from a single page refresh.

To check whether app traffic is going through the proxy, follow the system proxy setup steps to verify how traffic is captured, then use the latency test steps to check the group status. Don't switch to global mode instead of checking which rule matched.

Common mistakes: intervals, missing members, and subscription overwrites

Setting interval in milliseconds

interval: 300000 means 300,000 seconds—not 5 minutes. For a check every 5 minutes, use 300. Don't set it to 1 just to make it “react faster”: the more nodes you have, the more test traffic it generates, and frequent checks won't fix congestion on the node itself.

Naming nodes that aren't defined in the configuration

proxies references the names of existing nodes or proxy groups, not subscription URLs. Names must match exactly, including capitalization, spaces, and symbols. Groups must not reference one another in a loop—for example, “Proxy Outbound” includes “Auto Low Latency,” which in turn includes “Proxy Outbound.”

If your nodes come from proxy-providers, use use to reference an existing provider, for example use: [Subscription Nodes]. “Subscription Nodes” must match an existing provider key. Provider-level health-check settings and group-level checks are separate configuration layers; changing the group's check interval doesn't necessarily change the provider checks.

Custom proxy groups disappear after a subscription update

Direct edits to files generated from remote subscriptions are often overwritten during the next update. Use the client's supported override, merge, or extension mechanism instead; these options vary by client. After saving, validate the configuration, then update the subscription and confirm that group definitions, rule references, and manual node selection are still present.

Choosing a group: match the level of automation to the job

Everyday browsing and general proxy use: Start with url-test, a 300-second interval, and 50 ms tolerance. Watch for frequent switching.
Primary and backup connections: Choose fallback, put the primary node first, and test both failover and recovery.
Multiple destinations and connections: Consider load-balance. Start with consistent hashing, then decide whether round-robin is suitable for your use case.
Account sessions and fixed exit IPs: Keep a direct node selection option in select. If needed, route relevant domains through a dedicated group.

Proxy groups should match your routing needs—not chase the lowest test latency in every situation. Keep a working configuration to roll back to, change one setting at a time, and verify the final outbound with a new connection. This makes it easier to link configuration changes to changes in performance.