How to Set Clash Meta load-balance and consistent-hashing Step by Step (2026)

What load-balance groups are for (and what they are not)

A load-balance group answers a different question than url-test. The latter tries to keep you on the healthiest or lowest-latency candidate with periodic probes. A load-balance group intentionally spreads work across several members that you consider simultaneously valid: you are trading perfect optimality against parallelism, egress diversity, or lower per-node contention. Neither mode fixes bad rules; if GEO shortcuts or misplaced MATCH lines swallow your traffic before it reaches an intelligent group, the core never gets a vote. Nail rule order and specificity first, then tune distribution.

This article assumes you merged subscriptions into stable proxy names. If upstream renames thirty nodes overnight, automatic groups degrade just like manual selectors—solve that with mixin patches or generator templates separate from balancer math. Likewise, chaining double hops belongs in relay articles; you can nest a balancer inside richer trees, including relay-based chains, once plain single-hop balancer behavior feels predictable on your LAN.

Strategies at a glance: round-robin versus consistent-hashing

round-robin advances through the member list for successive new flows. Conceptually simple, visibly fair across nodes by connection count—but each new TCP session may emerge from a different public IP unless your provider multiplexes cleanly. Websites that correlate IP changes with fraud heuristics, some banking portals, or certain multiplayer backends can behave badly under blind rotation even when every exit is technically “healthy.”

consistent-hashing derives a deterministic mapping from routing context (typically destination-centric, depending on implementation) to one member bucket. Repeated visits to the same host tend to reuse the same exit, yielding a pragmatic form of sticky behavior without maintaining stateful NAT tables manually. Destinations hashed to different buckets still spread load, but the spread follows hash distribution, not round counts.

Choosing without overthinking telemetry

Prefer consistent-hashing when you want stable-ish sessions to the same CDN origin and fewer surprise IP flips on long-lived sites. Prefer round-robin when endpoints do not care about client IP stickiness or you deliberately want aggressive spread (for example, bulk downloads where each session is independent). Neither replaces url-test if you primarily need resilience to failing nodes—pair them: a small url-test pool for “best region,” then a nested fallback if you want strict disaster ordering. See the dedicated auto failover companion for probe timings; here we omit duplicate tolerance math.

Step 1: Declare a round-robin load-balance pool

Start from proxies exactly as enumerated after merges. Replace sample names (HKG-01, HKG-02) with yours—typos halt parsing with unmistakable YAML errors rather than silently dropping members.

proxy-groups:
  - name: LB-RR-HK
    type: load-balance
    strategy: round-robin
    proxies:
      - HKG-01
      - HKG-02
      - HKG-03

  - name: PROXY
    type: select
    proxies:
      - LB-RR-HK
      - HKG-01
      - DIRECT

Expose LB-RR-HK from a top-level select so you can still pin a single node while debugging. Point rules at LB-RR-HK for automated spreading; keep discrete nodes available for reproducible traceroutes when filing tickets upstream.

Step 2: Declare consistent-hashing with sane probes

Consistent hashing still benefits from light reachability probing when paired with subscriptions that fluctuate Quality-of-Service—even though the mental model differs from chasing minimum ping. Typical community defaults reuse small HTTP probes on a predictable cadence. Adjust cadence downward on unstable uplinks sparingly—each probe traverses membership costs on meters and irritated providers alike.

proxy-groups:
  - name: LB-CH-POOL
    type: load-balance
    strategy: consistent-hashing
    url: http://www.gstatic.com/generate_204
    interval: 240
    proxies:
      - HKG-01
      - HKG-02
      - HKG-03

If certain members block the probe endpoint entirely, tests may mark paths inconsistently versus real browsing—swap the probe target for one your entire pool can reach quietly, analogous to anecdotes in failover guides, just without rewriting that article's parameter playbook here.

Step 3: Wire rules once, avoid scatter

Centralize balancer names in your high-traffic clauses; duplicate per-domain scattering makes subscription refreshes brittle. A compact pattern separates domestic direct traffic early, pushes foreign general traffic toward LB-CH-POOL, then falls through to guarded defaults below MATCH.

rules:
  - DOMAIN-SUFFIX,google.com,LB-CH-POOL
  - GEOIP,CN,DIRECT
  - MATCH,LB-CH-POOL

If GEO lines trigger before intentional domain specificity, hashing never runs—those situations look like broken balancers despite perfect YAML—so loop back to GEO ordering guidance instead of iterating hash strategies blindly.

Step 4: Nest balances under failover when priorities matter

Balancers answer “how inside this sibling set,” not “Hong Kong versus Singapore geopolitically.” When you genuinely need hierarchical priorities—premium ring first, mass-market pool second—wrap pooling inside fallback. The following illustrative block defines two region pools separately, then layers an outer failover:

proxy-groups:
  - name: LB-CH-HK
    type: load-balance
    strategy: consistent-hashing
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - HKG-01
      - HKG-02

  - name: LB-CH-SG
    type: load-balance
    strategy: consistent-hashing
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - SGP-A
      - SGP-B

  - name: EXPORT-MIXED
    type: fallback
    url: http://www.gstatic.com/generate_204
    interval: 90
    proxies:
      - LB-CH-HK
      - LB-CH-SG
      - DIRECT

