Clash Proxy Group Types: url-test vs. fallback vs. load-balance

How proxy groups connect rules to proxies

A proxy group (Proxy Group) turns the policy selected by a rule into the proxy actually used. For example, a rule can send a domain to “Everyday Proxy,” and that group then picks an outbound proxy based on manual selection, latency checks, or failover logic. Rules answer “Where should this connection go?” Proxy groups answer “Which proxy should this group use?”

This article uses mihomo configuration, the core used by Clash Verge Rev, as an example. The interface displays and switches proxies; the type in proxy-groups determines how a group behaves. System proxy and TUN modes affect how traffic enters the core. They don't turn select into a latency-testing group or change the load-balancing algorithm.

select: manual selection and a fixed outbound proxy

Use select when you need to choose the outbound proxy yourself. In Clash Verge Rev, open the relevant group on the “Proxies” page and click a proxy or subgroup. If the selected proxy fails, a manual group won't switch just because another member is available. However, if the selected member is itself an automatic group, that subgroup will still make its own automatic selection.

Add automatic groups to a manual selection menu

A common setup is to use select for the outer group, with “Automatic low latency,” “Primary and backup,” and individual proxies as members. Choose the automatic group for everyday use, then switch to a specific proxy when you need a particular region or a fixed outbound route. Rules can keep pointing to the same entry point, so there's no need to edit the whole ruleset just to change proxies temporarily.

• Sign-ins, payments, or admin panels: choose a proxy with a consistent region and a known outbound route.
• Everyday browsing: use an automatic latency-testing subgroup to avoid switching manually.
• Troubleshooting: pin a single proxy to avoid automatic switching while you investigate.

A “fixed proxy” doesn't guarantee a “fixed public IP.” Providers may change the outbound IP or use multiple egress points. If your service requires a static IP, confirm the provider's routing and IP policy; a client-side proxy group can't guarantee it.

url-test: choose a proxy by probe latency; tolerance controls how readily it switches

url-test checks a specified test URL through candidate proxies, records the results, and selects a proxy based on those results, the current proxy's status, and the tolerance. It's best suited to proxies in the same region with similar use cases. If you mix regions, the lowest-latency one may keep winning even when it doesn't meet the destination site's regional requirements.

Units for interval, timeout, and tolerance

• interval: 300: The health-check interval is measured in seconds, so this setting means every 5 minutes.
• timeout: 5000: The per-probe timeout is measured in milliseconds, giving each check up to 5 seconds.
• tolerance: 50: Measured in milliseconds, this helps prevent switches caused by small latency fluctuations.
• lazy: true: Enables lazy checks. The group may not probe continuously at the configured interval while unused; this does not mean “every candidate is checked every 300 seconds.”

For example, suppose the current proxy has 105 ms latency and another has 80 ms, a difference of just 25 ms. With tolerance: 50, that small advantage usually won't trigger a switch. If the current proxy rises to 180 ms while the candidate remains at 80 ms, the gap is well beyond the tolerance. If a proxy becomes unavailable, the group still selects another available member; tolerance doesn't force it to keep a failed proxy.

Latency checks aren't throughput tests

The small response from a test URL mainly indicates whether the route is reachable and how long the request takes. A proxy at 80 ms isn't necessarily better for large downloads than one at 120 ms; bandwidth, congestion, routing to the destination, and server load can all affect performance. Also, don't treat the probe latency shown by the client as an ICMP ping value: they measure different paths in different ways.

fallback: fail over in member-list order

fallback checks members from the start of the list and uses the first available proxy. As long as the preferred proxy is healthy, it remains in use; the group doesn't compare all members to find the lowest latency. Put the primary route first, followed by backups. The list order defines priority, not display order.

For example, proxy A has 160 ms latency and proxy B has 70 ms. If A is available and listed first, the group still prefers A. It switches to the next available member only after A fails its health check. If a later check finds that A has recovered, new connections can prefer A again.

Failover doesn't migrate existing connections

An established TCP connection is tied to its original route. If the group switches to a backup proxy, the existing connection can't be moved seamlessly to the new outbound route. A webpage may recover on a new request, but a download, remote terminal, or meeting may need to reconnect. The check interval, timeout, lazy checks, and timing of the failure all affect detection speed. Don't treat interval: 300 as a guarantee that recovery will take exactly 300 seconds.

• Choose primary and backup routes in different failure domains, such as different entry points or servers—not just two names for the same server.
• Use a fallback group to keep a preferred route when possible, not to always choose the lowest-latency proxy.
• If the backup route is metered, monitor actual usage. Health checks also generate a small amount of traffic.

load-balance: distribute connections, not combine bandwidth for one connection

load-balance distributes connections across candidate proxies according to a strategy. It doesn't split a single TCP connection between two proxies, and it isn't link aggregation. A single-connection download is usually limited by the bandwidth of its selected proxy; multi-connection workloads may spread traffic across different egress routes.

