Clash Strategy Group Modes Explained: url-test, fallback, and load-balance

How strategy groups participate in Clash rule routing

Proxy nodes in a Clash configuration establish the actual connections, while rules determine what kind of traffic a connection belongs to. Strategy groups sit between these two layers and decide which node ultimately handles the traffic. Rules usually reference a strategy group instead of naming a node directly. For example, work domains can be sent to “Work Services” and streaming domains to “Media Services”, after which the group’s selection logic manages node changes.

url-test, fallback, and load-balance are all automatic strategy groups, but “automatic” does not mean that they make the same choices. They represent latency-based selection, ordered failover, and multi-node connection distribution respectively. If you only inspect the node list and ignore the group type, the same set of nodes can produce completely different browsing behavior.

proxy-groups:
  - name: Work Services
    type: url-test
    proxies:
      - Node-A
      - Node-B
      - Node-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

rules:
  - DOMAIN-SUFFIX,example.com,Work Services
  - MATCH,Work Services

In this configuration, rules only send matching connections to “Work Services”. The component that decides whether Node A, B, or C is used is the url-test group, based on its latency results and switching parameters. A strategy group is not an additional network tunnel, and it does not change a node’s protocol, encryption method, or server route. It simply organizes nodes and performs selection.

The role of health checks in automatic strategy groups

Automatic groups usually access a test URL through each candidate node at regular intervals. The core maintains node status based on request success, response time, and consecutive check results. A test URL should be stable, return a small response, and resemble the actual network exit when possible. A common 204 response endpoint works well for measuring basic connectivity, but a lightweight endpoint that you control long term may be better for a configuration serving a specific business.

interval specifies the check interval, usually in seconds. An interval that is too short adds requests for both nodes and devices, and may frequently wake connections on mobile networks. An interval that is too long delays failure detection. On an always-on desktop, start by observing behavior around 300 seconds, then adjust it for network volatility and the number of nodes.

url-test: choose nodes by health-check latency

url-test tests the nodes in a group and generally prefers the available node with the lowest measured latency. It suits situations where members provide similar capabilities and response time matters most, such as several exits in the same region, multiple nodes that can all reach the same service, or routine web and code repository access.

“Lowest latency” applies only to the health-check request; it does not mean the highest download speed. A small HTTP request mainly reflects the handshake, round-trip time, and current reachability of the route. It cannot fully represent large-file throughput, peak-hour congestion, or bandwidth between the target site and the exit server. A more accurate description of url-test is “choose the responsive healthy node based on test results”, not continuous bandwidth racing.

How tolerance reduces unnecessary switching

Network latency naturally fluctuates. If node A measures 82 milliseconds and node B measures 76 milliseconds, switching immediately for a six-millisecond difference usually provides no noticeable improvement, but it may move a new connection to another exit. tolerance sets the acceptable latency difference. When the gap between the current and candidate nodes remains within the threshold, the existing choice is retained.

- name: Everyday Low Latency
  type: url-test
  proxies:
    - Hong Kong-01
    - Hong Kong-02
    - Singapore-01
  url: https://www.gstatic.com/generate_204
  interval: 300
  tolerance: 100
  lazy: true

In mihomo configurations that support these fields, lazy: true can reduce checking activity while a strategy group is unused for an extended period. Once the group begins carrying traffic, the core updates its status according to its mechanism. Trigger behavior may vary between core versions, so consult the documentation and runtime logs for the version in use.

Where url-test works best

• Good for: candidate nodes with the same purpose, where regional differences do not change website content or account risk checks.
• Good for: web browsing and API requests that depend more on response latency.
• Use caution for: logins, payments, remote work, or allowlisted services that require a fixed exit IP.
• Do not judge by tests alone: large downloads, high-bitrate video, and sustained uploads also depend on bandwidth and packet loss.

If a service requires the same exit to be retained during a session, increase tolerance, reduce the member range, or add a manual select group outside the automatic group. This preserves automatic entry-point selection while allowing a specific node to be pinned when needed.

fallback: fail over in node order

The core idea of fallback is not to compare which node is fastest, but to use the first healthy node in the configured order. As long as the leading node passes its health check, a later node will generally not replace it even if its latency is lower. When the current leading node becomes unavailable, the group searches for the next available member in sequence.

This behavior suits environments with a clear primary-and-backup relationship. The primary node may have a fixed exit, a dedicated route, or a region required by the service, while backup nodes take over only when the primary route fails. Compared with url-test, fallback is easier to predict: the node order itself is the priority list.

