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

First, understand what proxy groups solve

After Clash or mihomo loads a subscription, it usually has a set of proxy nodes. Proxy groups sit between nodes and routing rules: a rule sends a request to a proxy group, and the group chooses the node that handles it. A manual group lets you choose the node; an automatic group keeps selecting one based on latency, availability, or an allocation algorithm.

url-test, fallback, and load-balance all run health checks on nodes in the group, but each uses a different selection goal. Treating them simply as “automatic node selection” can lead to incorrect configurations. For example, a backup route needs a stable primary/secondary order, not lowest-latency selection; a download job may need connections spread across nodes, but load balancing does not combine bandwidth for a single connection.

Proxy group type	Primary goal	Selection method	Best for
`url-test`	Reduce access latency	Choose the healthy node with the lowest test latency	Web browsing, search, and interactive applications
`fallback`	Keep a route available	Use the first healthy node in list order	Primary and backup routes, remote work
`load-balance`	Distribute multiple connections	Allocate connections using consistent hashing or round-robin	Multi-connection downloads, concurrent requests, and batch jobs

url-test: select primarily by response latency

url-test accesses a specified test URL through each node in the group, records the response time, and chooses a faster available node. It works well for web browsing, instant messaging, remote terminals, and other latency-sensitive traffic. Results such as 68 ms, 115 ms, or 240 ms describe the round trip for the test request—not download speed or the node’s available bandwidth.

A ready-to-use basic configuration

proxy-groups:
  - name: "Auto Select"
    type: url-test
    proxies:
      - "Hong Kong 01"
      - "Hong Kong 02"
      - "Japan 01"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80
    lazy: true

rules:
  - DOMAIN-SUFFIX,example.com,Auto Select
  - MATCH,Auto Select

This configuration runs a health check every 300 seconds, and the test URL returns an empty response when it is working normally. tolerance: 80 means the current node is kept when its latency is not clearly more than 80 ms worse than a candidate, helping prevent frequent switching. If the current node is 92 ms and the new result is 54 ms, the 38 ms difference usually favors staying put; if the new node is 55 ms while the current node rises to 190 ms, switching makes more sense.

How to tune the options safely

url: Use a test URL that returns a small, stable, predictable response. If the test target is rate-limited or blocked in a region, every node may be falsely marked unhealthy.
interval: The unit is seconds. Start with 300 seconds for everyday use; reduce it to 120 seconds when network conditions change frequently. A fixed home network can reasonably use 600 seconds.
tolerance: The unit is milliseconds. Setting it to 0 makes even small latency changes affect selection, which can cause repeated switching between similarly performing nodes. A common range is 50–150 ms.
lazy: When enabled, unused proxy groups can reduce unnecessary active testing. If a backup group must be monitored continuously, decide whether to disable it based on core behavior and operational needs.
proxies: Node names must exactly match the names defined in the configuration. When names contain spaces, region symbols, or numbers, quoting them is recommended.

The lowest latency does not always provide the best experience. One node may test at 48 ms but offer only 8 Mbps of usable evening bandwidth; another may test at 86 ms while consistently reaching 120 Mbps. The first may feel better for browsing, while the second may be better for large downloads. So url-test should be understood as latency-based selection, not an overall performance score.

fallback: preserve availability by priority

fallback also performs health checks, but it does not search all healthy nodes for the lowest latency. It checks nodes in the order listed under proxies, using the first one that is currently available. It switches to the second only after the first fails; once the first recovers and passes its checks, the group can return to the preferred route.

This behavior suits a clear “primary route first, backup as a fallback” requirement. For example, a business may need a fixed regional exit: keep the primary node first, and allow a same-region backup only when the primary connection fails. Even if the backup is 30 ms faster, it should not preempt the primary.

Primary/backup route YAML example

proxy-groups:
  - name: "Office Route"
    type: fallback
    proxies:
      - "Singapore Dedicated"
      - "Singapore Backup"
      - "Japan Backup"
    url: "http://www.gstatic.com/generate_204"
    interval: 180
    lazy: false

rules:
  - DOMAIN-SUFFIX,corp.example,Office Route
  - DOMAIN-SUFFIX,meeting.example,Office Route

