How to Choose a Clash Proxy Group: url-test vs. fallback vs. load-balance

In a Clash configuration, proxy groups determine which node ultimately handles a connection. Rules only send traffic to a group; the group’s type determines how a node is chosen. A manual select group lets the user pick a node, while automatic groups choose based on health checks, list order, or an allocation algorithm.

url-test, fallback, and load-balance all use health checks, but their goals are completely different. The first seeks lower probe latency, the second prioritizes ordered failover, and the third distributes new connections across available nodes. Choosing the wrong type usually causes frequent switching, changing egress IPs, or backups failing to take over as expected—not a configuration error.

The Key Differences Between the Three Automatic Proxy Groups

To choose a type, start with one question: does this group need to “pick the fastest-responding node,” “fail over by business priority,” or “share new connections across multiple nodes”? These needs correspond to url-test, fallback, and load-balance.

Health checks do not continuously benchmark active traffic connections

An automatic group requests the test URL at the interval specified by interval, recording member availability and response time. With interval: 300, the normal interval is 300 seconds, or 5 minutes. Shorter intervals generate more probe traffic to nodes and across the local network; longer intervals delay detection of recovery or failure.

Test URLs typically point to lightweight, stable endpoints, such as https://www.gstatic.com/generate_204. If the target network restricts that address, every node may appear to fail at once. Change to a lightweight endpoint that responds reliably instead of immediately assuming that all nodes are down.

url-test: Automatically Prefer the Lowest Probe Latency

url-test periodically tests the group’s members and selects an available node with relatively low probe latency. It suits everyday traffic such as web browsing, instant messaging, and code hosting, where response time matters. Selection happens at the proxy-group level; it does not mean every request triggers a new speed test.

proxy-groups:
  - name: Automatic Selection
    type: url-test
    proxies:
      - Hong Kong-01
      - Hong Kong-02
      - Japan-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

tolerance: Avoid Switching Over Minor Latency Differences

The tolerance value is measured in milliseconds. The example uses 50, meaning a new result should be sufficiently better—within the tolerance threshold—before switching; the exact behavior depends on the underlying core. Its practical purpose is to prevent two similarly fast nodes from repeatedly taking turns as the preferred choice.

For example, node A measures 82 ms and node B 106 ms, a difference of 24 ms. With a 50 ms tolerance, switching solely because of one probe fluctuation is unnecessary. If node A rises to 178 ms while node B stays at 103 ms, the gap reaches 75 ms, making a new selection more worthwhile. On home Wi-Fi with noticeable latency swings, start with 50–100 ms; on a stable wired network, 20–50 ms is reasonable.

lazy: Check Only When Traffic Is Active

lazy: true suits proxy groups that are rarely used. When a group has no connections for an extended period, the core can reduce unnecessary periodic probes and resume checking when matching traffic appears again. For critical groups that need rapid awareness of backup status, evaluate this setting against your mihomo version and client behavior.

When url-test Is—and Isn’t—a Good Fit

• Use it for nodes serving similar purposes with comparable plans and route quality.
• Use it when you want to avoid high-latency nodes automatically without requiring a fixed egress IP.
• Avoid it for login sessions that must keep the same region or egress IP over time.
• Avoid using a single 204 test to estimate video bandwidth; latency probes cannot replace sustained throughput tests.

fallback: Use the First Available Node in Order

The key question for fallback is not which node has the lowest latency, but which one comes first and is currently available. The first member is the primary route; only after its health check fails does the group try subsequent backups. Once the primary recovers and passes its checks, selection generally returns to the earlier member.

proxy-groups:
  - name: Work Route
    type: fallback
    proxies:
      - Enterprise Dedicated Line
      - Hong Kong Backup
      - Japan Backup
    url: https://www.gstatic.com/generate_204
    interval: 180
    lazy: false

This configuration expresses a clear business order: use “Enterprise Dedicated Line” first, switch to “Hong Kong Backup” when it is unavailable, and use “Japan Backup” only if both are unavailable. Even if the Japan node measures 45 ms and the enterprise line 92 ms, the enterprise line remains preferred as long as it is available.

“Available” Only Means the Test URL Completed Successfully

A node reaching the 204 test endpoint does not guarantee that it can reach the business domain matched by a rule. A route may pass its health check yet fail to access a particular service. In that case, choose a test endpoint closer to the actual target for the group, but avoid pages that require login, redirect repeatedly, or return large files.

