url-test, fallback, and load-balance: Which Clash Proxy Group Should You Use?

The short answer: these three proxy groups solve different problems

Proxy groups in Clash and Mihomo configurations are not simply lists of multiple nodes. The group type determines how the client probes nodes, chooses an exit, and responds when node health changes. url-test seeks the node with the lowest current measured latency, fallback selects the first available node in configuration order, and load-balance distributes different connections across multiple available nodes.

The most common misconception is treating all three as automatic best-node selection. In reality, lowest latency, highest priority, and distributed connections are three different decision models. A node with 62 ms latency may be selected by url-test but not used by fallback; and after a download goes through load-balance, one TCP connection is not automatically split into three to combine their bandwidth.

url-test: probe regularly and select a low-latency node

url-test makes the nodes in a group access the same test URL, records the time needed to establish a connection and receive a response, then selects the node with the better result. It suits setups where node quality fluctuates and users want to avoid manual switching. The result reflects one small request from the client through the node to the test target; it is not the same as peak-hour download speed and cannot fully represent cross-network streaming quality.

Basic configuration and parameter meanings

proxy-groups:
  - name: Auto Select
    type: url-test
    proxies:
      - Hong Kong-01
      - Hong Kong-02
      - Singapore-01
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

• url is the health-check target. The response should be small, the service stable, and the address reachable through the proxy. The example returns 204 when the address responds normally, helping keep probe traffic low.
• interval: 300 schedules one periodic check every 300 seconds, or 5 minutes. It is not measured in milliseconds, and latency testing does not restart every time you open a web page.
• tolerance: 80 means the current node is normally retained when the latency gap stays within 80 ms, preventing constant switching between 70 ms and 76 ms.
• lazy: true reduces proactive checks for proxy groups that have not been used for a long time. Exact scheduling depends on the core version, but the group still uses health status when it is selected.

Why tolerance should not always be set to 0

Suppose one test measures Hong Kong-01 at 68 ms and Hong Kong-02 at 75 ms. With zero tolerance, a few milliseconds of network jitter can change the result; if the next round shows 79 ms and 72 ms, the group may switch back to Hong Kong-02. Existing TCP connections usually do not migrate seamlessly, while new connections use a different exit. A logged-in service may also detect the IP change.

On a home broadband connection, start with 50–100 ms. When nodes are in the same region and have similar latency, 80 ms is a stable starting point. If nodes span Asia, Europe, and North America, split them into regional groups instead of pushing every service toward the nearest region based on latency alone. If you need faster movement toward the lowest-latency route, set interval to 120–300 seconds and tolerance to 30–50 ms, but higher probe frequency also creates more requests to nodes and test services.

How to interpret one real measurement

In a repeated test on a 500 Mbps home broadband connection, three nodes show median latency of 61 ms, 88 ms, and 142 ms to a 204 endpoint, with jitter ranges of about 9 ms, 34 ms, and 18 ms. url-test will favor the 61 ms node, but the second node may still deliver higher throughput for large-file downloads. For a default web-browsing exit, low latency is a reasonable guide; for downloads, also check sustained speeds on files over 100 MB, packet loss, and peak-hour performance.

fallback: use the first available node by priority

The key idea behind fallback is order, not finding the lowest-latency node among all available options. The first item is the primary route, the second is the first backup, and the third is the second backup. If the first item passes the health check, the group keeps using it even when its latency is 160 ms and the second item measures just 55 ms. This predictability suits services that need a fixed region, carrier, or exit identity.

proxy-groups:
  - name: Primary and Backup Routes
    type: fallback
    proxies:
      - Hong Kong-Dedicated
      - Hong Kong-Backup
      - Singapore-Backup
    url: https://cp.cloudflare.com/generate_204
    interval: 180
    lazy: false

When failover is triggered

The core uses health checks to determine whether the current higher-priority node is available. After the primary node repeatedly fails to complete a probe, new connections move to the next available node. Once the primary recovers and passes the check again, the group can return to the higher-priority node. Switching does not guarantee that an active video stream, SSH session, or download remains uninterrupted because its original connection and route have already failed.

