Clash Proxy Group Types Compared: How to Choose url-test, fallback, or load-balance

Start by separating proxy groups, nodes, and proxy rules

Clash and Clash Verge Rev, which uses the mihomo core, organize proxy nodes into proxy groups. Rules then determine which group handles each connection. A proxy group is not a new proxy server, nor does it change a node’s original protocol, transport, or egress location. Its job is to choose which member of the group handles the current connection.

For example, rules can send video-streaming domains to a “Streaming” group, work-related domains to a “Stable Routes” group, and all other traffic to a “Default Proxy” group. Each group can use a different type: url-test favors the available member with the lowest measured latency, fallback uses the first available member in configuration order, while load-balance distributes different connections across multiple available members.

The differences therefore cannot be reduced to “which one is fastest.” At minimum, compare these four dimensions:

Member selection: whether members are chosen by latency, fixed priority, or a distribution algorithm.
Failure behavior: whether the group retests, moves down the priority list, or continues distributing connections among the remaining members.
Egress consistency: whether the same destination or session should keep using the same egress address whenever possible.
Device overhead: scheduled probes consume a small amount of network traffic, battery, and background resources, so mobile devices need sensible intervals in particular.

What health checks actually measure

Automatic policies usually access the test URL configured in the profile and update availability or latency at the chosen interval. Common test URLs return a very small HTTP response, helping determine whether DNS, TCP, TLS, and the proxy path can complete a request. This reflects basic connectivity, but it is not equivalent to the actual download speed of every website.

The test target’s location, the route from a node to that target, short-term congestion, and the ISP network all affect the result. A node with the lowest latency to the test URL is not necessarily the fastest for a service in another region. When a service has specific regional or reliability requirements, first filter nodes by purpose, then use an automatic policy within the smaller set.

url-test: choose an available member by probe latency

url-test tests connectivity for members in the group and selects the available member with the lower measured latency. It works well when members offer similar capabilities and share the same egress region, while the main concern is interactive latency. For example, when several ordinary routes are available in the same region, url-test can handle basic selection automatically and reduce frequent manual switching.

A common configuration structure looks like this. Supported fields depend on the specific core version, so consult the current mihomo configuration documentation and client logs before importing it:

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

interval sets the testing interval, usually in seconds. A very short interval increases background probe frequency without necessarily improving the experience; a very long interval may delay recognition of route changes. Desktop devices that stay online can use an interval of several minutes based on network stability, while mobile devices may benefit from a longer interval.

tolerance reduces frequent switching when latency differences are small. Suppose the current member measures 95 ms and another measures 80 ms. Because the gap is small, keeping the current member is often more stable than switching immediately. Lower is not always better; setting the value to zero can make minor measurement jitter repeatedly change the selected member.

When lazy is enabled, the core can defer the relevant tests until the proxy group is actually used, reducing background requests from groups that remain idle. The exact trigger and caching behavior depend on the core implementation, so use the logs and the client’s displayed last-test time when interpreting the result.

When to use url-test—and its limits

Well suited to web browsing, code repository access, and everyday connections that benefit from low response times.
Best for a group of nodes in the same region, serving the same purpose, and offering comparable quality; avoid mixing clearly different egress capabilities and selecting solely by latency.
Probe latency is not a direct measure of bandwidth. Large downloads depend more on egress capacity, server throttling, and sustained congestion.
When the selected member changes, new connections may use a different egress address. Use caution with login sessions that depend on a consistent egress.

fallback: use the first available member in order

The core idea behind fallback is priority, not finding the member with the lowest latency. The core checks whether each group member is available and prefers the first available item in the list. Only when the preferred member is unavailable does it move to the next one; once the preferred member recovers, subsequent new connections usually return to the higher-priority member.

proxy-groups:
  - name: Stable Route
    type: fallback
    proxies:
      - Primary Route
      - Backup Route-One
      - Backup Route-Two
    url: http://www.gstatic.com/generate_204
    interval: 300
    lazy: true

This logic is especially useful when routes have clear priority levels. For example, the primary route may offer a fixed egress, support the required services, and remain stable over time, while backup routes are used only when it fails. Even if a backup occasionally reports lower latency, fallback will not bypass a primary route that is still available.

“Available” must be understood in the context of the test URL. A successful test only proves that a node can reach that target; it does not guarantee access to every service. If the primary route passes the connectivity test but a business domain is affected by routing, regional restrictions, or server-side policy, the group may still consider the primary available. In that case, adjust the business rules, split the groups, or use a more representative test target instead of simply shortening the check interval.

When fallback is the better choice

Remote work, region-locked services, home gateways, and long-running devices often prioritize keeping the preferred route unchanged and moving down the list only on failure. That requirement matches the ordering semantics of fallback. Put the member you genuinely want to use long term first, and make sure backup members provide the same business access.

If list order has no clear meaning and every member can be swapped freely, url-test is usually closer to the needs of everyday automatic selection. Conversely, if users need to choose the current node manually, use the select type rather than expecting fallback to remember a one-time manual choice.

load-balance: distribute connections across multiple available members

The primary goal of load-balance is not to select one “fastest node,” but to distribute different connections across multiple available members in the group. It suits large numbers of independent requests, concurrent downloads, or a gateway shared by multiple devices. It cannot directly combine the bandwidth of several nodes into one already established connection.

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

The common consistent-hashing strategy maps connections consistently based on destination information, so the same or similar destinations tend to use the same member while the member list remains stable. This can reduce frequent egress changes for consecutive requests to one site. If a member fails or the list changes, some mappings will still be reassigned, so the egress is not permanently fixed.

