Load Balancing & Failover in Practice

Having a lot of nodes doesn't help much if nothing is scheduling them intelligently — manually switching nodes during peak hours, or a node quietly dying overnight while nothing's watching. This article covers three automatic group types that hand all of that scheduling over to Clash, with one goal: faster when things are fast, and invisible when something breaks.

Three automatic group types, recapped

url-test: add tolerance to prevent flapping

By default, url-test has one annoying quirk: when two nodes have close latency, it can flip back and forth between them, and every switch can interrupt an active connection. The fix is adding tolerance:

proxy-groups:
  - name: "Auto Speed Test"
    type: url-test
    proxies: [HK-01, HK-02, Tokyo-01, Singapore-01]
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50   # switch only if 50ms+ faster than current

This means a new node has to beat the current one by more than 50ms before Clash bothers switching. Tune the number as needed — higher is more stable, lower is more aggressive about chasing speed.

fallback: the right way to set up primary/backup lines

If you have one high-quality line and a few ordinary ones, fallback is the right tool — it always prefers the good line, automatically degrades to a backup if that line fails, and automatically switches back once it recovers:

proxy-groups:
  - name: "Primary/Backup"
    type: fallback
    proxies: [HK-Premium, HK-Standard-01, US-Backup]   # priority order
    url: "http://www.gstatic.com/generate_204"
    interval: 120    # check more often for faster failover

Note that the order of proxies is the priority order, and it's worth setting a shorter check interval than url-test so failover kicks in quickly.

load-balance: two hashing strategies

proxy-groups:
  - name: "Load Balance"
    type: load-balance
    proxies: [HK-01, HK-02, HK-03]
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    strategy: consistent-hashing   # or: round-robin

• consistent-hashing: the same destination site always routes through the same node, so login sessions stay consistent — recommended for everyday use.
• round-robin: connections are distributed evenly across nodes, which noticeably speeds up multi-threaded downloads, though some sites may force a re-login if your IP keeps changing.

Combining them: nesting your way to something fast and stable

Proxy groups can reference other proxy groups. Here's a three-layer setup that's popular in the community:

proxy-groups:
  # Layer 1: user-facing switch
  - name: "Proxy Select"
    type: select
    proxies: [Smart Scheduling, HK-Premium, Manual Select]

  # Layer 2: auto scheduling with failover
  - name: "Smart Scheduling"
    type: fallback
    proxies: [Low-Latency Group, Load Balance Group]
    url: "http://www.gstatic.com/generate_204"
    interval: 120

  # Layer 3: workers
  - name: "Low-Latency Group"
    type: url-test
    proxies: [HK-01, HK-02, Tokyo-01]
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

  - name: "Load Balance Group"
    type: load-balance
    proxies: [Singapore-01, Singapore-02, US-01]
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    strategy: consistent-hashing

Everyday traffic runs through the "Low-Latency Group" with automatic speed testing; if that whole group goes down, fallback automatically degrades to the "Load Balance Group"; and if you want to take manual control, "Proxy Select" lets you switch with one click. Each layer has a clear job.

Which type should you actually pick? The short version

If all those parameters left you unsure which type to reach for, here's the simplified rule of thumb: don't care which node, just want the fastest → url-test; you have a clear primary/backup preference → fallback; want to squeeze out maximum bandwidth and don't mind an occasional re-login → load-balance. Most people only need a single url-test group for everyday use — fallback and load-balance are advanced options you add once you have a specific need for them, not something to reach for by default.

A few directions to check if a proxy group isn't working as expected

Set everything up and the scheduling still doesn't seem to be doing anything? Work through these in order:

1. Check whether rules actually reference this group: defining a group doesn't mean anything uses it — some rule (or the final MATCH) has to point to it for it to take effect. This is the step people forget most often.
2. Open the Proxies tab in the dashboard and check the nodes' status: if every node in the group is timing out or offline, url-test/load-balance will naturally look "broken" — there's simply nothing usable to pick from.
3. Confirm the test url itself is reachable: the default generate_204 URL can be blocked on some networks, causing every speed test to time out. Try swapping in a different test endpoint.
4. Check whether fallback's interval is too long: if it's set above 600 seconds, it can take a long time to notice a dead node and switch away from it, which will feel like "nothing is happening."

There's no one-size-fits-all scheduling setup — start with a single, simple url-test group, run it for a while, watch for actual pain points, and then layer in fallback or load-balance where they're actually needed. That's far easier to maintain than building a three-layer structure from day one.

When is it actually worth building a multi-layer setup?

Not everyone needs the three-layer structure described earlier. Before investing time in a complex scheduling setup, ask yourself a few questions: do you have multiple lines of different quality at home or work that need a clear primary/backup split? Do you regularly do multi-threaded downloads where a single node's bandwidth isn't enough? Have you already run into a node quietly dying without anyone noticing right away? If the answer to most of these is "no," a simple url-test group is all you need — there's no reason to pile on complexity just to look more sophisticated. On the other hand, if you're providing network access for a household or a team, the stability gained from multi-layer scheduling is real and worth the setup time.

One more tip: name your groups something intuitive (like "HK-Premium" or "Load-Balance-Singapore"). Six months from now, when you reopen your config file, you'll be able to tell at a glance why you set it up that way — instead of staring blankly at a pile of select/fallback/url-test groups.

Summary

Each of the three group types has its own job: url-test chases "always fastest" and fits most everyday scenarios; fallback is about a clear primary/backup split, for users with a defined line priority; load-balance is about squeezing out bandwidth, for multi-threaded downloads or avoiding per-node throttling. Don't underestimate tolerance and interval — getting them right eliminates a lot of confusing "node flapping" and "switching too slowly" headaches. Starting with a single simple url-test group and layering in more as real needs come up fits how most people actually use this, far more than building out a complex structure all at once.