Configuring Automatic Node Selection in Clash: url-test, fallback, and Latency Tolerance

Before creating an automatic group, use select to pin each candidate node and complete a real request through each. Remove candidates whose protocol is unsupported by the current core, whose subscription is invalid, or which are completely unreachable on the local network. Otherwise health checks will keep failing, and repeated errors will make useful logs harder to find.

Nodes can be listed directly in proxies or referenced through proxy-providers using use. A provider update changes the candidate list, so check name filters, region filters, and empty lists, and use node names that distinguish regions or routes.

A health check makes every candidate node access the address specified by url. If that address is unstable, blocked in some regions, or requires sign-in, the entire group's results become misleading. In most cases, choose a stable HTTPS address with a tiny response and no account requirement, such as a probe page that returns 204.

The test URL should resemble your everyday traffic, but do not use an API with a personal token or send high-frequency requests to a third-party site. A successful node probe only proves that this URL was reachable at that moment; video, AI streaming responses, and UDP still need verification in the relevant app.

No parameter set suits every network. On a stable home network with similar node latencies, use a longer interval and moderate tolerance. Even if a mobile network changes frequently, do not reduce checks to a few seconds. New requests may switch outbound routes frequently; whether existing connections stop depends on node failures and whether the client closes them.

Observe real use for a while after making changes. If Connections shows the node switching back and forth within minutes while candidates differ by only a few dozen milliseconds, increase tolerance or interval before adding more nodes.

fallback does not switch to the second item merely because it has lower latency. As long as the first item passes its health check, it remains in use; only when the first item is unavailable does the group choose a later available item. Configuration order should therefore reflect business priorities—for example, a stable primary route first, followed by a more expensive backup or one in another region.

After the primary route recovers, fallback reevaluates it during a later health check. Existing connections may not migrate when it switches back; new requests are more likely to reveal the new egress. For account dashboards and long downloads, consider a fixed select group to avoid session disruption from egress changes.

When you have many candidate nodes, you do not need to put them all in one url-test. Create a separate url-test for each region, then add the regional groups to fallback in priority order. Each regional group selects a lower-latency node; if the current region is unavailable, the main group switches to the next region. Connections also shows which policy groups handled the request.

The more groups you nest, the harder it is to spot an empty provider, circular references, or duplicate group names. If two levels are enough, do not add a third. Verify that each regional group works on its own before adding it to the primary/backup group.

The earlier YAML fragments only define proxy groups. Edit a copy of the complete configuration, add the new groups to its existing proxy-groups list, and keep the original nodes, proxy-providers, and rules. Do not replace the whole configuration with a fragment or repeat the proxy-groups key.

In Clash Verge Rev v1.6.2 or later, drag the complete YAML copy into the client, create a local profile, and select it for use. The new groups should appear in Proxies. If loading fails, select the original configuration again and check the logs; do not overwrite the original subscription file.

To test fallback, temporarily place a confirmed failed test node that contains no sensitive information first in a separate group and observe whether it moves to the second item; remove it immediately afterward. Do not manufacture a failure by disconnecting the network, disabling the system proxy, or breaking a production configuration, because that changes too many variables at once.

Point the target service's rule to the automatic group, then complete several web, streaming-response, or download requests in a row. Connections should show the expected parent group and specific node. url-test should not jump frequently over tiny latency differences, and fallback should remain on the first item while the primary route is available.

If health checks pass but the original task still fails, switch to select, keep the current node fixed, and retest, then check the protocol, DNS, or target service.