interval: 180 means a regular check every 3 minutes, so this is not millisecond-level hot standby. Actual failure detection time also depends on on-demand probes, timeout settings, and core scheduling. If the service needs faster detection, lower the interval to 60–120 seconds and accept the additional probe traffic. For typical home use, 180–300 seconds usually balances responsiveness and checking overhead.

How should nodes be ordered?

1. Put the primary node that best meets the business requirements for region, exit identity, and availability first.
2. Use a node in the same region but on a different server or route as the second option to reduce changes in the region detected by services.
3. Place cross-region backup nodes last, so an entire regional route failure still leaves an available exit.
4. Do not sort nodes by a single latency screenshot; observe stability at least during weekday evenings from 8:00 to 11:00 p.m.

Streaming is a common use for fallback. If the primary node is confirmed to access the target catalog and the backup is in the same region, the region remains consistent during failover. By contrast, putting nodes from multiple countries in url-test may let latency changes move the next connection to another region, changing the content catalog or triggering login risk controls.

load-balance: distribute connections, not single-connection bandwidth

load-balance distributes connections among multiple healthy nodes. Opening a web page often creates simultaneous requests for HTML, scripts, images, and APIs, and those requests may go through different nodes. Downloaders that support chunking and multiple threads may also create multiple connections, allowing them to use multiple exits. However, one established TCP or QUIC connection is normally carried by a single node; three 100 Mbps nodes do not automatically become one 300 Mbps single connection.

proxy-groups:
  - name: Concurrent Downloads
    type: load-balance
    proxies:
      - Download-Node-01
      - Download-Node-02
      - Download-Node-03
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    strategy: consistent-hashing

consistent-hashing and round-robin

Common load-balancing strategies in Mihomo include consistent-hashing and round-robin. Consistent hashing uses information such as the destination to map similar requests consistently to a node, reducing repeated exit-IP changes for the same site over a short period. Round-robin simply assigns new connections to available nodes in sequence, distributing them more evenly but offering less stability for sites that expect a consistent session exit.

Configuration fields should be checked against the capabilities of the current Mihomo version. Some older cores do not support the same strategy values, and a client may ignore unknown fields during import. After editing, open “Settings” → “Logs”, temporarily set the log level to debug, reload the configuration, and check for parsing errors. Once everything works, restore info to avoid generating excessive logs over time.

Why login, payments, and streaming should not use round-robin directly

Some services associate a session with its exit IP, region, or risk score. If node A opens the login page and node B handles a later API request, the service may require verification again or invalidate the session. Video playback may also complete regional detection through node A while fetching segments through node B, causing a 403, renewed authentication, or lower quality. This traffic is better suited to consistent hashing, a single-node selection group, or a region-fixed fallback group.

How interval, tolerance, and health checks work together

interval controls the approximate interval between periodic checks and is usually measured in seconds. Lower values update status sooner but increase probe traffic. At 300 seconds, each participating node visits the test address about once every 5 minutes; a 20-node group theoretically generates about 20 probes per round. If a subscription contains 100 nodes and you create several duplicate checking groups, there is no need to reduce the interval to 30 seconds.

tolerance mainly stabilizes switching in url-test. It is not a timeout and does not make a node “wait 80 ms longer.” A value of 80 means a candidate must show a substantial latency advantage before replacing the current node. fallback uses order and availability, while load-balance distributes connections, so neither normally relies on tolerance for its core behavior.

Three practical starting-point profiles

• Everyday browsing: interval: 300, tolerance: 80, prioritizing fewer frequent switches.
• Noticeable network fluctuations: interval: 180, tolerance: 50, to detect route changes sooner.
• Fixed primary and backup exits: use fallback with interval: 180, and order nodes by business priority.
• Heavy concurrent downloads: use load-balance with interval: 300, removing nodes with clearly poor throughput first.

The test address also affects the result. A target that is too far away mainly measures the cross-border path from the node to that service; a target reachable by only some nodes can falsely mark healthy nodes as failed. Use a stable 204 service for general checks, then validate specific services separately. Do not download a large file as a health check every few minutes; it continuously consumes traffic and server bandwidth.

