Clash Proxy Groups (proxy-groups): Complete Guide from Basics to Advanced

What are Clash proxy groups?

In a Clash configuration file, the proxy-groups section defines virtual proxies. These entries are not servers by themselves—they are scheduling policies over one or more real proxies (or other groups). When a rule sends a connection to a group name, Clash resolves that group according to its type and picks the final node.

Think of it in one line: rules decide whether traffic should use a proxy; proxy groups decide which proxy actually carries it. That separation is why getting proxy-groups right matters for gaming latency, streaming unlock, and day-to-day stability. If you are new to the ecosystem, skim our Clash tutorial first, then come back here to tune groups with confidence.

Most community profiles you download are already split into layers: a small set of “entry” groups that users switch in the UI, plus hidden regional pools that auto-test in the background. Learning to read that structure helps you merge upstream updates without breaking your own tweaks. You will also see the same vocabulary—select, url-test, fallback, load-balance—in Clash Meta–based clients, so the skills transfer across Clash Verge Rev, GUI forks, and headless deployments.

Finally, remember that subscription providers only ship proxies entries (nodes). Everything about how those nodes are grouped, labeled, and presented in the app is your YAML design. Two users can share the same subscription yet experience completely different routing because their proxy-groups and rules diverge.

The four core proxy group types

Most Clash and Clash Meta profiles rely on four group types. Each solves a different problem: manual control, latency-based selection, ordered failover, or spreading load.

Before you paste snippets from the web, check that the type string matches your core feature set. Clash Meta extends the ecosystem with additional behaviors, but the four classics remain the backbone of everyday configs. If a profile references a type your build does not support, the parser will error or ignore the group—always validate after edits.

① select — manual selection

select is the simplest group. The user chooses a member in the client UI; Clash does not auto-test or rotate nodes. It is ideal when you want explicit control—for example pinning a specific region for banking apps or testing a single node while you debug DNS.

Because nothing moves unless you click, select is also the safest starting point when you are learning. Pair it with a short list of candidates so the menu stays readable; you can always nest a richer url-test pool behind one of the entries later. Many templates expose a single top-level select named “Proxy” or “Global” so casual users never touch nested names.

proxy-groups:
  - name: "Manual"
    type: select
    proxies:
      - HK-01
      - JP-01
      - US-01
      - DIRECT

② url-test — pick the lowest latency

url-test periodically requests a probe URL (often a lightweight 204 endpoint) through each candidate and keeps the member with the best latency. Use it when responsiveness matters: games, live calls, or interactive SSH. The tolerance field prevents flapping when two nodes are only a few milliseconds apart.

Latency to the probe host is not identical to latency to every service you use, but it is a practical stand-in when you need automation. If you stream from a provider that is picky about egress, combine url-test with a dedicated select for that provider so you can override the automatic pick without rewriting rules.

proxy-groups:
  - name: "Auto fastest"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300        # re-test every 300 seconds
    tolerance: 50        # do not switch if within 50 ms
    proxies:
      - HK-01
      - HK-02
      - JP-01

③ fallback — ordered failover

fallback walks your list in order and sticks to the first proxy that passes the health check. When it fails, Clash moves to the next. This is not “fastest wins”—it is “prefer my primary unless it is down.” That makes it a great fit for mission-critical workflows where you care more about a predictable order than raw ping.

Operations teams sometimes mirror this pattern: a stable datacenter node first, cheaper residential nodes later. Document the intent beside the YAML (in your own notes) so future edits preserve the priority. If you reorder entries without thinking, you change failover semantics even though the file still “looks fine.”

proxy-groups:
  - name: "Failover"
    type: fallback
    url: "http://www.gstatic.com/generate_204"
    interval: 180
    proxies:
      - Primary-HK
      - Backup-JP
      - Emergency-SG

④ load-balance — spread connections

load-balance distributes traffic across several nodes. Common strategies include round-robin and consistent-hashing. Consistent hashing is often preferred for HTTPS because the same remote hostname tends to stick to one outbound path, which reduces login churn on sites that tie sessions to egress IP.

Use load balancing when you have multiple healthy routes to the same region and want to avoid hammering one machine. Avoid it when a service strictly requires a single static IP—banking and some SaaS portals fall in that bucket, so route them through select or a one-member group instead.

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

Nesting proxy groups for flexible policies

The proxies array can list real proxy names or other group names. Nesting lets you build a hierarchy: per-region auto-test pools at the bottom, manual “purpose” selectors above, and a single entry point that your rules reference. This keeps rule tables short—most lines only need to point at one stable group name.

Circular references are invalid: if group A lists group B and group B lists group A, Clash cannot resolve a deterministic path. When in doubt, sketch the graph on paper—leaf nodes are real proxies, internal nodes are groups, and edges follow the proxies lists. Acyclic graphs behave predictably; cycles trigger errors or undefined behavior depending on the core version.

