Proxy Groups Solve the "Which Node" Problem

In a rule like DOMAIN-SUFFIX,google.com,PROXY, PROXY isn't a specific node — it's the name of a proxy group. Rules only decide "which group this traffic should use"; which node within that group actually gets used, and how it switches, is entirely up to the proxy group's own scheduling logic. The benefit of this design: even if you switch subscriptions and every node changes, your rule file never needs to change, because rules always reference the group name, never a specific node.

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 香港01
      - 新加坡01
      - DIRECT

In the simplest example above, the PROXY group's type is select, which means you manually choose which node to use — one click in the client's UI switches it, and it never changes on its own.

The Four Scheduling Types, One by One

1. select: Fully Manual, No Auto-Switching

select is the simplest type — the client just lists out the nodes in the proxies array as-is, and you click to choose which one to use; it never switches on its own. This suits situations where you already know which node has a stable route and don't want the app "helpfully" switching things for you.

2. url-test: Automatically Picks the Lowest-Latency Node

url-test hits a test URL at a fixed interval (interval) to measure the latency of every node in the group, and automatically switches to whichever is currently fastest. What you see in the UI is a read-only "currently in use" node — you can't manually lock it.

proxy-groups:
  - name: 自动选优
    type: url-test
    proxies: [香港01, 香港02, 新加坡01, 日本01]
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

tolerance is the key parameter here: a switch only actually happens when the new node's latency is lower than the current one by more than this tolerance value (in milliseconds). Its purpose is to prevent two nodes with similar latency from flip-flopping back and forth. Setting tolerance too low is the single most common cause of "the node keeps switching on its own."

3. fallback: Only Switches When the Primary Node Dies

fallback also periodically checks whether nodes are reachable, but the logic differs: it keeps using the first reachable node in the list as long as it hasn't failed — it never switches just because "there's a faster one." Only when the currently active node fails does it move on to the next one in order. This suits situations where you want to stick with a primary node and only fall back to a backup line when it becomes completely unusable.

proxy-groups:
  - name: 主备切换
    type: fallback
    proxies: [主力节点, 备用节点A, 备用节点B]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

4. load-balance: Spreading Traffic Across Multiple Nodes

load-balance distributes different connections across the nodes in a group using consistent hashing or round-robin, so several connections may be using different nodes at the same time. This suits situations where all your nodes have plenty of bandwidth and you want to spread out the load — the trade-off is that different requests to the same site may appear to come from different IPs, which can cause issues on sites sensitive to IP consistency.

proxy-groups:
  - name: 负载均衡
    type: load-balance
    proxies: [香港01, 香港02, 香港03]
    strategy: consistent-hashing
    url: "https://www.gstatic.com/generate_204"
    interval: 300

Proxy Groups Can Be Nested: Groups Within Groups

Besides specific node names, the proxies list can also contain the name of another proxy group, letting you build a layered structure. A common pattern is to first set up several url-test auto-latency-testing groups by region, then use a select group to pull those regional groups together, letting you manually choose "which region to mainly use this time":

proxy-groups:
  - name: 香港自动
    type: url-test
    proxies: [港01, 港02, 港03]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

  - name: 日本自动
    type: url-test
    proxies: [日01, 日02]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

  - name: PROXY
    type: select
    proxies: [香港自动, 日本自动, DIRECT]

The benefit of this pattern: rules only ever need to reference the outermost PROXY, while exactly how each region's internal auto-latency-switching works is entirely the inner group's own business. The two layers of logic don't interfere with each other, and the config file stays much easier to maintain.

Node Keeps Switching? Check These Two Parameters First

If you're using url-test and notice the "current node" keeps switching, causing long connections (downloads, video calls) to drop frequently, it's usually because these two parameters aren't tuned properly: interval is set too short, making the latency test run too often; or tolerance is set too low or not set at all, causing two nodes with close latency to keep getting judged as "a better option" and switching back and forth. Bumping interval up to 300 seconds or more and setting tolerance to around 50ms usually improves this noticeably.

Final Thoughts

Choosing a proxy-group type really comes down to answering one question: "how much of the decision do I want the program to make for me, for the nodes in this group?" Use select for zero help, url-test to have it test and pick the fastest, fallback to have it just step in when something fails, and load-balance to spread the load. Once you understand how these four types differ, pair them with routing rules to decide "who should use which group," and you've basically got a complete, maintainable config. If you're ever unsure what a term means, check the glossary anytime.