Three proxy group types: choose by latency, priority, or connection distribution

Clash proxy groups determine which outbound connection to use after a rule matches. Rules send connections to a group, and the group selects from its candidate nodes. Switching a proxy group to automatic testing does not change domain rules or route connections that already use DIRECT through a proxy.

Use url-test to automatically select an outbound node with low measured latency, fallback to maintain a defined primary-and-backup order, and load-balance to distribute connections across multiple nodes. These are not performance tiers. Choose based on your needs for latency, connection reliability, and using multiple routes.

Type How it works Best for Key limitation
url-test Test results and switching tolerance Everyday browsing with automatic selection of a low-latency route Low test latency doesn't guarantee high download speeds
fallback Candidate order and availability A fixed primary route with a backup for failures May switch back when the primary recovers
load-balance Distribution method and node health Accessing multiple destinations and parallel connections Doesn't combine bandwidth across multiple routes for a single connection

url-test: Use tolerance to control how often the route switches

url-test sends requests to a specified test URL through candidate nodes, then selects an outbound route based on the results. This is neither an ICMP ping nor a bandwidth test. Test times depend on the proxy connection, the destination's response, and network conditions, so compare candidates using the same test URL.

Basic configuration and parameter units

These are configuration snippets, not a complete subscription. They assume your existing proxies section defines three nodes named “Hong Kong-01,” “Hong Kong-02,” and “Japan-01.” Replace these with the exact names of nodes in your configuration. Don't create a second top-level proxy-groups section; merge these entries into the existing list.

proxy-groups:
  - name: Auto Low Latency
    type: url-test
    proxies:
      - Hong Kong-01
      - Hong Kong-02
      - Japan-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false
  • url: The HTTP or HTTPS address used for health checks. This example uses a test endpoint that returns a small response. Don't use a business page that requires sign-in.
  • interval: 300: Run tests every 300 seconds, or 5 minutes—not every 300 milliseconds.
  • tolerance: 50: Set the switching tolerance to 50 milliseconds to prevent frequent switches when a candidate has only a slight advantage.
  • lazy: false: Keep testing at regular intervals even when the group isn't in use, making it easier to observe and compare nodes. The trade-off is more test requests.

Tolerance isn't a latency limit

Consider these hypothetical results: the current node has a latency of 180 ms, while another measures 155 ms—a difference of just 25 ms. With a tolerance of 50 ms, don't expect every test to switch to the second node. If its latency drops to 100 ms, the wider gap is more likely to trigger a switch. The actual choice also depends on that test's results and whether the nodes are available.

tolerance doesn't mean “unavailable above 50 ms,” and it can't guarantee that a route will stay below a particular latency. For everyday browsing, start with a 300-second interval and 50 ms tolerance, then observe the results. If the outbound route still changes too often, check node quality and the test destination before increasing tolerance. Don't just reduce the test interval to a few seconds.

fallback: Keep primary and backup routes in list order

fallback prefers the first node in the list that passes its health check. It doesn't search all nodes for the lowest latency. If the second node measures 80 ms and the first measures 160 ms, the group still prefers the first as long as it's considered available.

proxy-groups:
  - name: Primary and Backup
    type: fallback
    proxies:
      - Hong Kong-01
      - Japan-01
      - Hong Kong-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

Here, “Hong Kong-01” is the preferred node, “Japan-01” the first backup, and “Hong Kong-02” the second backup. If your service requires a specific region, include only nodes that meet that requirement. Mixing regions in a backup list may improve availability, but it can also change service region, language, or account risk signals.

Failover doesn't migrate sessions

  • Detection takes time: A 300-second interval doesn't mean the group switches immediately when a failure occurs. Detection time also depends on when the next test runs, timeouts, and connection activity.
  • The group may switch back: Once a higher-priority node becomes available again, new connections may use it. The group won't necessarily stay on the backup.
  • Existing connections don't move: If the current node fails, active transfers may be interrupted and the application may need to reconnect. Proxy groups don't migrate TCP sessions.

For remote administration, continuous uploads, and other tasks that need a consistent outbound route, consider a manual select group or a fallback group with a clearly defined order. If a task can't tolerate any route changes, automatic failover still can't replace the application's own reconnection, resume, and session recovery features.

load-balance: Distributes connections, not bandwidth for a single connection

load-balance distributes connections across multiple candidate routes. It doesn't split a single TCP connection across two nodes, so adding three routes won't automatically triple the speed of a single-connection download. Whether multiple tasks or destinations benefit depends on the distribution strategy, route capacity, and destination limits.

proxy-groups:
  - name: Multi-Route Distribution
    type: load-balance
    proxies:
      - Hong Kong-01
      - Hong Kong-02
      - Japan-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

consistent-hashing vs. round-robin

