Clash Meta Load-Balance Setup: Consistent Hashing Step by Step

Why load-balance differs from url-test and fallback

url-test optimizes for one winner among comparable nodes by repeatedly measuring delay. fallback encodes priority: try A, and only if A fails its probe, try B, then C. load-balance instead answers a different question: How do I use several good exits at once without micromanaging each app? Corporate backbones and CDNs have been doing variants of this for decades; proxy users typically reach for it when a subscription offers several similar premium lines and idle capacity should not sit unused while one node carries everything.

That power comes with responsibility. Spraying TCP flows across unrelated ASNs can trigger fraud heuristics on banks, game anti-cheat systems, and cookie-sensitive SaaS dashboards. That is why Mihomo exposes strategies rather than one blunt “spread everything” knob. Think of load-balance as pooling, and strategy as how picky the pool is about tying flows to a particular member.

Strategies: round-robin, consistent-hashing, sticky-sessions

Official documentation describes three strategies for type: load-balance groups. The differences are not academic; they change what you see in connection logs within minutes.

Round-robin distributes work in rotation across every healthy member of the group. In practice, successive connections tend to land on different exits. That maximizes even usage and can smooth throughput when each hop is an independent tunnel to the same provider region, but it is the harshest option for sites that expect one household IP per session.

Consistent-hashing maps each logical destination to a stable choice of member inside the pool. When the destination is expressed as a domain name, the implementation groups by registrable domain (effective top-level domain plus one label), not by every possible subdomain string in isolation. Multiple hostnames under the same site therefore usually cohere on one egress, which dramatically reduces “why did my OAuth bounce between countries?” surprises compared with naive random picks.

Sticky-sessions goes one step further toward session fidelity: flows that share the same source address and destination are pinned together, with roughly a ten-minute cache window before the mapping can move. That helps chatty clients that open parallel sockets to the same service but is more complex mentally because local LAN clients and NAT timing influence stickiness.

YAML skeleton for a load-balance policy group

A load-balance group lives next to your other symbols under proxy-groups. Members must be names that already exist in proxies or nested groups, spelled exactly the same way your subscription generator emits them—emoji flags and spaces included, if present.

Health probing uses the same url and interval pattern familiar from url-test: pick a small, cache-friendly HTTPS resource that answers consistently from every healthy exit, avoid endpoints that return captchas to datacenter ranges, and resist the temptation to poll every five seconds. Optional lazy: true delays aggressive testing until the group participates in live traffic, which is kinder on laptops.

# Illustrative — replace proxy symbols with your subscription names
proxy-groups:
  - name: LB-GENERAL
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - TOKYO-A
      - TOKYO-B
      - OSAKA-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

rules:
  - GEOIP,CN,DIRECT
  - MATCH,LB-GENERAL

The example sends only the final MATCH bucket through the pool while domestic destinations shortcut to DIRECT. Real profiles usually stack dozens of DOMAIN-SUFFIX and RULE-SET lines above that; the important lesson is that your rules choose which traffic even sees load-balance.

Consistent hashing walkthrough in plain language

Imagine three equal tunnels labeled Alpha, Bravo, and Charlie. For every new flow, the core computes a hash from destination identity and the current member list, then picks one tunnel. As long as the member list is stable, facebook.com and m.facebook.com typically hash to the same registrable domain bucket, so they exit together. If Charlie falls out after failed health checks, surviving members redistribute the space; expect a one-time shift for affected sites until the pool stabilizes again.

This behavior is why consistent hashing pairs naturally with rule slices that isolate sensitive stacks. You might route an entire video vendor to a load-balanced trio in Tokyo while keeping a separate select group for a fragile ticketing site. The hashing math is automatic; your job is not to overload one pool with incompatible policy goals.

When round-robin still earns its keep

Round-robin shines when you have confirmed—by measurement—that targets tolerate fresh egress identities, and you genuinely need to soak multiple uplinks. Package mirrors, firmware blobs, and certain research crawls often qualify. Conversely, interactive OAuth or WebRTC screensharing usually does not. If your logs show captcha loops only while round-robin is enabled, that is a clue to narrow the rule span or switch strategy.

Operators occasionally nest round-robin pools inside a premium-first fallback arm: as long as the primary region stays up, only that pool rotates; if the region browns out, control passes to the next ordered group. The YAML stays readable if you name tiers like LB-APAC versus LB-NA-FALLBACK instead of reusing the word “PROXY” everywhere.

Sticky-sessions and NAT-heavy networks

