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

Inside proxy-groups for Clash and Clash Meta (mihomo core), besides the manual select type, there are three automated group types: url-test, fallback, and load-balance. All three run periodic health checks on the nodes in a group, but what they do with the results is completely different — one picks the fastest, one guarantees an available node, and one spreads traffic across several. Miss this distinction and copy-pasting a config snippet from the web can leave you puzzled by things like "I set up auto speed-test, but it keeps using the same slow node." This article breaks down the parameters for each type and gives ready-to-use YAML you can drop straight into a config.

Three types, three different problems

One thing first: all three group types only make sense with at least two usable nodes in the group — with a single node, they behave exactly like select. Their real difference is the logic behind "which node gets picked":

• url-test: periodically sends a test request to every node in the group and picks the one with the lowest latency as the current exit. The goal is "always use the fastest line."
• fallback: checks node availability in the order they're listed and uses the first one that passes, only moving to the next when the current node fails. The goal is "always have a working node" — not speed, but reliability.
• load-balance: doesn't judge "which is best" at all. Instead it distributes different requests across multiple nodes in the group by algorithm. The goal is "spread the load" so no single node stays under constant pressure or gets singled out for throttling.

Which type to pick depends on whether you value latency, stability, or load spreading most — the three aren't interchangeable.

url-test: latency-first auto routing

url-test is the most commonly used automated group type, ideal when you have a pool of nodes and just want the client to always use whichever one has the lowest latency, without manual switching. A typical config:

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

Key fields explained:

• url: the target address for the speed-test request. Usually a lightweight endpoint that's reachable outside China; a successful response marks the node available, and the response time becomes the latency reading.
• interval: the test cycle, in seconds. Too short adds probing load on nodes; too long means the client is slow to respond to latency changes. Common values range from 180 to 600.
• tolerance: the tolerance margin, in milliseconds. A switch only triggers when the newly measured latency is lower than the current node's by more than this margin. This prevents the exit from flip-flopping every time latency jitters by a few milliseconds, which would otherwise cause repeated connection drops.
• lazy: when set to true, scheduled testing only runs while the group is actually in use; an unselected group pauses probing to cut down unnecessary requests.

fallback: switching that guarantees availability

fallback is built for "primary/backup," not "pick the best." It checks nodes in the order they appear in proxies, starting from the first, and won't proactively jump to a lower-latency node further down the list as long as the currently used node still connects. Only when the current node fails does it search forward for the first available one. Example:

proxy-groups:
  - name: Fallback-Link
    type: fallback
    proxies:
      - Primary-Shanghai-Relay
      - Backup-Tokyo-Direct
      - Backup-Seoul-Direct
    url: http://www.gstatic.com/generate_204
    interval: 180

fallback has no tolerance parameter because it never compares latency — it only checks "connected" or "not connected." This type suits scenarios that demand connection stability and dislike frequent switching, such as long-running background downloads or services that need to keep a session alive. List order is priority order: put the node you trust most, or care about most, at the top.

load-balance: spreading traffic across nodes

load-balance doesn't try to pick "the best." It distributes different requests across several nodes in the group, and it's typically used when you have several nodes of similar quality and want to keep any single one from carrying sustained heavy load. Example config:

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: consistent-hashing

strategy determines the distribution algorithm, and there are two common ones:

• consistent-hashing: assigns a node based on the hash of source and destination address, so the same connection session keeps hitting the same node while it's active. This suits scenarios that need session persistence — for instance, sites where login state depends on a consistent exit IP.
• round-robin: assigns nodes in rotation, handing each new connection to the next node in sequence. Distribution is more even, but the same destination isn't guaranteed to always go through the same node.

load-balance also runs periodic availability checks; a node that fails is temporarily excluded from the rotation and rejoins once it recovers. The core difference from url-test is this: url-test always uses one single "currently best" node, while load-balance uses several nodes at once to split the load.

Quick parameter reference and common pitfalls

A few pitfalls worth watching for:

1. Listing nodes in the wrong order inside a fallback group, so a higher-latency backup node ends up being preferred — fallback never compares latency, it only follows list order and whether the current node has failed.
2. Setting tolerance to 0 makes a url-test group switch the moment any node in a new test round is even 1 millisecond faster than the current one, causing the exit to jump around constantly. Keep at least 30–50 ms of margin.
3. Mixing nodes with wildly different latency inside a load-balance group (say, a high-latency relay node alongside a low-latency direct one) — spreading traffic that way often feels worse overall than just picking the single best node. load-balance works best with nodes of similar quality.
4. Setting interval too low (under 10 seconds) makes probing requests too frequent, and some proxy providers or self-hosted nodes may start rate-limiting as a result. Staying above 120 seconds is a safer baseline.

Which one should you use

If you only remember one line: pick url-test for latency, fallback for stability, load-balance for spreading load. In practice you can combine them — for example, run a url-test group as your everyday exit, then set up a separate fallback group with a few reliable direct nodes reserved for scenarios that need long-lived connections (download managers, remote desktop), routed there specifically through rules. This balances speed and stability. Once the group type is chosen, pairing it with rule sets to route different domains and apps to the right group is what completes the routing logic — the group type itself only answers "which node, or nodes, should this class of traffic use."