- name: Office Primary and Backup
  type: fallback
  proxies:
    - Office Primary Route
    - Office Backup Route
    - Emergency Route
  url: https://www.gstatic.com/generate_204
  interval: 180
  lazy: false

The example uses “Office Primary Route” first. If its health check fails, it tries “Office Backup Route”, followed by “Emergency Route”. If the primary route later recovers and is marked healthy again, the group may return to the higher-priority node. Recovery detection and migration of existing connections are separate concerns: group selection affects subsequent connections, while established TCP or UDP sessions may not move seamlessly.

Node order matters more than latency numbers

When configuring fallback, arrange nodes by business priority before considering test results. The primary route should be the one intended for long-term use, and backup routes must provide the same critical access. If a backup node cannot reach the main service, a successful health-check URL still does not constitute a real failover.

For region-sensitive services, avoid mixing nodes from unrelated regions in one fallback group. A safer approach is to create a primary-and-backup group within each region, then let a higher-level manual group select among those regional groups. For example, “Japan Primary/Backup” should contain only Japan nodes and “Singapore Primary/Backup” only Singapore nodes. This prevents a regional change caused by automatic failover.

Typical cases for fallback

1. Remote work services require a fixed exit that has already been added to an access allowlist.
2. The primary route is stable and has predictable costs, while the backup carries traffic only during failures.
3. Nodes have a clear reliability ranking rather than merely different momentary latency values.
4. You want automatic recovery of basic connectivity while keeping the decision logic easy to audit and explain.

load-balance: distribute new connections across nodes

load-balance lets multiple healthy nodes in a group carry connections together. Its goal is not to select one permanent winner, but to choose exits for different connections according to a balancing strategy. It suits environments with many independent requests, nodes of similar capability, and services that allow multiple exits.

Clash load balancing usually makes decisions per connection or destination; it does not split one TCP connection across multiple proxy servers. If a large download uses only one connection, its speed remains limited by the selected node. Multiple nodes can share the work only when the application creates several concurrent connections.

- name: Multi-Node Distribution
  type: load-balance
  proxies:
    - Node-A
    - Node-B
    - Node-C
  url: https://www.gstatic.com/generate_204
  interval: 300
  strategy: consistent-hashing

consistent-hashing and round-robin

For the exact balancing strategies supported by mihomo, refer to the version in use. The common consistent-hashing strategy maps connections relatively consistently according to destination information, making the same or related destinations more likely to continue using the same node. This can reduce exit changes when loading one site, especially when a site is sensitive to the source of its session.

round-robin tends to rotate through available nodes in order, distributing consecutive new connections among different members. Its traffic distribution is more direct, but several connections to the same site may use different exits. If the site maintains login state by source IP or performs security checks, this can cause repeated verification, expired sessions, or inconsistent regional content.

Some mihomo versions also offer other strategy options, whose fields and behavior may change. When migrating a configuration, do not assume that identical parsing means identical semantics. Check configuration warnings in the startup log and inspect connection details to confirm which node is actually being used.

Load balancing is not suitable for every service

• Services such as account logins, online banking, and enterprise identity systems need a stable exit and should prefer a fixed node, select, or destination-stable mapping.
• When exit regions differ, search results, media catalogs, currency, and regional page settings may change between connections.
• When node performance varies widely, evenly distributing connections does not evenly distribute bandwidth; slower nodes can still delay some requests.
• Frequent mobile-network changes, limited device resources, or too many nodes can add overhead from health checks and concurrent connections.

Key differences between url-test, fallback, and load-balance

Choose by requirements, not by name

When selecting a strategy group, answer three questions first. Does the service require a fixed region or exit? May a failure switch automatically to any available node? Does the workload really need several nodes to carry connections at once? If the primary exit must remain in use and switching should happen only after failure, fallback is the direct choice. If nodes are equivalent and response speed comes first, url-test is more suitable. Consider load-balance only when request volume is high, connections are independent, and changing the source is acceptable.

A configuration does not have to use only one automatic group. A practical design can combine layers: use fallback at the lower level for regional primary-backup nodes, url-test at the middle level to choose the more responsive entry among equivalent regional groups, and select at the top level so users can pin a strategy manually. Nested groups express clearer business boundaries, but too many layers make troubleshooting harder. Group names should accurately describe their purpose.

