Clash Proxy Group Strategies: Selection, Load Balancing and Failover
Table of Contents
- What Is a Proxy Group?
- Select Strategy: Manual Choice
- URL-Test Strategy: Automatic Best Node Selection
- Fallback Strategy: Automatic Failover
- Load-Balance Strategy: Traffic Distribution
- Relay Strategy: Chained Proxies
- Nested Proxy Groups: Advanced Usage
- Practical Example: Building a Smart Selection Strategy
- Common Configuration Templates
Proxy groups are one of the most flexible yet often overlooked components in Clash configuration. Many users simply rely on the config provided by their proxy service without understanding how proxy groups actually work. In reality, proper proxy group configuration is key to improving network stability and speed.
This guide covers every proxy group strategy type in Clash, from basic concepts to advanced nested usage, helping you truly master proxy group configuration.
What Is a Proxy Group?
A proxy group is a core component in the Clash configuration file that defines a set of proxy servers and how traffic should be distributed among them.
Simply put, a proxy group answers this question: When you have multiple servers available, which one should handle the traffic?
In the Clash configuration file, proxy groups are defined under the proxy-groups field:
proxy-groups:
- name: "Proxy"
type: select
proxies:
- Hong Kong Node 1
- Hong Kong Node 2
- Japan Node
- US Node- name: The group name, referenced in routing rules
- type: The strategy type, determining how traffic is distributed among proxies
- proxies: List of proxy servers included, which can be specific nodes or other proxy groups
Clash supports 5 main proxy group types (plus relay), each with specific use cases. Understanding their differences is fundamental to optimizing your network configuration.
Select Strategy: Manual Choice
select is the simplest strategy type -- it gives the user full manual control over which node to use. This is what most proxy services use for their main "Proxy" group.
Basic Configuration
- name: "Proxy"
type: select
proxies:
- Hong Kong Node 1
- Hong Kong Node 2
- Japan Node
- US Node 1
- US Node 2Use Cases
- Main proxy group: manually switching nodes for daily use
- Streaming geo-unblocking: manually selecting region-specific nodes (e.g., US nodes for Disney+)
- Gaming: manually choosing the lowest-latency game server
In the client UI, select groups are typically displayed as a list. Click to switch nodes. Place your most frequently used nodes at the top of the list to minimize switching effort.
URL-Test Strategy: Automatic Best Node Selection
url-test is the most practical automated strategy -- it periodically tests all nodes and automatically selects the one with the lowest latency. This is the go-to choice for most advanced users.
Complete Configuration Parameters
- name: "Auto"
type: url-test
proxies:
- Hong Kong Node 1
- Hong Kong Node 2
- Japan Node
- Singapore Node
url: "http://www.gstatic.com/generate_204"
interval: 300
tolerance: 150Parameter Details
- url: The test target URL. Recommended:
http://www.gstatic.com/generate_204-- a lightweight endpoint that returns HTTP 204, providing the most accurate latency measurement - interval: Test interval in seconds. 300 means testing every 5 minutes. Too short wastes bandwidth; too long means slow reaction to node changes
- tolerance: Tolerance threshold in milliseconds. The strategy only switches when the difference between the current best node and a new node exceeds this value, preventing frequent switching between similar nodes
Do not set interval below 60 seconds. Frequent test requests consume node bandwidth and can actually degrade performance. The recommended value is 300 seconds (5 minutes), which balances responsiveness with efficiency.
The Lazy Parameter
lazy (default: true) controls whether inactive proxies are skipped during testing. If some nodes are rarely accessed, enabling lazy mode avoids unnecessary test overhead:
- name: "Auto"
type: url-test
proxies:
- Hong Kong Node 1
- Hong Kong Node 2
- Japan Node
url: "http://www.gstatic.com/generate_204"
interval: 300
tolerance: 150
lazy: trueFallback Strategy: Automatic Failover
fallback implements a primary-backup switching logic -- it tests nodes in list order and uses the first available one.
Basic Configuration
- name: "Fallback"
type: fallback
proxies:
- Hong Kong Node 1
- Hong Kong Node 2
- Japan Node
- US Node
url: "http://www.gstatic.com/generate_204"
interval: 300How It Works
The fallback group performs health checks in order:
- First, test if "Hong Kong Node 1" is available
- If available, use it directly without testing subsequent nodes
- If unavailable, test "Hong Kong Node 2"
- Continue until an available node is found
- If all nodes are unavailable, use the first node in the list (even if unreachable)
Key Difference from url-test
- url-test: Selects the node with the lowest latency (optimizes for speed)
- fallback: Selects the first available node in the list (optimizes for priority)
If you want to prioritize Hong Kong nodes and only switch to Japan when Hong Kong is down, use fallback. If you want whichever node is faster between Hong Kong and Japan, use url-test.
Typical Use Cases
- Multi-line backup: automatically switch to backup when primary line fails
- Cost optimization: prefer budget nodes, only switching to premium when budget nodes are down
- Cross-region disaster recovery: automatically switch to remote nodes when local nodes fail
Load-Balance Strategy: Traffic Distribution
load-balance distributes traffic across multiple nodes, ideal for scenarios requiring high bandwidth or multi-user sharing.
Basic Configuration
- name: "LoadBalance"
type: load-balance
proxies:
- Hong Kong Node 1
- Hong Kong Node 2
- Hong Kong Node 3
- Japan Node 1
url: "http://www.gstatic.com/generate_204"
interval: 300
strategy: consistent-hashingLoad Balancing Algorithms
Clash supports two load balancing algorithms:
All requests to the same target domain (e.g., google.com) always go through the same node. Benefits include:
- Stable connections without frequent node switching
- Efficient use of persistent TCP connections
- Avoids cookie loss or session interruption caused by node switching
Recommended: This is the best choice for most scenarios.
Requests are distributed sequentially across nodes -- the 1st request goes to node 1, the 2nd to node 2, and so on.
Characteristics:
- Most even traffic distribution
- May split requests for the same domain across different nodes
- Can affect services that rely on persistent connections
Use case: When multiple users share the same proxy configuration, each user's traffic can be distributed to different nodes.
The load-balance strategy may not work well with some proxy services. Certain providers impose per-node rate limits or connection limits, and distributing across nodes might trigger risk controls. Test thoroughly before relying on it in production.
Relay Strategy: Chained Proxies
relay is the most specialized strategy type -- it routes traffic sequentially through multiple proxy nodes, forming a proxy chain. This is the only way to achieve "multi-hop proxying" in Clash.
Basic Configuration
- name: "Relay"
type: relay
proxies:
- Japan Node (entry point)
- Singapore Node (middle hop)
- US Node (exit point)How It Works
The data path is: Your device -> Japan Node -> Singapore Node -> US Node -> Target website
To the target website, the request appears to come from the US node's IP. However, both Japan and Singapore nodes can see your original encrypted traffic.
Use Cases
- Source obfuscation: Obscure the relationship between real entry and exit IPs through multi-hop routing
- Special restrictions bypass: Scenarios requiring traffic to pass through a specific region before exiting from another
- Network penetration: Connect to an accessible entry node first, then reach the target network through intermediate nodes
Chained proxies significantly increase latency. Each additional hop adds approximately 20-100ms of delay. Chains with 3+ hops are generally unsuitable for everyday browsing and only make sense for extremely privacy-sensitive scenarios. Additionally, relay groups don't support url and interval parameters, as their health check mechanism differs from other strategies.
Relay Limitations
- Cannot use automated parameters like
url-test - Cannot nest other relay groups
- Each entry must be a specific proxy server, not another group
- Clash Meta kernel no longer supports relay (use
chainas an alternative)
Nested Proxy Groups: Advanced Usage
A proxy group's proxies list can contain not just specific nodes but also other proxy groups. This is nested proxy groups -- the core mechanism for implementing complex routing logic.
Nested Structure Example
proxy-groups:
# Bottom layer: regional groups
- name: "Hong Kong Group"
type: url-test
proxies:
- HK-01
- HK-02
- HK-03
url: "http://www.gstatic.com/generate_204"
interval: 300
- name: "Japan Group"
type: url-test
proxies:
- JP-01
- JP-02
url: "http://www.gstatic.com/generate_204"
interval: 300
- name: "US Group"
type: url-test
proxies:
- US-01
- US-02
- US-03
url: "http://www.gstatic.com/generate_204"
interval: 300
# Middle layer: regional priority
- name: "Asia-Pacific Auto"
type: fallback
proxies:
- Hong Kong Group
- Japan Group
url: "http://www.gstatic.com/generate_204"
interval: 300
# Top layer: final selection
- name: "Proxy"
type: select
proxies:
- Asia-Pacific Auto
- US Group
- Hong Kong Group
- Japan GroupHow Nesting Works
In the example above:
- "Proxy" group provides the final manual selection
- By default, it selects "Asia-Pacific Auto", which prioritizes Hong Kong Group (because fallback follows list order)
- If all Hong Kong nodes are unavailable, it automatically switches to Japan Group
- The user can also manually switch to "US Group" or any specific regional group
Keep proxy group nesting depth to no more than 3 levels. Excessive nesting increases configuration complexity and makes debugging difficult. It can also affect Clash's parsing performance.
Practical Example: Building a Smart Selection Strategy
Here is a complete production-ready configuration implementing "smart selection with manual fallback":
Design Goals
- Group nodes by region, with auto-selection within each group
- Set regional priority, favoring low-latency regions
- Preserve manual selection capability as fallback
- Provide dedicated groups for specific apps (streaming, gaming)
Complete Configuration
proxy-groups:
# ===== Main Strategy Group =====
- name: "Proxy"
type: select
proxies:
- Auto Best
- HK Auto
- JP Auto
- SG Auto
- US Auto
- DIRECT
# ===== Auto Selection Layer =====
- name: "Auto Best"
type: fallback
proxies:
- HK Auto
- JP Auto
- SG Auto
url: "http://www.gstatic.com/generate_204"
interval: 300
# ===== Regional Auto Layer =====
- name: "HK Auto"
type: url-test
proxies:
- HK-01
- HK-02
- HK-03
url: "http://www.gstatic.com/generate_204"
interval: 300
tolerance: 100
- name: "JP Auto"
type: url-test
proxies:
- JP-01
- JP-02
url: "http://www.gstatic.com/generate_204"
interval: 300
tolerance: 100
- name: "SG Auto"
type: url-test
proxies:
- SG-01
- SG-02
url: "http://www.gstatic.com/generate_204"
interval: 300
tolerance: 100
- name: "US Auto"
type: url-test
proxies:
- US-01
- US-02
- US-03
url: "http://www.gstatic.com/generate_204"
interval: 300
tolerance: 150
# ===== Streaming Specific =====
- name: "Disney+"
type: select
proxies:
- US Auto
- US-01
- US-02
- name: "Netflix"
type: select
proxies:
- HK Auto
- JP Auto
- US Auto
# ===== Gaming Specific =====
- name: "Game"
type: url-test
proxies:
- HK-01
- HK-02
- JP-01
url: "http://www.gstatic.com/generate_204"
interval: 120
tolerance: 50Configuration Breakdown
- Proxy defaults to "Auto Best", which prioritizes HK Auto via fallback -- if all HK nodes fail, it switches to JP Auto, then SG Auto
- Users can manually switch to "US Auto" or any regional group
- Disney+ rules force US nodes
- Netflix defaults to HK (richer content library), with manual override option
- Game group uses 120s interval (more frequent testing) and 50ms tolerance (more sensitive switching) to ensure lowest latency
Common Configuration Templates
Template 1: Simple Auto-Switch
For users who prefer fully automated operation:
proxy-groups:
- name: "Proxy"
type: url-test
proxies:
- Node 1
- Node 2
- Node 3
url: "http://www.gstatic.com/generate_204"
interval: 300
tolerance: 150Template 2: Primary-Backup Dual Line
For users with clear primary and backup lines:
proxy-groups:
- name: "Proxy"
type: fallback
proxies:
- Primary Group
- Backup Group
url: "http://www.gstatic.com/generate_204"
interval: 300
- name: "Primary Group"
type: url-test
proxies:
- HK-01
- HK-02
url: "http://www.gstatic.com/generate_204"
interval: 300
- name: "Backup Group"
type: url-test
proxies:
- JP-01
- SG-01
url: "http://www.gstatic.com/generate_204"
interval: 300Template 3: Multi-Region Smart Selection
For advanced users with nodes across multiple regions:
proxy-groups:
- name: "Proxy"
type: select
proxies:
- Smart Auto
- HK Auto
- JP Auto
- SG Auto
- TW Auto
- US Auto
- DIRECT
- name: "Smart Auto"
type: url-test
proxies:
- HK Auto
- JP Auto
- SG Auto
- TW Auto
url: "http://www.gstatic.com/generate_204"
interval: 300
tolerance: 80
- name: "HK Auto"
type: url-test
proxies: [HK-01, HK-02, HK-03]
url: "http://www.gstatic.com/generate_204"
interval: 300
- name: "JP Auto"
type: url-test
proxies: [JP-01, JP-02]
url: "http://www.gstatic.com/generate_204"
interval: 300
- name: "SG Auto"
type: url-test
proxies: [SG-01, SG-02]
url: "http://www.gstatic.com/generate_204"
interval: 300
- name: "TW Auto"
type: url-test
proxies: [TW-01, TW-02]
url: "http://www.gstatic.com/generate_204"
interval: 300
- name: "US Auto"
type: url-test
proxies: [US-01, US-02, US-03]
url: "http://www.gstatic.com/generate_204"
interval: 300Replace the proxy names in these templates with your actual node names. Combine with Rule Provider for fine-grained traffic management across different strategy groups.