Clash Proxy Groups Explained: Choosing Between url-test, fallback, and load-balance

In a Clash configuration, proxy groups sit between routing rules and individual proxy nodes. Rules determine what kind of traffic a connection belongs to, while the proxy group decides which node ultimately handles it. Treating a proxy group as a simple “node folder” can lead to mistaken assumptions: each group type has its own selection criteria, health-check behavior, and failure-handling order. Similar names do not imply identical behavior.

Although url-test, fallback, and load-balance can all reference multiple proxies, they address different needs. The first seeks the node with the best probe results, the second preserves a predefined primary-to-backup order, and the third distributes separate connections across available nodes. Before choosing one, decide whether the goal is lower everyday latency, a consistent egress priority, or distributed concurrent connections—not merely the lowest latency number shown in the client.

Where proxy groups fit into routing

After a request enters Clash or Mihomo, it typically goes through DNS and inbound processing before the rules are evaluated from top to bottom. A rule can target either a specific node or a proxy group. In practice, rules commonly point to group names—for example, sending development services to “Web Auto,” work systems to “Work Failover,” and large batches of independent downloads to “Download Distribution.”

A proxy group handles only connections that rules have directed to it. Even if several latency-test groups exist, a connection still goes directly when its matching rule targets DIRECT. If it eventually matches MATCH and enters another group, earlier test groups are not used. When troubleshooting why traffic is not using an apparently available node, inspect both the matched rule and the proxy group's current selection instead of focusing only on the node list.

How automatic groups relate to manual select groups

A select group is a common manual-selection group and can include an automatic group as one of its options. This preserves automatic selection for everyday use while allowing a temporary switch to a fixed node when a destination restricts a particular egress IP. Automatic groups can also be referenced by other groups, but excessive nesting makes troubleshooting harder. Use functional names such as “Web Auto,” “Work Failover,” and “Download Distribution” rather than generic labels such as “Group 1” and “Group 2.”

url-test: Automatic selection based on probe results

A url-test group has the core probe each candidate proxy using a specified URL, then selects a node with favorable results. It suits everyday traffic such as web browsing, code hosting, and software updates where automatically avoiding high-latency routes is useful. Here, “favorable” mainly reflects probe response time and availability; it is not a complete assessment of bandwidth, packet loss, peak-hour stability, or overall performance.

The probe URL should be reliable, return a small response body, and provide an unambiguous success status. Many configurations use an HTTP endpoint that returns no content to minimize test traffic. If the test URL is redirected, rate-limited, or specially optimized on certain networks, the resulting ranking may not reflect real application performance. When changing the URL, confirm that every candidate route can access the endpoint under comparable conditions.

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

interval defines the periodic probe interval, usually in seconds. An interval that is too short increases request volume and can make the selection react to minor network jitter. One that is too long may delay status updates after a node fails. For typical client devices, probing every few minutes is generally more stable than probing every few seconds, though the appropriate value also depends on the number of nodes and device performance.

tolerance sets the threshold for switching. If the difference between the current node and a candidate does not exceed this tolerance, retaining the current node helps prevent frequent changes. Suppose the current result is 125 ms and another node reports 90 ms. With a tolerance of 50 ms, the 35 ms difference is not enough to trigger a switch. If the gap continues to widen beyond the threshold, the automatic group has stronger grounds to update its choice. Options may appear slightly different across core versions and clients, so refer to the documentation for the Mihomo or Clash core actually in use.

When lazy is enabled, health checks generally favor running when the group is actually used, reducing periodic probes for idle groups. This is useful when a configuration contains many regional groups but only a few are used regularly. If a group carries critical connections that require rapid failure detection, balance discovery delay against the overhead of background probing.

fallback: Preserve primary and backup order

The purpose of fallback is not to “choose the fastest” but to select the first available item in the list. Earlier nodes have higher priority and remain in use as long as the health check considers them available. Only when the current priority node fails does the group look farther down the list. This behavior suits cases where egress identity, region, or route stability matters more than a few milliseconds of latency.

For example, if a work service should consistently use an egress in a particular region, place the primary node first, a backup in the same region second, and a cross-region emergency node last. Even if the backup reports lower probe latency, it will not displace an available primary. This reduces egress changes, but it also means the group may not switch when the primary remains reachable yet performs poorly.

proxy-groups:
  - name: Work Failover
    type: fallback
    proxies:
      - Primary Route
      - Same-Region Backup
      - Cross-Region Emergency
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

“Available” is defined by the health check, which can observe only the specified endpoint. If a node reaches the probe URL but cannot access a particular application domain, fallback may still keep it active. In that case, first verify that the destination domain matches the intended rule, then inspect DNS resolution, destination restrictions, and the route's support for the required protocol. Shortening the probe interval alone cannot resolve a mismatch between the test endpoint and the application endpoint.

After the primary route recovers, the group may return to the earlier node in the list. If the route repeatedly alternates between available and unavailable, failback flapping can occur. Mitigate this by choosing a more reliable probe endpoint, using a sensible check interval, and reconsidering whether an unstable node should have the highest priority. If the goal is to retain the current working egress until a manual change, a manual select group is often a better fit than automatic failover.

Common causes of incorrect failover

• The list order is the reverse of the intended primary and backup priority, placing a lower-priority route first.
• The health-check URL is unreachable through one route even though the actual application endpoint works, causing the node to be marked unavailable prematurely.
• Node names changed after a subscription update, leaving static group references invalid or pointing to different nodes.
• The rule never sends traffic to the fallback group, so the observed egress comes from another group or the final catch-all rule.
• The client UI has cached stale status, and its display is out of sync with the core's actual selection. Check connection logs to confirm the active node.