The order is the priority: use “Singapore Dedicated” first, switch to “Singapore Backup” when it is unavailable, and use “Japan Backup” only if both fail. interval: 180 checks again about every three minutes. If a failure occurs between checks, a new connection may still experience a timeout first, so services that require fast recovery should not use an interval that is too long.

When fallback is the wrong choice

If you always want the node with the lowest current latency, use url-test.
If several nodes should handle many independent connections at the same time, consider load-balance.
When nodes have no defined priority and differ only in name order, fallback will not automatically compare their speeds.
A login session that requires a fixed exit address should not be placed casually in a cross-region backup group, or the exit region may change after failover.

load-balance: distribute connections across nodes

The goal of load-balance is for multiple healthy nodes in the group to share connections, rather than selecting one “fastest node.” It is a good fit for pages with many independent resources, segmented downloads, concurrent API requests, and batch jobs. The allocation method is controlled by strategy; common mihomo strategies include consistent-hashing and round-robin.

Consistent hashing configuration

proxy-groups:
  - name: "Concurrent Routing"
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - "Hong Kong 01"
      - "Hong Kong 02"
      - "Hong Kong 03"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    lazy: true

rules:
  - DOMAIN-SUFFIX,download.example,Concurrent Routing
  - DOMAIN-SUFFIX,static.example,Concurrent Routing

consistent-hashing creates a stable mapping from destination information, so the same destination tends to use the same proxy while the node set remains largely unchanged. This reduces frequent exit-IP changes across requests to one site, making it useful for logged-in sessions, CDN resources, and situations that need some exit consistency.

Round-robin configuration

proxy-groups:
  - name: "Round-Robin Nodes"
    type: load-balance
    strategy: round-robin
    proxies:
      - "Japan 01"
      - "Japan 02"
      - "Japan 03"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    lazy: true

round-robin assigns new connections to healthy nodes in sequence, distributing connection counts more directly. It suits concurrent jobs where the service permits exit changes. If a site is sensitive to IP changes, round-robin can cause extra issues with logins, CAPTCHA challenges, or session checks. In that case, prefer consistent hashing or use a single-node group.

Health-check options and node sources

All three group types depend on health checks. If results show timeouts or negative values, do not immediately assume every subscription node has failed. First verify that the test URL is reachable, the system clock is correct, DNS can resolve the destination, and the local firewall is not blocking the core process. If a test URL is unstable on a particular network, try another HTTPS or HTTP URL that returns a small response and compare the results.

Symptom	Check first	Recommended action
All nodes time out at once	Test URL, DNS, and local network	Open the test URL directly in a browser and inspect the core logs
One node keeps timing out	Node parameters and server status	Select the node manually and test an actual connection
url-test switches too often	`tolerance` is too small	Start at 80 ms or 100 ms and adjust
fallback does not choose the lowest-latency node	Node order	Reorder by business priority or switch to url-test
Login expires after load balancing	Exit address changes frequently	Use consistent hashing or a single-node group

Use proxy providers when you have many subscription nodes

When nodes are updated dynamically by a subscription, listing every node under proxies is difficult to maintain. mihomo can define the subscription source with proxy-providers, then reference the provider from a proxy group with use. After an update, matching nodes are added to the relevant group.

proxy-providers:
  main-subscription:
    type: http
    url: "https://subscription.example/profile.yaml"
    path: "./providers/main.yaml"
    interval: 21600
    health-check:
      enable: true
      url: "http://www.gstatic.com/generate_204"
      interval: 300

proxy-groups:
  - name: "Hong Kong Auto"
    type: url-test
    use:
      - main-subscription
    filter: "(?i)香港|港|HK"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

filter uses a regular expression to select nodes by name. This example keeps nodes whose names contain “香港,” “港,” or “HK”; (?i) makes English matching case-insensitive. Subscription naming varies: you may see “Hong Kong,” “HKG,” or regional flag symbols. Review the node list first, then adjust the expression to match the actual names.

Both the provider layer and the proxy-group layer may run health checks. The former maintains node availability status; the latter selects among nodes. With 100 or more nodes, setting several check intervals to 30 seconds can create a large number of probe requests. Everyday configurations typically use 300 seconds; a subscription refresh interval can be 21600 seconds, or six hours.

Apply the configuration in Clash Nyanpasu

First confirm that the running core supports the proxy-group types and options in your configuration. In Clash Nyanpasu, open “Settings” → “Clash Core” to view the core type and version. With the mihomo core, check the beginning of the log to confirm the version actually loaded. The examples here use common mihomo syntax; older Clash branches may not recognize some load-balancing strategies or provider filters.