Failover also cannot move an established TCP connection seamlessly to another node. When the primary route drops, existing downloads, SSH sessions, or WebSocket connections usually disconnect; only after the application reconnects will the new connection use a backup member. For long-lived connections, also check the application’s own retry behavior.

Typical fallback Use Cases

1. Fixed primary route: The primary node provides a stable egress or specific region; other nodes only take over during failures.
2. Cost first: Prefer routes with ample traffic allowance and place expensive or limited routes later.
3. Regional priority: Use Hong Kong first, then switch to Japan or Singapore only when all Hong Kong routes are unavailable.
4. Remote connections: Remote development and admin panels value egress continuity more than a latency difference of a few dozen milliseconds.

load-balance: Distribute New Connections Across Multiple Nodes

load-balance distributes connections among multiple available members. It is not a bandwidth aggregator: a single TCP download usually still travels through one node, so three 100 Mbps routes do not automatically combine into one 300 Mbps connection. It is better suited to many independent requests, multi-domain browsing, or several concurrent tasks.

proxy-groups:
  - name: Concurrent Distribution
    type: load-balance
    proxies:
      - Hong Kong-01
      - Hong Kong-02
      - Hong Kong-03
    url: https://www.gstatic.com/generate_204
    interval: 300
    strategy: consistent-hashing

consistent-hashing: Keep Similar Destinations Relatively Stable

consistent-hashing calculates an assignment from the connection target, making identical or similar destinations tend to land on the same member. Compared with pure round-robin allocation, it better suits website logins, API calls, and scenarios that need some egress continuity. Changes to the node list can still remap some destinations, so it cannot replace a truly fixed egress.

round-robin: Allocate New Connections in Rotation

mihomo’s round-robin strategy assigns new connections to available members in sequence. If a group contains nodes A, B, and C, successive connections may be assigned A, B, C, A. A webpage often connects to multiple domains at once, so a single page load may use several egress IPs.

Round-robin suits concurrent fetching and connection distribution when a single egress is not required. Avoid it for account logins, payments, online banking, or APIs sensitive to IP changes. If a service treats multiple egress IPs in a short period as suspicious, use select, fallback, or a strategy with more stable destination mapping.

Combining Proxy Groups: Prefer Within a Region, Then Fail Over Across Regions

Complex configurations do not need to solve every goal in one group. Proxy groups can reference other groups, so a clearer design is to create regional url-test groups first, then let an upper-level fallback group determine regional priority. This selects a low-latency node within a region and still switches when the entire region becomes unavailable.

proxy-groups:
  - name: Hong Kong Automatic
    type: url-test
    proxies:
      - Hong Kong-01
      - Hong Kong-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: Japan Automatic
    type: url-test
    proxies:
      - Japan-01
      - Japan-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: Default Egress
    type: fallback
    proxies:
      - Hong Kong Automatic
      - Japan Automatic
    url: https://www.gstatic.com/generate_204
    interval: 180

rules:
  - DOMAIN-SUFFIX,example.net,Default Egress
  - MATCH,Default Egress

In this structure, “Hong Kong Automatic” first chooses a suitable member from the two Hong Kong nodes. The upper-level “Default Egress” prefers the Hong Kong group and uses the Japan group only when the Hong Kong group cannot complete its checks. Group names must match exactly, including capitalization, spaces, and symbols. Use two spaces consistently for YAML indentation; do not mix in tabs.

Using Manual and Automatic Groups Together

A practical configuration usually keeps a select group for temporarily choosing a node. You can place “Automatic Selection,” “Work Route,” “Concurrent Distribution,” and individual nodes in one manual group, then point rules to that group. Choose an automatic strategy for everyday use and switch to a specific node when a fixed egress is needed.

proxy-groups:
  - name: Node Selection
    type: select
    proxies:
      - Automatic Selection
      - Work Route
      - Concurrent Distribution
      - Hong Kong-01

This structure is easier to maintain than pointing every rule directly at a low-level automatic group. In the client UI, you only need to operate “Node Selection,” while the underlying groups continue handling tests and failures. After changing the configuration, use “Configuration” → “Reload” in the client and check the logs for missing proxy-group names, YAML parsing failures, or invalid node references.

