Clash Proxy Group Types Explained: url-test vs fallback vs load-balance

Proxy Groups: Where Traffic Forks

In a Clash config, rules decide which type of traffic goes where, while proxy-groups decide which node the traffic ultimately exits through once it reaches a given group. Besides the manually-picked select group, the Clash core (mihomo included) also ships three automatic group types: url-test, fallback, and load-balance. None of them require manual node switching, but their auto-selection logic is completely different: one watches latency, one watches uptime, and one spreads the load.

Short version first, details below: for everyday browsing where you just want it to work, use url-test; if you have a clear primary node and only want automatic failover as a safety net, use fallback; if you want to combine the bandwidth of multiple lines, use load-balance.

url-test: Lowest Latency Wins

url-test is the most commonly used automatic group. It works in two steps: every interval seconds, each node in the group independently sends a probe request to the address in url and records the round-trip time; whenever a new connection enters the group, the core routes it to whichever node had the lowest latency in the most recent test and passed the health check.

Two parameters make or break how well it performs:

• tolerance: the tolerance margin, in milliseconds. A candidate node must beat the current node's latency by more than this margin before a switch happens. When several nodes have similar latency, skipping this leads to constant flip-flopping and connections getting rebuilt over and over.
• lazy: when enabled, speed tests only run while the group is actually carrying traffic; when disabled, it keeps probing in the background on the interval schedule. For subscriptions with lots of nodes, keeping this on is recommended to cut down on unnecessary probe traffic.

proxy-groups:
  - name: Auto Select
    type: url-test
    proxies:
      - Hong Kong 01
      - Hong Kong 02
      - Japan 01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 100
    timeout: 5000

One common misunderstanding needs clearing up: lower latency does not mean higher speed. A 204 probe only measures the round trip of a tiny request — it reflects how responsive a line is, not how much bandwidth it has. If a large download is slow, it's not necessarily the wrong node — the node itself may simply have limited bandwidth.

Best fit: when you have several similar-quality nodes in the same region and just want it to pick the fastest one for everyday browsing, streaming, and normal downloads. mihomo also supports expected-status, which lets you specify the expected response status code — a probe returning anything else is treated as a failed check, which is useful for catching lines that connect but respond abnormally.

fallback: Switch Only When the Primary Dies

fallback doesn't compare latency at all — it only checks whether a node is reachable. It strictly follows the order of the proxies list: it always uses the first node in the list that passes its health check. Once the current node fails health checks consecutively up to the max-failed-times limit, it's marked unavailable and traffic automatically drops to the next available node; once an earlier node in the list recovers, traffic automatically switches back to it.

proxy-groups:
  - name: Failover
    type: fallback
    proxies:
      - Primary Line
      - Backup Relay A
      - Backup Relay B
    url: http://www.gstatic.com/generate_204
    interval: 120
    max-failed-times: 3

The key difference from url-test: url-test picks the fastest among all working nodes, while fallback only cares about order — even if a backup node has lower latency, it will never proactively switch to it. This fits a common setup perfectly: the primary is an expensive, stable dedicated line, and the backup is an ordinary line you never want traffic to touch unless it absolutely has to.

The health-check interval determines how fast a failure is detected, so fallback's interval can be set lower than url-test's — say, 120 seconds. Going much lower rarely helps and just adds more probe traffic and log noise.

load-balance: Spreading Connections Across Multiple Lines

The first two group types only ever use one exit node at a time. load-balance instead keeps every node in the group active simultaneously: each new connection is assigned to a node according to the strategy you specify.

• consistent-hashing (default): hashes the destination address, so connections to the same site consistently land on the same node. This keeps the exit IP stable from a given site's perspective, which suits everyday mixed usage.
• round-robin: rotates through nodes connection by connection. When a multi-threaded download tool opens dozens of connections at once, traffic gets spread evenly and the bandwidth of multiple lines effectively stacks together.

proxy-groups:
  - name: Load Balance
    type: load-balance
    proxies:
      - Node A
      - Node B
      - Node C
    url: http://www.gstatic.com/generate_204
    interval: 300
    strategy: round-robin

The trade-off is just as obvious: different connections exit through different IPs. For anything sensitive to a consistent IP — online banking, payments, account logins — a constantly changing exit address can trip risk-control systems, at best forcing re-verification and at worst triggering a temporary lockout. The safer approach is to route those domains to a fixed node or direct connection with a dedicated rule, and let only the rest of your traffic go through the load-balance group.

Which One Should You Pick

The short version: nodes are similar quality and you want simplicity — url-test; nodes have a clear pecking order and you only want failover as a backup — fallback; you want maximum throughput and can live with a shifting exit IP — load-balance. If you're not sure, start with a url-test group — it covers the vast majority of everyday needs.

Combining Groups and Common Pitfalls

Proxy groups can be nested inside each other, and a group name itself counts as a valid member. A common pattern is to nest the automatic groups inside a select group, and have rules reference only the outermost one:

proxy-groups:
  - name: Main Proxy
    type: select
    proxies:
      - Auto Select
      - Failover
      - DIRECT
  - name: Auto Select
    type: url-test
    proxies:
      - Hong Kong 01
      - Hong Kong 02
      - Japan 01
    url: http://www.gstatic.com/generate_204
    interval: 300

Day to day you run on "Auto Select," and whenever you need a fixed exit node you just switch to "Failover" or DIRECT from the client's proxy page — no need to touch the rules file at all. mihomo users can also use the use field to pull in proxy-providers, bulk-adding subscription nodes into a group, and pair it with a filter regex to avoid maintaining node names one by one.

Edits Get Overwritten by Subscription Updates

If you edit a profile generated from a subscription directly, your changes will be wiped out the next time that subscription updates. For customizations you want to keep long-term, use the merge (override) feature on Clash Verge Rev's Profiles page and put your proxy groups into an extension config instead of the subscription file itself.

Lower interval Isn't Always Better

If the probe interval is too short, dozens or even hundreds of nodes end up hammering the probe address in rotation, burning CPU, battery, and traffic — and flooding your logs with health-check entries. Around 300 seconds is a reasonable starting point for everyday use; fallback can go a bit lower, but going under 60 seconds isn't recommended.

The Probe Address Itself Needs to Be Stable

All three group types rely on health checks: the probe request goes out through the node, and an unreachable address gets the node marked as failed. Pick a 204 probe address that's reliably stable over time. If an entire group of nodes suddenly "times out" all at once, suspect the probe address first before blaming the nodes.

Group Names Must Match Exactly

The group name referenced in rules must match the name in proxy-groups character for character — even one extra space will cause a match failure. After editing your config, check the Logs page; loading errors will point straight to the offending line.