Proxy Groups Explained: select, url-test, fallback and More

Proxy groups are the middle layer of every Clash and mihomo configuration: they sit between the raw list of servers and the routing rules, turning dozens of individual nodes into a few meaningful choices. When you open your client and see a dropdown called "Auto" or a region selector full of flags, you are looking at proxy groups.

The group's type decides how a node gets picked — by you, by a latency test, or by failover logic. This article explains the four types you will actually meet — select, url-test, fallback and load-balance — with a YAML snippet for each, and shows how subscription providers nest groups to build the structures you see in your client.

What proxy groups are for

Routing rules in a well-built config never point at an individual server. They point at a group, and the group resolves to a server according to its policy. That indirection is what makes everything flexible: you can switch nodes without touching a single rule, and automation like latency testing lives in one place. If the overall config structure is still fuzzy, read that primer first — groups will make far more sense.

select: manual choice

The workhorse. A select group shows its members in the client UI and uses whichever one you clicked last:

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

Members can be servers or other groups — here "Auto" is itself a group. Most people leave their main select group pointed at an automatic group and only intervene when they need a specific region.

url-test: pick the fastest automatically

A url-test group probes every member against a test URL on a schedule and routes through the one with the lowest latency:

  - name: "Auto"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies:
      - "HK-01"
      - "JP-01"
      - "US-01"

interval is the test period in seconds. tolerance (in milliseconds) prevents constant switching: a new node must beat the current one by more than the tolerance before the group changes over. Without it, two nodes with nearly identical latency can flap back and forth.

fallback: ordered failover

A fallback group cares about availability, not speed. It always prefers the first healthy member in the list and only moves down when a health check fails:

  - name: "Failover"
    type: fallback
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    proxies:
      - "Primary"
      - "Backup-1"
      - "Backup-2"

Use it when you have a preferred line and merely want insurance: order in the list is priority, and the group returns to the primary once it recovers.

load-balance: spread the connections

A load-balance group distributes connections across all members instead of picking one winner. Depending on its strategy, it can keep the same destination on the same node (hash-based) or rotate more freely. It is situational — useful when one node throttles per-connection throughput — but it can also break sites that dislike your IP changing mid-session. Reach for it only with a concrete reason.

Nesting: how subscriptions structure groups

Because groups can reference other groups, providers typically ship a two-layer layout:

• Region groups — "Hong Kong", "Japan", "US" — each a url-test over that region's nodes.
• Function groups — "Streaming", "AI", "Default" — each a select whose members are the region groups.
• Rules then point at function groups, so "route video sites through Streaming" stays true no matter which region you pick.

When you import a subscription, this whole tree arrives prebuilt — which is why your client shows several groups even though you configured nothing. Understanding the layers tells you where to click: choose regions in function groups, and let url-test handle individual servers.