Skip to main content
EN

Home / Blog / Config Basics

The five proxy-group types — select, url-test, fallback, load-balance and relay

Config Basics2026-07-291335 words3 min read
The five proxy-group types — select, url-test, fallback, load-balance and relay

Policy groups are the layer of a Clash config with the most design freedom. The same set of nodes, grouped differently, produces a very different experience.

The five types at a glance

How the five behaveselectmanuwhatever you click is what you usemost controlurl-testpickre-tests periodicallythe everyday workhorsefallbackusesonly switches when the current one dieswhen stability mattersload-balancespreby hash or round robinseveral lines in parallelrelaychaitraffic passes through several nodes in sequencespecial cases
The first three are the daily drivers; the last two solve specific problems

1. select: manual choice

The most basic kind — effectively a dropdown menu.

- name: "🚀 Select"
  type: select
  proxies:
    - "♻️ Auto"
    - "🇭🇰 Hong Kong"
    - "🇯🇵 Japan"
    - DIRECT

Character: entirely up to you, never switches by itself.

Use: as the top-level master switch. Most of your rules point at it, you change it once in the interface, and the whole config follows.

2. url-test: pick the fastest automatically

Periodically measures latency across every node in the group and picks the lowest.

- name: "♻️ Auto"
  type: url-test
  proxies: ["HK-01", "HK-02", "JP-01"]
  url: "http://www.gstatic.com/generate_204"
  interval: 300        # re-test every 300 seconds
  tolerance: 50        # 50 ms tolerance
  lazy: true           # do not test while idle

How to set the parameters

ParameterSuggestedWhy
urlhttp://www.gstatic.com/generate_204Returns an empty 204 — the lightest possible check
interval300 (5 minutes)Too short bothers every node constantly; too long delays switching
tolerance50–100The most frequently overlooked parameter
lazytrueSkips testing when idle, saving power and data

You can also point url at the service you actually care about — testing YouTube reachability with https://www.youtube.com/generate_204, for instance. The closer the target is to real use, the better the chosen node fits.

3. fallback: failover

Checks in the order you wrote and uses the first one that works.

- name: "🛡 Failover"
  type: fallback
  proxies: ["Primary-IPLC", "Backup-relay", "Backup-direct"]
  url: "http://www.gstatic.com/generate_204"
  interval: 180

The key difference from url-test:

url-test vs fallbackurl-testalways uses the fastestswitches back and forth when node quality fluctuatesfor chasing speedfallbackalways uses the first woonly changes when it diesfor chasing stability
Use fallback when you have one good dedicated line; url-test when node quality is uneven

Typical use: you have one expensive but reliable IPLC line and several cheap relays. Put the dedicated line first, and only when it fails does it drop down to the relays.

4. load-balance: spreading the load

Distributes traffic across several nodes.

- 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

Two values for strategy:

  • consistent-hashing (default): the same domain always takes the same node. Use this one — sessions stay consistent and you do not mysteriously lose login state.
  • round-robin: each connection takes the next node in turn. Better bandwidth utilisation, but plenty of sites will demand re-verification when your IP keeps changing.

Also, services that depend on a stable session (banks, streaming, anything with two-factor checks) are a poor fit for load balancing; a hopping IP invites risk controls.

5. relay: chained proxying

Traffic passes through several nodes in sequence.

- name: "🔗 Chain"
  type: relay
  proxies: ["Entry-relay", "Exit-US-residential"]

The path: your machine → the relay → the US exit → the target site.

When it makes sense:

  • The exit node is a native residential IP (good at unlocking) but the direct connection to it is poor, so a relay improves the link
  • You need a fixed exit IP but the direct route to that machine is unstable

The cost: every extra hop is another round of encryption plus another stretch of network latency. Do not use it without a reason.

A Mihomo speciality: include-all and filter

Hand-written node lists are painful to maintain when nodes change. Mihomo can collect them automatically:

- name: "🇭🇰 Hong Kong"
  type: url-test
  include-all: true                 # take in every node from proxies and providers
  filter: "(?i)HK|Hong ?Kong"       # keep only what matches
  exclude-filter: "(?i)trial|expired|website"   # drop these
  url: "http://www.gstatic.com/generate_204"
  interval: 300
  tolerance: 50

New Hong Kong nodes appearing after a subscription update are then picked up automatically, with no config change. Regex syntax in node naming and automatic grouping.

Other useful options:

  include-all-proxies: true      # only from the proxies section
  include-all-providers: true    # only from providers
  use: ["main-sub", "backup-sub"]  # which proxy-providers to use
  hidden: false                  # hide this group in the interface
  icon: "https://.../hk.png"     # icon in the interface

A grouping structure you can copy

proxy-groups:
  # master switch
  - name: "🚀 Select"
    type: select
    proxies: ["♻️ Auto", "🇭🇰 Hong Kong", "🇯🇵 Japan", "🇺🇸 US", "🇸🇬 Singapore", DIRECT]

  # automatic testing across everything
  - name: "♻️ Auto"
    type: url-test
    include-all: true
    exclude-filter: "(?i)remaining|expiry|website|traffic"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    lazy: true

  # regional groups
  - name: "🇭🇰 Hong Kong"
    type: url-test
    include-all: true
    filter: "(?i)HK|Hong ?Kong"
    interval: 300
    tolerance: 50
  - name: "🇯🇵 Japan"
    type: url-test
    include-all: true
    filter: "(?i)JP|Japan|Tokyo"
    interval: 300
    tolerance: 50
  - name: "🇺🇸 US"
    type: url-test
    include-all: true
    filter: "(?i)US|United States"
    interval: 300
    tolerance: 50
  - name: "🇸🇬 Singapore"
    type: url-test
    include-all: true
    filter: "(?i)SG|Singapore"
    interval: 300
    tolerance: 50

  # by purpose (this is what rules point at)
  - name: "🤖 AI services"
    type: select
    proxies: ["🇺🇸 US", "🇯🇵 Japan", "🚀 Select"]
  - name: "🎬 Streaming"
    type: select
    proxies: ["🇭🇰 Hong Kong", "🇸🇬 Singapore", "🚀 Select"]
  - name: "📢 Ad blocking"
    type: select
    proxies: [REJECT, DIRECT]
  - name: "🐟 Fallthrough"
    type: select
    proxies: ["🚀 Select", DIRECT]
The hierarchy this createsrulespoint somewhere on matchPurpose groupsAI Regional groupsHong Kong Actual nodesthe real exit
The advantage of three layers: changing nodes happens in one place, and the rules never move

Common questions

Q: Can policy groups reference each other in a cycle? No. Putting B in A's proxies and A in B's causes a load failure or an infinite loop.

Q: Why does my url-test always time out? The test URL itself is unreachable. gstatic.com does not work on some networks; try http://cp.cloudflare.com/generate_204 or http://connectivitycheck.platform.hicloud.com/generate_204.

Q: Do I have to define DIRECT and REJECT? No, they are built-in policies. DIRECT connects directly, REJECT refuses outright (used for ad blocking), and Mihomo additionally has REJECT-DROP and PASS.

Q: What is a good interval? 300 seconds is the balance point. 60 hammers every node with requests and some providers treat that as abnormal; 1800 means a dead node takes half an hour to get switched away from.

In short

  • select as the master switch, url-test as automatic, fallback as insurance
  • Always set tolerance — without it the group flip-flops
  • Use include-all plus filter instead of hand-written node names, so subscription updates need no maintenance
  • A three-layer structure (rules → purpose group → regional group → node) is the easiest to maintain

Next, how to write rules: the rule type reference.


Related docs