Open the “Profiles” page and find the currently enabled subscription profile.
Open the configuration editor and locate the top-level proxy-groups section.
Add the new proxy group under proxy-groups. Keep indentation consistent at every level and do not use tabs.
In rules, direct the domains, rule providers, or catch-all rule that need handling to the new group name.
Save and reload the configuration, then open “Logs” and check for YAML parsing errors or messages saying that a proxy node cannot be found.
Run a latency test once in the proxy-group view and confirm that node status and automatic selection match expectations.

Combining all three proxy-group types

Complex configurations do not have to use only one type. You can create regional url-test groups and then expose those groups for manual selection; you can also use fallback for critical services and load-balance for large download batches. Keep nested groups purposeful and avoid circular references.

proxy-groups:
  - name: "Hong Kong Low Latency"
    type: url-test
    proxies:
      - "Hong Kong 01"
      - "Hong Kong 02"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

  - name: "Japan Low Latency"
    type: url-test
    proxies:
      - "Japan 01"
      - "Japan 02"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

  - name: "Critical Services"
    type: fallback
    proxies:
      - "Hong Kong Low Latency"
      - "Japan Low Latency"
    url: "http://www.gstatic.com/generate_204"
    interval: 180

  - name: "Node Selection"
    type: select
    proxies:
      - "Hong Kong Low Latency"
      - "Japan Low Latency"
      - "Critical Services"
      - DIRECT

This structure first selects a low-latency node within each region, then runs “Critical Services” with Hong Kong preferred and Japan as the backup. The outer “Node Selection” group keeps a manual control point. If all Hong Kong nodes are unavailable, fallback turns to the Japan group; if only one Hong Kong node fails, the inner url-test first tries another Hong Kong node.

Common configuration errors and troubleshooting order

Group or node names do not match

YAML matches names as complete strings. “Hong Kong 01” and “Hong Kong01” are different names, and full-width versus half-width spaces can also break references. When the log shows a message such as proxy not found, copy the node’s original name instead of typing it again.

Indentation is valid, but the hierarchy is wrong

proxy-groups, proxy-providers, and rules are all top-level fields. Placing a proxy group inside a proxies node will prevent it from loading correctly even if the text looks neatly aligned. Two spaces before list items are common, but consistency within the same level is what matters.

Latency tests pass, but the actual website is still unreachable

Switch the strategy to Global or select a node manually first to separate routing issues from node issues. If the site works with a manual node but fails in rule mode, inspect rule order. Clash evaluates rules from top to bottom; an earlier DOMAIN, DOMAIN-SUFFIX, rule provider, or GEOIP entry may already have sent the request to another group.

Results differ between TUN mode and the system proxy

The system proxy only handles applications that follow the system proxy settings; TUN mode captures a broader range of traffic through a virtual network interface. After switching to TUN, terminal programs, games, or standalone updaters may start going through Clash, changing proxy-group load. During troubleshooting, record the current mode, DNS settings, and target process so an entry-point change is not mistaken for a group failure.

The configuration is overwritten after editing the subscription

Direct edits to a configuration generated from a remote subscription may be replaced by the original subscription content at the next update. Put long-term custom groups in the client’s supported override, merge, or script mechanism. Before making changes, copy the profile locally and verify that groups, rule references, and provider filters load correctly, then move the changes into a maintainable workflow.

The takeaway: choose by goal, not by name

For web browsing, search, and remote interaction, start with url-test and use a 50–150 ms tolerance to reduce flapping.
When the primary route must always come first and the backup should be used only after failure, choose fallback; node order is the business priority.
For tasks with many independent connections that should be spread across nodes, use load-balance; for login-sensitive sessions, prefer consistent hashing.
When a single connection is slow, do not expect load balancing to combine bandwidth. Check node capacity, protocol overhead, the local network, and rate limits on the destination server separately.
Whatever automatic group you use, verify the rule target, health-check URL, core compatibility, and node names after subscription updates.

Start with a simple group containing three nodes and a 300-second check interval. Observe latency, switch counts, and logs for a day, then tune gradually. Once you decide whether the priority is lowest latency, availability, or distributing concurrent connections, choosing among the three group types is usually straightforward.