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

Both url-test and fallback run health checks, but they optimize for different goals. url-test compares probe latency among candidate nodes and selects a lower result that meets its conditions; fallback uses the first available node in configuration order and moves down the list only when the current one fails.

The former is suited to favoring lower latency among equivalent nodes; the latter is for “primary route first, backup route if needed.” If you simply want to choose a node yourself, use select. To distribute connections across multiple routes, use load-balance; fallback is not a substitute.

Before creating an automatic group, use select to pin each candidate node and complete one real request through it. Remove candidates whose protocols the current core does not support, whose subscriptions have expired, or that are completely unreachable from the local network. Otherwise, health checks will fail continuously and flood the logs with useless results.

Nodes can be listed directly under proxies or referenced from proxy-providers with use. New nodes enter the candidate pool after a provider update, so watch name filters, region filters, and empty lists. A group can appear to exist even when it contains no items.

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 single parameter set fits every network. On a stable home network where node latencies are similar, use a longer interval and moderate tolerance. Even on a mobile network that switches frequently, do not reduce the interval to a few seconds, because repeated egress changes interrupt sign-ins and streaming connections.

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 there are many candidates, you do not need to put every node into one url-test. Create a separate url-test for each region, then place those regional groups in fallback priority order. This separates “choose by latency within a region” from “preserve primary/backup order across regions,” and Connections can show which groups a request traversed.

More levels make empty provider results, circular references, and duplicate group names harder to spot. If two levels express the goal, do not add a third. Verify every lower-level group on its own before handing it to the parent group.

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 every health check is green but the original service still fails, pin the current node, retest, and return to the protocol, DNS, or target service. The standard for keeping an automatic group is simple: the service is stable, egress changes are explainable, and primary/backup order matches expectations. A green probe page alone does not mean setup is complete.