load-balance: Distribute connections across nodes

A load-balance group operates on multiple independent connections. Based on the configured strategy, the core assigns different connections to available nodes in the group. It does not combine several nodes into one higher-bandwidth tunnel, nor does it arbitrarily split packets from a single TCP connection across multiple egress points. A single-file download using one connection is generally still handled by one node. Distribution becomes easier to observe with multi-connection downloads, many concurrent requests, or multiple devices accessing services at once.

Common Mihomo load-balancing strategies include consistent-hashing and round-robin. Consistent hashing tends to keep the same destination on the same node, reducing frequent egress changes for a site over short periods. Round robin selects available nodes in sequence for successive connections, providing more direct distribution, but separate connections to the same service may use different egress points.

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

For services that are sensitive to login sessions or validate the egress address, consistent hashing is generally safer than round robin. Some sites associate login sessions, risk controls, or regional content with the egress IP. If page assets and API requests use different nodes, users may encounter repeated verification, region changes, or invalid sessions. Even with consistent hashing, resources on different domains may be assigned to different nodes, so financial services, enterprise logins, and workloads requiring a fixed egress are better served by a fixed node or fallback.

Round robin is suitable for large numbers of independent connections that can tolerate egress changes—for example, multiple package downloads, distributed requests for public resources, or high volumes of non-sensitive connections from several devices on a LAN. Any improvement in aggregate throughput still depends on local access bandwidth, remote server limits, upstream node capacity, and the concurrency model. Adding nodes cannot overcome a bottleneck in the home internet connection or destination server.

How subscription nodes work with health checks

When nodes come from a subscription, a common approach is to manage the remote provider with proxy-providers, then reference that provider from multiple proxy groups using use. New nodes can then enter the relevant dynamic groups after a subscription update without copying each name into every group. The provider update interval and health-check interval serve different purposes: the former controls when the node list is fetched, while the latter controls when existing nodes are tested.

proxy-providers:
  provider-main:
    type: http
    url: https://example.com/clash-provider.yaml
    path: ./providers/provider-main.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

proxy-groups:
  - name: Subscription Auto
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

Provider health checks and proxy-group probes may both be active. With many nodes, watch for network requests and device load caused by duplicate probing. The impact is especially noticeable on mobile devices, low-powered routers, and large subscriptions. You can align check intervals, enable on-demand checks, or limit required tests to groups that actually participate in selection. Reducing probes does not mean disabling every check; it means matching the frequency to the required failure-detection speed.

Subscription updates can also change node names, order, or labels. When using filter to select regions, verify that the regular expression does not include test nodes accidentally or omit nodes whose naming format changed. If fallback dynamically references a provider, the order returned by that provider may affect priority. Explicitly listing nodes offers better control for primary and backup routes that require a fixed order, but the list must also be maintained when nodes are renamed.

Choose a proxy group by workload

Everyday web browsing and general applications

Start with url-test, use a moderate probe interval and tolerance, and retain a manual selection option. It provides routine automatic selection among nodes with similar capabilities. If nodes span substantially different regions, create an automatic group for each region and use a top-level select group to choose the region. This prevents automatic testing from moving the egress to a region that does not meet application requirements.

Fixed-region access, work systems, and remote access

Start with fallback. Put the route that best meets the egress requirements first, followed by backups in the same region. If the service strictly binds access to an egress IP, a fixed node or manual group may be more appropriate. Automatic failover improves continuity during an outage, but the egress change itself may trigger security verification by the destination service.

Concurrent downloads and multi-device sharing

Consider load-balance, choosing consistent hashing or round robin according to the workload's need for egress consistency. Do not place sensitive traffic such as logins, payments, or enterprise authentication in a round-robin group. A safer approach is to use rules that send download domains, update services, or selected device traffic to the load-balancing group while keeping other traffic on a stable egress.

Proxy-group selection in TUN mode

TUN mode expands the range of traffic that the core can intercept, but it does not change the basic decision logic of these three proxy-group types. Connections entering through TUN must still match rules before reaching the relevant proxy group. If access behavior changes after TUN is enabled, inspect system routes, DNS hijacking or redirection settings, rule matches, and proxy-group options separately instead of attributing every issue to automatic latency testing.

Troubleshooting frequent switching and incorrect failover

1. Confirm the matched rule. Find the destination domain in the client's connection log and check which proxy group it actually entered. If the rule points to the wrong target, changing health checks will not alter the traffic path.
2. Verify that the group type matches the goal. Using url-test when primary-to-backup order is required, or round robin when a fixed egress is needed, produces results that may look wrong but are consistent with the configuration.
3. Inspect the probe endpoint. Confirm that the test URL reliably returns a success status through every node. Avoid regional restrictions, redirects, or server-side rate limits that could distort the result.
4. Check the interval and tolerance. If url-test switches frequently, increase the tolerance first. If failure detection is too slow, then reassess the check interval rather than immediately setting an extremely short one.
5. Verify node order. A fallback group selects the first available item from top to bottom, so the first entry must be the route that should genuinely have priority.
6. Review subscription updates. Verify node names, filters, and provider status to ensure that the group's actual candidates match expectations.
7. Observe real connections, not just dashboard numbers. The latency panel shows probe results; connection logs reveal which node a workload ultimately used.

The key to choosing a proxy group is to treat “latency ranking,” “primary and backup priority,” and “connection distribution” as separate goals. url-test suits automatic selection among nodes with similar capabilities, fallback preserves an explicit route priority, and load-balance distributes multiple independent connections. After configuration, test with the actual workload to verify rule matches, node selection, and egress stability instead of drawing conclusions from a single latency test.