Outermost fallback advances when an entire pooled path fails probing expectations; inner load-balance retains spread within tiers. Document why intervals differ tier-to-tier—future merges should not flatten them casually.

Verification you can rely on logs for

After reload, skim parse errors immediately—balancer groups choke on dangling references early. Attach a dashboard such as the setup in the external-controller and YACD article to correlate active outbounds with policy names visually. Rotate through several distinct destinations and confirm that round-robin rotates per new flow boundaries while consistent-hashing keeps recognizable destinations anchored until membership changes perturb the ring.

Common pitfalls and misreads

• Thinking hashing equals security: predictability aids session convenience, not anonymity—correlating flows across sites may become easier relative to perpetual single-node use cases.
• UDP and QUIC divergence: Some flows exercise different code paths—if voice or gaming misbehaves while HTTPS looks fine, check capture mode docs and UDP-specific threads rather than only balancer strategy.
• Stale membership ghosts: After refresh, orphaned names inside proxy-groups break validation—automate merges or annotate local overrides.
• Unbounded probe frequency: Aggressive timers across dozens of members resemble operational noise; raise intervals before blaming hash logic.

When round-robin shines versus when hashing saves your evening

Think in workloads, not vibes. Bulk parallel downloads across many discrete files often tolerate per-connection IP diversity because servers treat each TCP session independently. In that posture, round-robin can keep any single egress from absorbing the entire queue depth—particularly when your vendor advertises many mid-tier boxes with similar throughput ceilings. Conversely, heavyweight single-page apps that multiplex dozens of HTTPS calls against one origin benefit from steady exit identity; here consistent-hashing reduces unexplained logout prompts and anti-bot friction triggered purely because your egress IP jittered twice per minute during an ordinary scroll session.

API clients that authenticate with keyed cookies or short-lived bearer tokens rarely care about hashing versus round-robin until the remote service ties sessions to client subnet reputation. Observability tooling helps: compare response headers across repeated calls versus destinations. When error rates correlate with rotation epochs rather than time-of-day congestion, you probably asked round-robin to solve a sticky-session problem—or your provider has tightened IP reputation precisely because many users multiplex cheap shared nodes aggressively.

Households blending gaming consoles, conferencing, and workstations on one profile sometimes split unrelated goals: keep interactive UDP-centric traffic on predictable paths while letting general browser traffic roam a hashing pool upstream of GEOIP directs. That split is policy design, not a single knob—document which rules send each family of apps to which proxy-groups label so collaborators do not “optimize” you back into naive MATCH,PROXY umbrellas that bypass your balancer deliberately.

Rolling back cleanly if load-balance fights your reality

If symptoms appear immediately after introducing a balancer, snapshot the prior YAML—even a commented block at the tail of your mixin preserves rollback clarity. Symptoms that warrant retreat include cascading HTTP 429 responses from APIs that dislike bursty parallelism, repeated identity challenges on portals that keyed on session IP prefixes, or measurable packet loss concentrating on whichever node round-robin momentarily overloaded while siblings sat idle cluelessly waiting their turn due to artificially short connection lifetimes.

First confirm your issue is balancer-specific versus DNS or GEO ordering by temporarily pointing the same problematic rule set at an explicit leaf node inside a neutral select. Regression isolates hashing effects from unrelated drift. Second, shorten membership lists deliberately—fewer sharper nodes often beats wide pools with flaky tails. Third, reintroduce url-test umbrellas only where failover semantics truly beat fan-out semantics; redundancy and parallelism answer orthogonal questions despite sharing YAML surface area under proxy-groups.

Telemetry patience matters during experiments: dashboards show aggregate choices, whereas applications surface human-perceived regressions minute by minute. Cross-check both before concluding your balancer tier needs surgery.

Quick contrast with url-test and plain select

Upstream documentation versus installer habits

Field-level truth for balancer knobs moves with Mihomo revisions—consult the Wiki shipped with your build when in doubt about optional keys. Binaries belong on our official download page; GitHub remains excellent for changelog archaeology and reproducible builds rather than steering casual installers through release asset menus.

Structured reference material also lives alongside our site configuration docs when vocabulary between UI and YAML needs alignment mid-edit.

Summary

load-balance gives Clash Meta operators a way to use several nodes concurrently: round-robin rotates fresh flows across members fairly, while consistent-hashing maps destinations to repeatable exits approximating session stickiness without manual pinning. Declare groups under proxy-groups, reuse compact probe stubs when hashing pairs with flaky subscriptions, keep rules pointing at umbrella balancer names rather than cloned node lists, and combine with nested fallback when tiered resilience matters beyond intra-pool hashing. Respect GEOIP ordering, QUIC realities, subscription churn—and lean on companion pieces for deep-dive failover probes rather than duplicating tolerance essays here.

When spreadsheets of nodes shrink to a disciplined profile that spreads load intelligently, maintenance stops feeling like endless clicking and starts resembling infrastructure you can reason about from logs alone.

→ Download Clash for free and experience the difference