Common strategy options

Whether the destination is a domain or an IP, and whether DNS mode preserves the domain name, can affect how traffic is assigned. Don't assume that “one browser always uses one proxy.” An account service may connect to separate login, static asset, and API domains; even with consistent hashing, those connections may use different proxies.

Complete example: one manual entry point and three automatic groups

The following proxy groups and rules are snippets to add to an existing mihomo configuration, not a complete subscription with proxy credentials. HK-A, HK-B, and SG-A must already be defined in the current configuration's proxies list, with names that match exactly. If your proxies come from proxy-providers, use use with the actual provider name; don't enter a provider name as if it were a proxy name in the member list.

proxy-groups:
  - name: Everyday Proxy
    type: select
    proxies:
      - Automatic Low Latency
      - Primary and Backup
      - Multi-Connection Distribution
      - HK-A
      - HK-B
      - SG-A

  - name: Automatic Low Latency
    type: url-test
    proxies:
      - HK-A
      - HK-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    tolerance: 50
    lazy: true

  - name: Primary and Backup
    type: fallback
    proxies:
      - HK-A
      - SG-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    lazy: true

  - name: Multi-Connection Distribution
    type: load-balance
    proxies:
      - HK-A
      - HK-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    lazy: true
    strategy: consistent-hashing

rules:
  - DOMAIN-SUFFIX,example.com,Everyday Proxy
  - MATCH,Everyday Proxy

Three things to check when merging configuration

1. Merge the group list: Add the new groups to the existing proxy-groups; don't define a second key with the same name at the same level. Group names must be unique, and subgroups must not reference each other in a loop.
2. Keep your existing routing rules: example.com is a sample matching domain. If your existing configuration has direct, blocking, or region-specific rules, keep them and put the fallback MATCH rule at the end. Rules are matched in order, so don't put the catch-all before rules for specific traffic.
3. Check which configuration is active: Confirm the active configuration on the “Profiles” page in Clash Verge Rev. Refreshing a remote subscription may overwrite direct edits. For long-term changes, use a merge configuration or script mechanism supported by your client, then inspect the final effective configuration.

All three automatic groups above use lazy: true, which can reduce probing when they aren't in use. If you need continuous background checks, consider setting it to false and keep an eye on the number of proxies and check frequency. For example, a group with 20 proxies and a 300-second interval performs 20 probes per round. If multiple groups reference the same proxies, also account for core scheduling and provider health checks when assessing the actual load.

Choose a setup for your use case, then verify which rules and proxies are actually used

Three common configuration choices

• Web browsing and everyday work: Use an outer select group with a same-region url-test group selected by default. Start with a 300-second check interval and 50 ms tolerance, then adjust based on observed fluctuations.
• Prefer a primary route with a backup: Use fallback and put the route you want to use most of the time first. Allow connections to reconnect on failure, and test what happens when the primary route recovers.
• Many connections that can use different egress routes: Consider load-balance. Try consistent hashing first, then decide whether round-robin is actually needed. Don't switch to load balancing just to speed up a single download.

How to verify your setup in Clash Verge Rev

1. Open the “Profiles” page and confirm that the target configuration is active. If the configuration fails to load, check the “Logs” page for errors involving the group type, proxy name, or YAML indentation. Don't continue testing with a configuration that failed to load.
2. Open the “Proxies” page and select the subgroup to test under “Everyday Proxy.” Use “Rule” mode to verify rule-based routing. “Global” mode uses the global proxy entry point, so its results may differ from your rules.
3. Run a group latency test and note the time, current proxy, and latency. Don't just look for a green result on an individual proxy; confirm which group the outer entry point actually selected.
4. Visit a site that should definitely use the proxy, then filter by domain on the “Connections” page to check the matched rule and proxy chain. Seeing a group selected doesn't prove that the request used it.
5. Close existing page connections or start a new request before comparing results. To test primary-route failure, temporarily disable the primary in a recoverable test environment, then record when the failure is detected and when a connection through the backup is established.

If a latency test succeeds but a site won't load, distinguish reachability of the test URL from reachability of the actual destination: check DNS resolution for the destination domain, rule matching, proxy region restrictions, and errors in the logs. If the outbound IP doesn't change after switching, check whether an existing connection is being reused, whether the rule is bypassing the proxy, whether the wrong global entry point is selected, and whether both proxies share the same public egress IP.

The key to choosing a proxy group isn't how automated it is, but whether its selection criteria fit your needs: use select for manual control, url-test to choose by latency, fallback for ordered primary-to-backup switching, and consider load-balance to distribute multiple connections. Rules, groups, and proxies each have distinct roles, making it easier to troubleshoot one layer at a time. For configuration fields, consult the protocol reference; for related concepts, see the glossary.