Load Balancing & Failover: Building Rock-Solid Proxy Groups

Proxy Groups and Strategies: An Overview

Clash's proxy-groups determines how traffic is distributed across multiple nodes or sub-groups. After a rule matches, it points to a proxy group (such as PROXY, Auto Select, or Failover), and the group's internal strategy decides which node is ultimately used.

In addition to the manual select type, there are three automated strategies that can significantly improve stability and experience:

• url-test: Runs periodic speed tests and automatically selects the lowest-latency node.
• fallback: Uses nodes in order; automatically switches to the next one when the current node fails.
• load-balance: Distributes connections across multiple nodes to spread the load.

By combining these strategies intelligently, you can say goodbye to the common frustrations of "manually switching nodes" and "single-point failure disconnections," achieving a proxy setup that is both fast and reliable for everyday use.

select: Manual Selection

select is the most basic proxy group type: the user picks a node manually in the client or dashboard. It is ideal for "I know which server is best right now" scenarios, or as a complement to automatic strategies – for example, running an "Auto Select" (url-test) group alongside a "Manual" (select) group so you can normally use the automatic selection but intervene manually whenever needed.

Proxy subscription services typically provide select groups like "Node Selection," "Hong Kong," or "Japan," making it easy to switch by region or purpose.

url-test: Automatic Best-Node Selection

url-test periodically sends an HTTP request to every node in the group (using a lightweight speed-test URL such as http://www.gstatic.com/generate_204), selects the node with the lowest latency, and switches to it automatically. Perfect for users who always want the fastest node without doing manual speed tests.

Key parameter explanations:

• interval: Speed test interval in seconds (default 300). Avoid setting it too short to prevent excessive switching.
• tolerance: Tolerance in milliseconds. A new node must be faster than the current one by more than this value to trigger a switch – this reduces jitter from minor fluctuations.
• lazy: Lazy mode; speed tests are only triggered when there is actual traffic, conserving resources.

fallback: Failover

fallback uses nodes in the order listed in proxies, switching to the next node only when the current one fails a speed test or becomes unreachable. It is ideal for "I have a preferred primary node, and I only want backups if it goes down" – for example: primary Hong Kong, backup Japan, backup US.

The difference from url-test: fallback never proactively switches to a faster node – it only switches when the current node becomes unavailable. This makes it more stable with fewer interruptions, which is ideal for users sensitive to latency spikes who prefer to stay on one server – for example, when watching live streams or maintaining a remote desktop session.

load-balance: Load Balancing

load-balance distributes different connections across multiple nodes in the group, relieving pressure on any single node and improving overall throughput. Available strategies:

• round-robin: Uses each node in turn.
• consistent-hashing: Routes traffic to the same node based on the destination (domain + port). Better for sites that require session persistence (such as staying logged in).

Load balancing is most beneficial in high-concurrency multi-node scenarios. For most individual users, url-test or fallback is sufficient for daily use. If your subscription has a large number of nodes, consider creating separate url-test groups for different regions and then doing a second-level best-selection across those groups to fully leverage the advantage of multiple nodes. Good proxy group architecture is key to getting the best out of Clash, and it is an essential skill for going from beginner to power user.

Nested Proxy Groups

The proxies list in a proxy group can contain not only node names but also the names of other proxy groups, enabling nesting. For example:

This first selects the best node within each regional group, then selects the best regional group – a clean and easy-to-maintain structure. Avoid nesting too deeply; two to three levels is sufficient for almost all use cases. Deeper nesting increases speed-test overhead and makes the configuration harder to reason about.

Parameter Tuning and Troubleshooting

If automatic switching is too frequent, increase tolerance or interval. If nodes are frequently and incorrectly flagged as down, check whether the speed-test URL is reachable from those nodes. If you want a node pinned, use select or fallback and put the desired node first. The recommended speed-test URL is a lightweight generate_204 endpoint – it responds quickly and generates minimal traffic, avoiding extra load on nodes.

The Proxies page in the Clash dashboard shows each group's currently selected node and its latency in real time, which is very helpful for debugging. If you are using a proxy subscription, some subscriptions already include optimized proxy group structures that you can use directly; when writing your own configuration, use the examples in this article as a starting point and adjust incrementally.

Typical Use Cases

Daily browsing: Point the PROXY rule to a url-test "Auto Select" group for a good balance of speed and convenience. When you need to fix a specific node, switch temporarily to a select group in the client. Most proxy subscription services already include a structure like this out of the box.

Live streaming / video calls: These demand low latency and stability. Use fallback with a low-latency node first in the list, or use select to pin the best-tested server – avoiding the brief disruption that can occur when url-test auto-switches nodes.

Large file downloads: Consider load-balance to spread the load across multiple nodes, or use select to pick a high-bandwidth dedicated server. Note that some proxy subscription services impose per-connection speed limits; load balancing may not break through a single-link bandwidth cap. For any scenario, monitor actual performance in the Clash dashboard for a while before adjusting interval, tolerance, or other parameters – avoid over-optimization that introduces instability.

Summary

url-test, fallback, and load-balance each have their strengths: use url-test when you want maximum speed, fallback when you need maximum stability, and load-balance when you want to distribute load. Fine-tune with tolerance, interval, and lazy parameters; add select for manual override capability; and use nested proxy groups to build a proxy setup that is fast, stable, and resilient. The recommended starting point is a dual-group setup – "Auto Select" paired with a manual select group – and then optimize based on real-world experience. Proxy group configuration is one of the core advanced skills in Clash; once you have mastered it, you can quickly build effective connection strategies regardless of whether you switch subscription providers or run your own servers. A small investment in understanding the differences between strategies pays off in the long run with far less time spent manually switching nodes and a much smoother browsing experience.