Clash Strategy Group Guide: Differences Between url-test, fallback, and load-balance

What Is a Strategy Group: Decision Groups vs. Execution Groups

In a Clash or Clash Meta (mihomo) config file, the proxies section lists individual proxy nodes, while proxy-groups defines "strategy groups" — logical units that bundle multiple nodes (or other sub-groups) together and decide, according to some rule, which one traffic actually flows through. The rules section usually doesn't point to a specific node at all; it points to the name of a strategy group, and the group decides at runtime where the traffic lands.

There are four mainstream strategy group types: select (manual selection), url-test (automatic speed-based selection), fallback (failover), and load-balance (load distribution). All four share the same field structure (name, type, proxies), but their decision logic is completely different — mixing them up incorrectly leads to problems like "a backup node is configured but it never switches over" or "nodes keep flapping back and forth." Understanding each type's trigger conditions is a prerequisite for building a stable subscription rule set.

select: Manual Selection Groups

select is the most basic type. It doesn't perform any speed testing or health checks on its own — it simply lists a set of nodes or groups for the user to switch between manually in the client interface. By default it shows the first entry in proxies; once switched, the client remembers the last choice (stored as runtime state, not written back into the config file). Its typical use is as a top-level entry point, letting users freely toggle between "auto-select the best node" and "manually pin a specific node."

proxy-groups:
  - name: Node Selection
    type: select
    proxies:
      - Auto Select
      - HK Relay
      - JP Line
      - DIRECT

Because there's no speed testing or failure detection, if a node placed directly in a select group is already dead, traffic will still be forced through it until the user manually switches. In practice, raw nodes are rarely dumped straight into a select group; instead, a speed-testing sub-group (such as the url-test group below) is added as one of the options, balancing manual control with automatic fallback.

url-test: How Automatic Speed Testing and Switching Work

A url-test group periodically sends requests to a configured test URL, records each node's response latency, and automatically selects whichever node currently has the lowest latency — provided the difference exceeds the tolerance threshold. Three fields matter most:

• url: the test target, usually a lightweight, internationally reachable endpoint;
• interval: the test cycle in seconds — too short adds load and battery drain, too long delays failure detection;
• tolerance: the tolerance margin in milliseconds. The group only switches when the new best node beats the current one by more than this margin, preventing constant flapping caused by a few milliseconds of jitter.

proxy-groups:
  - name: Auto Best
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies:
      - HK Relay
      - SG Line
      - JP Line

url-test suits scenarios with many nodes where you want "whichever is fastest" without caring which specific one is used — everyday browsing and video streaming, where latency matters but a fixed route doesn't. Its limitation is that the test result only reflects network conditions at the moment of testing; if the actual destination server's network path differs greatly from the test target's, the "best" node picked may not actually be the fastest for the real workload.

fallback: Failover Trigger Conditions and Delay

A fallback group probes nodes in the order they appear in the proxies list, preferring whichever node comes first and passes the probe. It only moves to the next available node when the currently used one fails the probe (timeout or an unexpected response). It also relies on url and interval for health checks, but the decision logic differs from url-test: url-test compares "which is fastest," while fallback checks "is the one at the front still alive."

proxy-groups:
  - name: Failover
    type: fallback
    url: "https://www.gstatic.com/generate_204"
    interval: 180
    proxies:
      - Primary Line
      - Backup Line A
      - Backup Line B

fallback fits scenarios with a clear priority order where you'd rather "not switch away from the primary line unless truly necessary" — for example, putting a stable but pricier line first and a decent-but-reliable backup after it, only cutting over when the primary genuinely drops, not just because one test cycle showed slightly higher latency. Keep in mind that the health-check interval determines how long failure detection takes — set it too long, and traffic keeps hitting a dead primary line for a while after it fails; set it too short, and probe requests fire too frequently.

load-balance: Two Distribution Strategies

A load-balance group doesn't aim to pick a single "best" node — it spreads requests across multiple nodes, useful when you want several lines to share bandwidth load rather than let one node carry all the traffic for a long stretch. It sets the distribution algorithm via the strategy field, with two main values:

• consistent-hashing: hashes based on the request's destination address, so the same domain/IP consistently lands on the same node — useful for session persistence (e.g. sites that require a stable exit IP to stay logged in);
• round-robin: assigns requests to nodes in rotation, distributing load more evenly, but the same destination may hit different nodes across requests — not suitable for workloads that need a consistent exit IP.

proxy-groups:
  - name: Load Split
    type: load-balance
    strategy: consistent-hashing
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    proxies:
      - Line A
      - Line B
      - Line C

A load-balance group also runs health checks, automatically excluding failed nodes from distribution. It works best when several similar-quality lines (comparable bandwidth and latency) coexist and the goal is spreading load rather than picking the best one. If the lines vary widely in quality, blind load balancing can send requests randomly to the weaker nodes — a worse experience than the more consistent behavior of url-test.

Common Group Combinations and Practical Advice

In practice it's rare to rely on a single type alone — layered combinations are more common: a select group at the top for manual override, several sub-groups with different strategies underneath, and rules dispatching traffic to specific sub-groups by domain or IP. A typical structure looks like this:

proxy-groups:
  - name: Outbound Policy
    type: select
    proxies:
      - Auto Best
      - Failover
      - DIRECT

  - name: Auto Best
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies: [Line A, Line B, Line C]

  - name: Failover
    type: fallback
    url: "https://www.gstatic.com/generate_204"
    interval: 180
    proxies: [Primary Line, Backup Line A]

When choosing a type, think through the goal: if you want "automatically pick the fastest, and I don't mind occasional flapping," use url-test; if you want "a clear primary/backup order, and don't want to leave the primary line easily," use fallback; if you want "several lines carrying load together," use load-balance; if you just want "a manual toggle for the user," use select. All four can nest inside each other — for example, putting a url-test group as one option inside a select group keeps automatic optimization available while still leaving room to manually pin a single node as a fallback.

One more thing worth noting: strategy group decisions only cover proxy-layer connectivity and latency — they don't touch whether rule matching actually hit, whether DNS resolution went through the correct exit, or whether the system routing table is properly in effect under TUN mode. If switching strategy groups doesn't fix the problem, first confirm the rules section actually points the target traffic to that group, then check whether the test URL and tolerance settings are reasonable. Working through one layer at a time is easier than changing several fields at once and hoping something sticks.