proxy-groups:
  - name: Hong Kong Primary and Backup
    type: fallback
    proxies:
      - Hong Kong Primary Route
      - Hong Kong Backup Route
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: Singapore Primary and Backup
    type: fallback
    proxies:
      - Singapore Primary Route
      - Singapore Backup Route
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: Automatic Region
    type: url-test
    proxies:
      - Hong Kong Primary and Backup
      - Singapore Primary and Backup
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 120

  - name: Final Selection
    type: select
    proxies:
      - Automatic Region
      - Hong Kong Primary and Backup
      - Singapore Primary and Backup
      - DIRECT

A complete checklist for configuring strategy groups

1. Confirm the core, client, and configuration fields

The original Clash, Clash Meta, and later mihomo branches differ in supported features and fields. Graphical clients may also provide different strategy-group editors. A field appearing in a subscription does not guarantee that the current core supports it. After importing a configuration, inspect the core startup log for unknown fields, invalid strategy types, or failed proxy-name references.

If the client allows core switching, confirm which core is actually running instead of relying on the client name. Some clients regenerate the configuration when updating a subscription, which can overwrite manual strategy-group changes. Long-term custom rules and strategies are better maintained through the client’s supported overrides, extensions, or configuration-merge features.

2. Check proxy names and indentation

YAML is sensitive to indentation. Names under proxies must exactly match proxy nodes or other strategy groups. Chinese characters, spaces, and symbols can be used in names, but avoid adding extra spaces when copying. When one group references another, also make sure that the references do not form a loop.

proxies:
  - name: Node-A
    type: ss
    server: server.example
    port: 443
    cipher: aes-128-gcm
    password: example-password

proxy-groups:
  - name: Automatic Selection
    type: url-test
    proxies:
      - Node-A
    url: https://www.gstatic.com/generate_204
    interval: 300

3. Verify health checks instead of relying on an icon

The latency shown by a client may come from a manual test or from a strategy-group health check; the test URL and timestamp may differ. If a node appears available but a website does not open, inspect connection logs to confirm which rule matched, which group selected the node, and whether the failure occurred during DNS resolution, connection setup, or the target server’s response.

If all members time out at once, first check whether the test URL is reachable on the current network, whether DNS returns abnormal results, whether the system clock is accurate, and whether the nodes can establish connections. Do not immediately shorten interval and run repeated tests; a higher test frequency cannot repair a basic connectivity problem.

4. Validate system proxy and TUN mode together

A strategy group takes effect only after traffic enters the Clash core. The system proxy mainly handles applications that follow the operating system proxy settings. Programs that ignore system proxy settings, some games, and certain UDP traffic may require TUN mode to enter the rule chain. If a browser switches nodes as expected while one application always connects directly, first confirm whether that traffic is being intercepted instead of changing the strategy group.

After enabling TUN mode, also check the DNS mode, route exclusions, and LAN access. Incorrect DNS settings can prevent domain rules from matching as expected, while route exclusions can send target traffic around the core. During troubleshooting, choose a clearly defined test domain and check DNS resolution, rule matching, group selection, node connection, and target response in that order.

5. Handle node changes after subscription updates

A subscription provider may add nodes, rename them, or remove old ones. If a strategy group lists members by static name, a name change breaks the reference. mihomo configurations can also use proxy sets and filtering rules to organize subscription nodes dynamically, but filters must be designed carefully so that entries such as “remaining traffic” or “plan information” are not included in an automatic group.

With dynamic filters, create separate sets by region and purpose and keep each set clearly bounded. For example, a low-latency group should contain only regions accepted by the same service, while a primary-backup group should contain only routes that can genuinely take over. More nodes are not always better: too many candidates lengthen health-check lists and make abnormal nodes harder to identify.

Practical advice for stable strategy groups

1. Make group names express the decision logic. “Hong Kong Primary/Backup”, “Low-Latency Automatic”, and “Download Balance” are easier to understand in connection logs than “Proxy Group 1”.
2. Put business boundaries before speed. First ensure that every candidate meets regional, account, and protocol requirements, then compare latency or distribute connections.
3. Leave room for automatic switching. Set a reasonable url-test tolerance to avoid changing exits because of minor latency fluctuations.
4. Do not use load-balance as a speed test. It distributes connections; it does not guarantee that every connection uses the fastest node.
5. Review actual matches regularly. Use the client’s connection page to confirm that the domain rule, strategy group, and final node match expectations.
6. Test in layers after changes. Verify an individual node first, then health checks, rule matching, and finally the real service.

In short, url-test answers “which healthy route is responding faster now”, fallback answers “who takes over when the primary route fails”, and load-balance answers “how should multiple healthy nodes carry connections”. Once the goal is clear—speed, priority, or connection distribution—health checks, switching thresholds, and rule entry points can keep Clash routing clear and predictable.