round-robin is closer to taking turns when assigning new connections. It gives members more even opportunities, but an application accessing multiple domains or opening multiple connections may use different egress addresses. Available strategy values vary across Clash branches and mihomo versions. Check the current core documentation before use; do not copy fields from another implementation directly into your configuration.

Load balancing is not single-connection aggregation

When a browser downloads one file, the server may establish only a single connection, which usually passes through one member. Overall throughput can benefit from multiple routes only when a downloader, browser, or application opens several independent connections and those connections are assigned to different members. The final speed still depends on the local network limit, node throttling, the destination server, and protocol behavior.

Load balancing can also create egress consistency issues. Some websites may treat source addresses that change frequently over a short period as suspicious, affecting login sessions, CAPTCHA frequency, or regional content. For these services, use rules to send domains to a fallback, url-test, or fixed select group, while directing static assets, software updates, and other concurrent requests to a load-balancing group.

UDP traffic also requires attention to session mapping and node support. Voice, gaming, and QUIC connections are sensitive to path changes, so related traffic should not be moved frequently between egresses merely for “balance.” After configuration, test packet loss, latency variation, and reconnection behavior with the actual application instead of looking only at health-check values.

Choose a proxy group by device and use case

Everyday desktop browsing: consider url-test first

Windows, macOS, and Linux desktops often handle web browsing, code downloads, and instant messaging at the same time. If nodes are in the same region and offer similar access, use url-test with a sensible tolerance to prevent needless oscillation. For domains that require a fixed region or stable egress, use rules to route them to a separate fallback or manual selection group.

Remote work and fixed services: consider fallback first

Enterprise systems, remote desktops, admin panels, and long-lived login sessions value predictability. Put the route that best meets the requirements first, then order backups by actual reliability; this is more appropriate than sorting purely by millisecond latency. Verify that backup members support the target services, DNS resolution, and UDP in advance rather than discovering incompatibility after the primary fails.

Home gateways and multi-device concurrency: use load-balance carefully

When a router or gateway handles several devices at once, the high connection count makes load balancing more useful for distributing connections. Use rules to isolate services that require a consistent egress, then send system updates, static assets, and ordinary concurrent requests to load-balance. If gateway hardware is limited, also monitor the resources consumed by health checks, TUN forwarding, and tracking a large number of connections.

Mobile devices: extend the test interval and reduce the member set

Laptops and mobile devices switch between Wi-Fi, hotspots, and cellular networks. Changes in the network environment can invalidate probe results on their own, making overly frequent health checks of limited value. Reduce the number of members in automatic groups, lengthen the interval, and enable suitable lazy checks. If a device uses a proxy only occasionally, a manual selection group may be clearer than a complex automatic policy.

TUN mode does not change proxy group semantics

TUN mode takes over more system traffic, including some applications that ignore system proxy settings. It does not turn url-test into load balancing or change the member order of fallback. Once traffic enters mihomo, it is still matched to a proxy group by the rules, and the group then selects a member.

After TUN is enabled, more traffic is covered, so DNS, LAN traffic, and UDP applications may also enter the core, making proxy group issues more apparent. Troubleshooting should distinguish three stages: “Was the traffic captured by TUN?”, “Which proxy group did the rules match?”, and “Which member did the group ultimately select?”

Troubleshooting order when a proxy group does not switch as expected

Confirm the configuration actually in use.
A subscription update may generate new proxy groups, while overrides may change group names, members, and test parameters. First confirm the active profile on the configuration page in Clash Verge Rev, then inspect the contents of the running proxy group.
Check the rule match result.
If a connection never enters the target proxy group, changing the group’s algorithm will have no effect. Open the connections or logs page and confirm the domain, destination address, rule type, and name of the proxy group ultimately matched.
Check the health-test status.
Review each member’s last test time, latency, and availability. If every member times out, check the test URL, DNS, the nodes themselves, and the local network. If only a few members fail, verify those routes individually.
Verify names and indentation.
YAML is sensitive to indentation, and names under proxies must exactly match the names of nodes or other proxy groups. If a name contains special characters, enclose it in quotes to avoid parsing ambiguity.
Retest with a new connection.
Close existing sessions in the test application, or wait for them to end before visiting again. Refreshing the proxy status shown in the interface does not immediately migrate every established connection.
Separate DNS failures from proxy failures.
If a domain fails to resolve, the policy group may not have a reachable target yet. Check DNS logs, nameserver settings, and hijacking rules first, then investigate node selection. If the IP works but the domain does not, troubleshoot the DNS path first.

Quick conclusions for the three strategies

Need to automatically choose a low-latency member: use url-test and reduce frequent switching with tolerance.
Need a fixed primary route with ordered backups: use fallback and order members by real business priority.
Need to distribute many independent connections across multiple members: use load-balance while accounting for egress consistency.
Need the user to specify a node explicitly: use select instead of simulating manual control with an automatic strategy.

Real-world configurations can combine these approaches: a top-level proxy group can provide manual selection, with automatic latency testing, failover, and load-balancing groups nested inside. Rules should reference group names with clear purposes, while each group should contain comparable members. Adjust test URLs and intervals for the device and workload. This makes status easier to review in Clash Verge Rev and helps identify whether a failure comes from the rules, health checks, or the node itself.

Clash Proxy Group Types: How to Choose url-test, fallback, or load-balance