proxy-groups:
  # Tier 1: regional pools (url-test per region)
  - name: "HK pool"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    proxies: [HK-01, HK-02, HK-03]

  - name: "JP pool"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    proxies: [JP-01, JP-02]

  # Tier 2: manual pick among regions
  - name: "Pick region"
    type: select
    proxies:
      - HK pool
      - JP pool
      - DIRECT

  - name: "Streaming"
    type: select
    proxies:
      - US-01
      - JP pool

End-to-end YAML example

Below is a layered layout that covers most daily-driving scenarios: a top-level selector, an automatic fastest pool, dedicated streaming choices, regional url-test groups, and a catch-all selector that can fall back to direct access. Adapt names to match your real proxies section.

proxy-groups:
  - name: "Main"
    type: select
    proxies: [Auto, HK, JP, US, DIRECT]

  - name: "Auto"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies: [HK-01, HK-02, JP-01, SG-01]

  - name: "Streaming"
    type: select
    proxies: [US, JP, HK]

  - name: "HK"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    proxies: [HK-01, HK-02]

  - name: "JP"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    proxies: [JP-01, JP-02]

  - name: "US"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    proxies: [US-01, US-02]

  - name: "Catch-all"
    type: select
    proxies: [Main, DIRECT]

How proxy groups connect to rules

Your rules section references group names as policy targets. For example, you might send domestic domains to DIRECT, send a streaming domain list to Streaming, and end with MATCH pointing at Main or Catch-all. Keeping those names stable matters: a typo in either rules or proxy-groups breaks routing silently or sends traffic to the wrong hop.

Policy-based rules (GEOIP, DOMAIN-SUFFIX, PROCESS-NAME, etc.) simply forward to a string target. That target must exist either as a proxy name, a group name, or a built-in keyword such as DIRECT / REJECT. This is why experienced users rename groups carefully: refactoring “HK” to “HongKong” means touching every rule line that referenced the old token.

When you change group membership, clients that cache the profile may need a refresh—usually a restart or “update profile” from your app. For a maintained client build with up-to-date Clash Meta support, use our download page so installs and updates stay straightforward.

Choosing the right type (quick comparison)

If you are unsure which primitive to apply, start from user intent. Need a fixed node for auditing or testing? Use select. Want the client to chase the lowest ping automatically? Use url-test. Need a strict primary/secondary story? Use fallback. Trying to split bulk traffic across several healthy nodes? Consider load-balance with consistent-hashing for long-lived HTTPS flows.

Mixing types in one stack is normal: a select at the top for human choice, url-test children for each region, and a fallback chain for rare admin-only nodes. The art is keeping the user-visible surface small while still exposing emergency options (DIRECT, REJECT) where they help.

Common pitfalls

• Shadow names: Referencing a proxy that was removed from the subscription leaves dangling entries. Trim groups after every provider update.
• Over-testing: Extremely low interval values look “smart” but can trigger rate limits or drain laptops on battery power.
• Mis-set tolerance: A tolerance of 0 may cause rapid switching on noisy networks; a generous value may stick to a mediocre node. Tune with real-world use.
• Rule mismatch: Copy-pasting rules from another profile without aligning group names is the fastest way to send everything to the wrong exit.

Practical tuning tips

• Intervals: 180–300 seconds is a sweet spot for url-test and fallback. Aggressive intervals burn battery and bandwidth; very slow ones leave you on a bad node for too long.
• Probe URLs: Use endpoints your provider allows. Public 204 URLs are common; some users mirror the probe on their own domain for consistency.
• Naming: UTF-8 names (including emoji) are valid, but every reference must match exactly, including case. Simple ASCII names reduce mistakes when editing by hand.
• Depth: Deep nesting is powerful, but too many layers can confuse newcomers. Document your top-level groups and treat them as your public API inside the YAML.
• Logging: When something looks wrong, enable your client’s connection log and verify which group name handled the flow—then walk backward through nested groups until you reach a real proxy.

Validate before you rely on it

After any structural edit, reload the profile and hit a few representative sites: a local news domain that should go DIRECT, a search engine, and whichever service you care about most (streaming, cloud console, game launcher). If only one category misbehaves, isolate the rule that matches it and confirm the target group still exists.

For bulk changes, keep a backup YAML in version control. Git diffing text files beats re-downloading a broken subscription bundle when you need to roll back. Pair that habit with occasional review of the Clash blog for ecosystem updates that might affect parser behavior.

FAQ

Compared with one-off VPN toggles, Clash gives you structured control: rules for intent, groups for execution. A well-tested client makes that stack easier to live with day after day—Download Clash for free and experience the difference.