strategy value How connections are distributed When to use it
consistent-hashing Uses destination information for consistent hashing; the same destination usually maps to the same route Everyday access to multiple sites when you want to reduce route changes for the same destination
round-robin Cycles through available candidates when assigning connections Multi-connection tasks where route changes are acceptable

Consistent hashing typically uses the destination's registrable domain for mapping; for IP destinations, it uses the corresponding address information. Exact behavior depends on the core implementation. It doesn't guarantee that every domain associated with an account uses the same route. Login, payment, and API domains may map separately, and changes to the node list can change the mapping.

To use round-robin, change the strategy in the example to strategy: round-robin. Don't assume this means “each request gets an equal share.” Multiple HTTP requests may reuse the same TCP or QUIC connection, and connections—not individual requests—are distributed. For payments, account management, and similar tasks, a fixed route is usually a better fit than load balancing just to use multiple routes.

Connect the rules: Route traffic through an automatic proxy group

Defining a proxy group is only the first step. If your rules still point to an old group, the new group won't handle those connections. The example below uses a manual selection group as the entry point, with three automatic groups and a direct connection option for easy comparison in the client.

proxy-groups:
  - name: Proxy Entry
    type: select
    proxies:
      - Auto Low Latency
      - Primary and Backup
      - Multi-Route Distribution
      - DIRECT

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

This snippet shows only the entry group and rules; merge it with the automatic group definitions above. example.com is a reserved example domain for demonstrating rule matching, not a real service. MATCH handles connections that haven't matched an earlier rule. In a production configuration, keep your existing LAN, direct, and service-specific rules, and put the catch-all rule last. Don't replace your entire routing configuration with this abbreviated example.

  1. Merge the configuration using the client's editor or override feature, then check the YAML indentation. Use spaces—not tabs—for list entries.
  2. Reload the configuration and check that all three automatic groups and “Proxy Entry” appear. Make sure there are no “proxy not found” or circular proxy group reference errors.
  3. Expand “Proxy Entry” on the proxy groups page and select the automatic group you want to test, rather than leaving the original manual node selected.
  4. Start a new connection. Check the matched rule and proxy chain in the connection list to confirm that the final outbound route is what you expect.

Test results can mislead: latency, DNS, and TUN limitations

Tests pass, but the service still fails

A reachable test URL only shows that the route can reach that particular destination; it doesn't prove that every site is accessible. A service may fail because of the outbound region, destination-side blocking, certificate issues, or DNS resolution problems. If this happens, first pin the entry group to a single node and retry the service, then check the connection logs. Don't assume the automatic group algorithm is at fault.

HTTPS tests may also include connection setup and TLS negotiation time. In mihomo, the top-level unified-delay option can reduce the effect of differences in proxy handshake times when comparing latency; it's not a proxy group field. Keep this setting, the test URL, and the network consistent when comparing results. Don't rank numbers gathered under different test conditions.

TUN doesn't change the proxy group's selection algorithm

System proxy and TUN determine how traffic enters the core, rules determine which group receives it, and the proxy group determines the outbound route. Enabling TUN won't make fallback select the lowest-latency node or give load-balance bandwidth aggregation. If an app doesn't appear in the core's connection list, check how its traffic is being captured before changing tolerance.

With Fake-IP, the core can preserve domain matching information through address mappings, but this doesn't replace proxy group health checks. If a node server uses a domain name, make sure its DNS resolution path works too; otherwise, the proxy connection may depend on DNS requests that can only be completed through the proxy itself. DNS failures can make every automatic group node time out, so check the DNS logs to find the cause.

Putting settings into practice: Start conservatively and test

For an initial setup, use interval: 300 across the board. Set lazy: false while troubleshooting, then adjust based on battery life and node count once behavior is clear. For a group with 12 nodes, assuming at least one test per node each cycle, testing every 5 minutes comes to about 144 tests per hour. Actual request counts also depend on extra tests, retries, and manual checks, so this isn't a traffic estimate.

  • Prioritize low latency: Choose url-test, start with a 50 ms tolerance, and check whether new connections switch routes too often.
  • Prioritize the primary route: Choose fallback, put your preferred node first, and confirm that the backup nodes suit your region and use case.
  • Use multiple routes: Choose load-balance and try consistent hashing first. Use round-robin only if your service can handle route changes.
  • Prioritize session stability: Keep a manual select entry and assign a stable node for logins, payments, and long-running tasks.

Change one variable at a time when testing: first pin a node and test URL, then change the group type, and finally adjust the interval and tolerance. Observe at least two complete test cycles, and test new connections, sustained downloads, and the actual service separately. The selected route, service success rate, and connection stability tell you more about whether the setup suits your network than the lowest number in a one-off speed test.