Combine by use case: everyday browsing, streaming, and downloads

Everyday browsing: url-test with manual selection

Everyday web browsing and messaging usually benefit most from fast response times. Create an automatic url-test group, then use select to combine it with the automatic group and frequently used individual nodes. This keeps the automatic result as the default while allowing you to pin a specific exit under “Proxy” → “Node Selection” when a site triggers risk controls or a particular node has access problems.

proxy-groups:
  - name: Auto Select
    type: url-test
    proxies:
      - Hong Kong-01
      - Hong Kong-02
      - Singapore-01
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 80

  - name: Everyday Proxy
    type: select
    proxies:
      - Auto Select
      - Hong Kong-01
      - Singapore-01
      - DIRECT

Streaming: same-region fallback

First filter nodes by the regions where the service is available, then create a same-region fallback group. Put a verified, stable, peak-hour-capable route first and another server in the same region second. Point the target service domains or matching rule set to this group. The goal is not the lowest 204 latency, but regional consistency and failover when the primary route fails.

Multi-threaded downloads: load-balance with comparable node quality

A downloader configured for 8 or 16 concurrent connections gives the load-balancing group a chance to distribute different connections across multiple nodes. Browser downloads using one connection, and object-storage requests that create only one connection, generally remain limited by a single node. Before using it, confirm that the subscription allows concurrent connections and that accessing the same download URL from different exits will not invalidate its temporary link.

Connect proxy groups to rules

rules:
  - DOMAIN-SUFFIX,example-video.com,Streaming Primary and Backup
  - DOMAIN-SUFFIX,example-download.com,Concurrent Downloads
  - MATCH,Everyday Proxy

Rules are matched from top to bottom, and matching stops at the first hit. A service often uses multiple domains, so adding only its homepage may miss video segments, image CDNs, or login APIs. When using a rule set, check its update source and actual contents. After editing, open the client’s “Connections” page to see which rule matched the target domain and which proxy group handled it; this is more accurate than checking only whether the page opened in a browser.

Common configuration errors and troubleshooting order

All nodes show timeout

1. Use a browser or command line to confirm that the test address itself is reachable.
2. Check whether DNS resolution succeeds and whether the logs show dns resolve failed.
3. Replace the test address with another stable target that returns a small response, then run the latency test again.
4. Confirm that node names exactly match the proxies list, including spaces, capitalization, and symbols.
5. Check whether a subscription update renamed the nodes, leaving the proxy group pointing to old names.

url-test switches nodes too often

First raise tolerance from 0 or 10 to 50–100, then widen interval from 30 seconds to 180–300 seconds. If nodes from different regions are mixed together, split them by region. You can also run 10 consecutive tests and record the median and variation range; a node with low average latency but over 100 ms of variation may be a worse default exit than one that stays near 90 ms.

fallback did not choose the lowest-latency node

This is expected. fallback selects the first available node in the list; it does not compare speeds. To choose the lowest-latency node automatically, use url-test. If the primary should remain fixed and switch only on failure, keep fallback and adjust the node order.

Download speed did not increase after load-balance

First confirm that the download tool actually opened multiple connections, then inspect the client’s “Connections” page to see which routes each connection uses. With only one connection, the speed limit still comes from a single node. If there are many connections but they all target the same destination, consistent hashing may keep them on one node. Before switching to round-robin, assess whether the download site permits exit-IP changes. Even with evenly distributed connections, source-side throttling, local bandwidth, and shared node bandwidth can remain bottlenecks.

Final choice: define the business goal first, then choose the group type

Choose url-test when you need “the fastest responder”; choose fallback when you need “the backup only after the primary fails”; choose load-balance when you need “concurrent connections distributed across different nodes.” None is universally best—the decision model simply needs to match the service.

A practical configuration often uses several group types at once: url-test for the everyday default exit, fallback for fixed-region services, and load-balance exclusively for concurrent downloads, with an outer select group for manual override. Combined with rules ordered from specific domains to MATCH, this sends each kind of traffic to the right group instead of making one automatic group handle everything.