How Rules Mode, System Proxy, and TUN Mode Relate

Proxy groups choose the egress; rules decide which group receives a connection. In Rules mode, connections are matched from top to bottom against rules such as DOMAIN, DOMAIN-SUFFIX, and IP-CIDR; once a rule matches, traffic enters its specified proxy group. Global mode generally sends traffic to a global policy instead of deciding its destination through ordinary rules one by one.

System Proxy and TUN mode determine which traffic can enter the core; they do not change the basic selection logic of url-test, fallback, or load-balance. Whether a browser enters Clash through the system proxy or game traffic enters mihomo through TUN, traffic is selected according to the group type once it matches the same proxy group.

Pay Extra Attention to UDP in TUN Mode

Games, voice calls, and some HTTP/3 traffic use UDP. The node protocol, server, and client core must all support the required UDP forwarding. A node passing a TCP test URL does not guarantee that UDP works. If web browsing works but voice or games fail, confirm the network type in the connection panel and check the node’s UDP support, TUN settings, and firewall rules.

DNS Results Affect Rules and Connection Targets

With Fake-IP enabled, the DNS module returns mapped addresses, and the core restores the domain through that mapping before matching rules. With Redir-Host enabled, the resolved address participates more directly in the connection. Proxy groups do not fix DNS; if domain resolution times out, none of the three automatic groups may get a chance to establish a normal application connection.

Tuning Parameters: Start with a Stable Configuration

There is no fixed set of automatic proxy-group parameters that suits every network. Home broadband, mobile hotspots, cross-border dedicated lines, and cloud servers have different levels of fluctuation. A more reliable approach is to start conservatively, record switching and failure behavior, and adjust one issue at a time.

1. First confirm that every node can access the test URL reliably, then run at least three consecutive checks.
2. Record node latency instead of relying on a single result. 82 ms, 91 ms, and 87 ms are close; 82 ms versus 260 ms is a clear difference.
3. Watch the actual policy chain in the client’s connection panel and confirm that the group matched by the rule is the expected one.
4. After adjusting the settings, reload the configuration and test with a new connection. Existing connections may continue using the previous egress.
5. When the entire group fails, check the local network and test endpoint first, then inspect subscription nodes. Do not change several parameters at once.

Common Misconceptions and a Troubleshooting Order

Misconception 1: url-test sends every request to the lowest-latency node

It maintains the current selection from the latest health-check results; it does not run a full speed test before every HTTP request. If node latency changes between two check cycles, the current result may temporarily lag behind. That is normal for periodic checks.

Misconception 2: fallback picks the fastest node in the backup list

fallback follows the member order first. As long as the first member is available, it will not switch just because the second is faster. For latency-based selection, use url-test, or reference a url-test subgroup inside fallback.

Misconception 3: load-balance increases the speed of a single-file download

A single connection is usually tied to one node. Total throughput may change only when a downloader splits a file across multiple independent connections and those connections are assigned to different members. The final speed still depends on source-side limits, node bandwidth, route congestion, and the allocation strategy.

A Consistent Troubleshooting Order

1. In the client’s “Configuration” page, confirm that the currently loaded file is the one you just edited.
2. Open the logs and check that the proxy-group type, member names, and YAML indentation are correct.
3. Run a latency test once from the “Proxies” or “Policies” page and record which members fail.
4. Open the “Connections” panel and confirm the rule and policy chain actually matched by the target connection.
5. Close and reopen the target application to rule out an old TCP connection still reusing the previous egress.
6. If system-proxy traffic works but TUN traffic does not, check TUN, DNS, and firewall settings instead of repeatedly changing the proxy-group type.

Choosing the Type: Decide by Goal, Not by Name

• To automatically use the node with lower probe latency, choose url-test.
• To prioritize a primary route and fail over in order, choose fallback.
• To distribute new connections across multiple nodes when changing egress is acceptable, choose load-balance.
• To retain manual control while using automatic selection, use select at the outer layer and add the automatic group as a member.
• When regional priority is needed, create a regional url-test group first, then combine regions with an upper-level fallback.

Most personal configurations can start with two layers: “manual selection + automatic preference.” Add fallback only when there is a clearly defined primary and backup route; use load-balance only when you truly have many independent connections and can accept distributed egress. More types do not make a configuration more effective. Clear responsibilities between groups and rules make validation and troubleshooting easier.