Because sticky-sessions keys off source and destination together, multiple devices behind the same IPv4 NAT often look like one conversation to the balancer for that destination bucket during the cache window. That can be desirable when a single browser spawns many tabs, but confusing when two humans expect different outcomes through the same policy group simultaneously. If household devices fight over affinity, split them with different rule lines or separate WLAN subnets upstream.

Remember the approximate ten-minute window: long-lived downloads may cross the boundary and migrate members mid-stream. Applications that cannot resume cleanly may need deterministic select groups instead of any load balancer.

Health checks, lazy mode, and UDP caveats

Dead members should leave rotation automatically after probes fail, yet probes measure reachability of the probe URL, not your aunt’s recipe blog. If every member fails simultaneously, revisit DNS, TLS inspection, or whether the provider blocked the probe host. Logging the raw error codes beats swapping strategies randomly.

For UDP-heavy stacks (VoIP, some games, QUIC experiments), consider whether fan-out across asymmetric NAT paths helps. Mihomo allows disable-udp: true on groups when you prefer to starve UDP on that pool rather than debug echo behavior across three tunnels. Document the choice in your private notes; future you will forget why voice broke otherwise.

Mounting the group in rules

Policy groups are meaningless until a rule references their symbol. Typical patterns include DOMAIN-SUFFIX,example.com,LB-GENERAL for a scoped pool, GEOSITE or RULE-SET imports for maintained lists, and a cautious MATCH,LB-GENERAL as a wide net. Order matters: Clash evaluates from top to bottom, first hit wins.

When remote rule providers supply targets that already point to outdated group names, your load-balance block never runs. After renaming groups locally, reconcile every reference—static YAML, script shortcuts, and dashboard overrides. For provider downloads, see the rule-provider path and interval guide so merges stay predictable.

# Illustrative rules — verify group names match your file
rules:
  - DOMAIN-SUFFIX,video.example,LB-GENERAL
  - DOMAIN-SUFFIX,cdn-video.example,LB-GENERAL
  - GEOIP,CN,DIRECT
  - MATCH,LB-GENERAL

Nesting with fallback and url-test

Advanced profiles treat load-balance as a building block. A fallback group may list LB-GENERAL first and a cold-standby select group second, yielding pooled throughput under normal conditions but an operator-chosen escape hatch after outages. A url-test wrapper can choose among multiple load-balance pools tuned to different regions, although the complexity grows quickly—debug with staged YAML, not wholesale paste from forums.

Keep mental clarity: url-test inside load-balance membership is legal when each inner symbol is itself a group, but tracing failures becomes harder. Reserve such nesting for cases where the UI or automation already gives you good visibility.

Step-by-step setup checklist

Pitfalls that masquerade as “load-balance bugs”

Captchas only on balanced traffic. You probably need consistent-hashing or a narrower rule. Everything still uses one node. Another rule higher in the file intercepts first, or the dashboard pinned a mode override. UDP apps flaky. Test with disable-udp toggles and compare. Weird results after subscription refresh. Provider renames removed a member your group still references silently—validate parser warnings.

FAQ

Should I replace all url-test groups with load-balance?

No. Latency racing and pooling solve different problems. Keep url-test where you want automatic winner selection among similar pings, and add load-balance only where multiplexing healthy members helps.

Can DIRECT be a member?

Technically people embed DIRECT in creative chains, but mixing unpooled domestic routes with commercial exits inside one balancer usually contradicts clarity. Prefer separate rules sending LAN and domestic traffic to DIRECT first.

Do forks differ?

Stay on maintained Meta-class cores; after major upgrades, diff your proxy-groups against release notes. Strategy keywords and health defaults evolve slowly but not never.

Operational takeaway

Load-balance groups reward profiles that already separate concerns in rules. Treat them as managed pools, pick a strategy that matches how picky your destinations are about IP stability, and prove behavior in the connections UI instead of assuming YAML magic.

Keep configuration intentional

Many one-click generators bury users under opaque policy names where the difference between pooling, racing, and failover is invisible until something breaks at midnight. That opacity is less a personal failing than a tooling problem: when you cannot see why a hop was chosen, you cannot tune sticky banking flows differently from bulk downloads.

Clash leans on readable YAML, explicit group types, and client panels that expose the active chain. You can merge provider snippets, lift sensitive domains above broad matches, and iterate without relearning a proprietary schema each week—precisely the workflow load-balance depends on.

If you want routing logic that stays legible while your subscriptions evolve, download Clash for free and shape pools with confidence.