Clash Policy Group Comparison: url-test, fallback & load-balance Use Cases

01 · Starting Point

The Three Policy Group Types Solve Different Problems

Many people, the first time they touch a Clash or Clash Meta (mihomo core) configuration file, treat the type field under proxy-groups as "just pick some automatic mode" — then swap it out and try something else if it doesn't work. Trial and error gets you there eventually, but it's inefficient, and picking the wrong type can actually land you in a new problem — for example, wanting low latency but choosing fallback, which is really about "as long as it connects," so latency doesn't improve noticeably; or wanting to spread bandwidth load but choosing url-test, which ends up piling all the traffic onto whichever one or two nodes test fastest.

The core difference between the three can be summed up in one line each:

• url-test cares about "who's fastest" — it continuously tests latency and automatically switches to the lowest-latency node.
• fallback cares about "who works" — it goes down the configured order and picks the first healthy node, without actively chasing speed.
• load-balance cares about "how to split things up" — it spreads concurrent requests across multiple nodes by algorithm, rather than optimizing for a single best node.

Next, we'll break down the decision logic and key parameters of each one. Once you understand the logic, picking the right type mostly stops being a matter of trial and error.

02 · url-test

url-test: Latency-First Automatic Selection

url-test periodically sends an HTTP request to every node in the group (the target is set by the url parameter), records the response time as that node's latency, and switches current traffic to whichever node has the lowest latency. It's the most common implementation behind "the panel shows auto-tested node latency" style UI features, and it's usually the first automatic policy group a newcomer encounters.

Key parameters:

tolerance is the parameter that's easiest to overlook but has the biggest impact on the actual experience. Without a tolerance margin, a 1ms latency difference between two nodes is enough to trigger a switch, and frequent switching interrupts long-lived connections (video streaming, downloads) and forces them to reconnect. Setting a tolerance of around 50ms is basically telling the client "don't bother switching unless the difference is meaningful" — you trade a bit of theoretical optimality for connection stability.

proxy-groups:
  - name: Auto Select
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - HK-01
      - SG-02
      - JP-03

Best for: latency-sensitive use cases where a single node's bandwidth is enough, such as web browsing, messaging, or gaming. It doesn't actively split traffic — everything defaults to whichever node is currently "best," which is the opposite of what load-balance does.

03 · fallback

fallback: A Failover Mechanism Focused on Availability

fallback also runs health checks on the nodes in a group, but its decision logic isn't "pick the fastest" — it's "go down the list and pick the first one that works." The order of the proxies list in the configuration is the priority order: the client always tries the topmost node first, and as long as it passes the health check (connectivity checked the same way, via the url parameter), it keeps using it — it won't switch away just because a node further down the list happens to have lower latency. Only when the current node is deemed unavailable does it move on to try the next one in order.

proxy-groups:
  - name: Stable Failover
    type: fallback
    url: http://www.gstatic.com/generate_204
    interval: 180
    proxies:
      - Primary-Dedicated
      - Backup-HK
      - Backup-JP

Best for: situations where you have a clear "preferred node" (a dedicated line, a self-hosted relay, a corporate network egress) and you just want an automatic fallback if it drops, rather than having the system constantly compare latency across multiple nodes. This is common where connection stability matters more than raw speed — long-running remote meetings that need to stay connected, packet-loss-sensitive voice calls, or cases where you trust one specific line and only want the other nodes as emergency backup.

One thing worth noting: interval controls how often health checks run. Setting it too long means a node can already be dead while the client hasn't noticed yet, causing a stretch of failed connections; setting it too short adds unnecessary check traffic and overhead. Somewhere in the 120–300 second range is generally a reasonable balance.

04 · load-balance

load-balance: Spreading Traffic Across Nodes

load-balance doesn't aim to pick a single "best node" — its goal is to spread different connection requests across multiple nodes in the group, so traffic doesn't stay concentrated on one exit long-term. The strategy parameter determines the distribution algorithm; the two most common are:

• consistent-hashing: assigns a node based on a hash of information like the connection's source address. Connections from the same source tend to land consistently on the same node, which fits use cases that need session persistence.
• round-robin: assigns new connections to the next node in sequence, giving a more even spread, but doesn't guarantee that connections from the same source always hit the same node.

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

Best for: situations where a single node's bandwidth or concurrent-connection limit gets hit easily — multiple devices sharing the same subscription, heavy download activity, or nodes that themselves cap concurrent connections. Spreading traffic across multiple nodes reduces the pressure on any single one, so overall throughput can get closer to the sum of several nodes' bandwidth, instead of being capped by whatever one node can handle.

05 · Comparison

Parameters and Use Cases at a Glance

In real configuration files, these three types can absolutely be combined — you don't have to pick just one and use it everywhere. For example, you might use fallback as the top-level entry point, with the backup line itself being a url-test group that picks the fastest among several overseas nodes; meanwhile, a rule that routes download-tool traffic separately might point to a load-balance group, so a large download doesn't eat up a single node's bandwidth and hurt the experience for other apps. This kind of layered design fits real-world usage better than a single flat policy group, and it's a structure you'll often see when looking at more elaborate shared configuration files.

One more detail that's easy to miss: if the address pointed to by the url parameter is itself unstable or rate-limited, it directly skews the decisions of all three policy group types — url-test will measure inflated latency, fallback may misjudge a healthy node as unavailable, and load-balance's health checks will be distorted too. Using a lightweight, fast-responding, widely reachable check address is a precondition for all three automatic policy group types to work correctly, and when troubleshooting "automatic selection isn't picking the right node," the check address's own availability should be on the checklist.