Why Your Subscription Is Not Enough

Importing a subscription gives you a flat list of outbounds—servers, relays, and maybe a few preset groups. That list alone does not decide how traffic moves. The moment a rule points to a name like Proxy or Auto, Clash resolves that name to a policy group: a small state machine that picks one child outbound for each connection according to its type. If that group is a plain selector, nothing measures latency unless you click manually. If you want automatic fastest-node selection, you need url-test. If you want primary with backup behavior, you need fallback. This guide is the missing bridge between “I have nodes” and “the client actually steers traffic the way I expect,” with concrete YAML you can paste and adapt.

We will stay focused on operational steps: which keys exist, what sensible defaults look like, how health checks interact with real browsing, and how DIRECT, REJECT, and nested groups cooperate inside rules:. For the broader story of rule order and providers, pair this walkthrough with our rule routing best practices article so you are not fighting “first match wins” while tuning groups.

Policy Group Types at a Glance

Think of each group as answering a different question. A selector asks, “Which single outbound did the user choose in the UI?” It is ideal for manual overrides. A url-test group asks, “Which outbound currently has the lowest latency to a probe URL?” It is the usual answer to “pick the fastest node automatically,” provided your probe URL is reachable and comparable across servers. A fallback group asks, “Which is the first healthy outbound in my ordered list?” It implements classic active–standby failover: try A, then B, then C, without ranking everyone by milliseconds. load-balance spreads sessions across members; it is not the same as latency-based picking, and it is easy to confuse with url-test when you only read the label “balance” in a third-party profile.

Advanced profiles often nest groups. For example, a top-level selector named Final might offer Rule, Global, and Direct, while Rule mode sends most domains to an inner url-test group that only contains datacenter nodes. Nesting is powerful but increases the number of names you must keep consistent between proxy-groups and rules:. When something “does nothing,” the first debug step is still spelling: a rule that references PROXY will never hit your group named Proxy.

ℹ Remember: Health checks consume small background requests. Aggressive intervals on huge node lists can annoy providers and skew latency if the probe endpoint rate-limits you. Start conservative, then tighten only when you understand the load.

Configure url-test Step by Step

A minimal url-test entry lists child proxies by name, points to a URL Clash can GET, and defines how often to repeat the measurement. Names in proxies: must match existing outbounds from your proxies: section or from providers that expanded into the running config. A common beginner mistake is referencing display labels from a GUI that differ from the YAML identifiers—export the running config from your client when in doubt.

The url field is the latency probe. Clash measures the time to complete an HTTP request through each candidate outbound. Good probes are short, cache-friendly, and geographically stable. Many templates use a major CDN or a vendor-specific /delay endpoint. Avoid probes that always 302 across continents, return huge bodies, or require a browser cookie, because you are measuring the probe—not your real website mix. If every node shows “timeout,” your probe might be blocked, TLS-intercepted, or simply wrong for that network path.

interval controls how often all members are retested. Values between thirty and three hundred seconds are typical on desktops. Mobile clients sometimes use longer intervals to save battery. tolerance (milliseconds) prevents flapping: if the current node is still within tolerance of the best newly measured node, Clash may prefer sticking with it instead of bouncing every cycle. Without tolerance, a one-millisecond jitter can trigger endless switches that hurt long-lived TLS sessions.

Depending on core version and GUI mapping, you may also see lazy (skip testing unused members), timeout overrides, and per-group expected-status or similar extensions in Meta-class builds. Those knobs matter when a provider only returns 204 on success or when you intentionally use a probe that answers 404 quickly. When documentation conflicts, trust the schema shipped with your exact kernel build over random snippets from older Gists.

Example: url-test group (illustrative names) 
proxy-groups:
  - name: Auto
    type: url-test
    proxies:
      - Node-A
      - Node-B
      - Node-C
    url: https://www.gstatic.com/generate_204
    interval: 60
    tolerance: 30

Configure fallback for Primary and Standby

fallback walks the proxies: array in order. It selects the first member that passes the health check, then sticks with it until that member fails—at which point it advances down the list. That behavior matches mental models like “use my dedicated line, and only if it is dead, fall back to the cheap pool.” Unlike url-test, fallback does not rank everyone by ping each cycle; ordering in YAML is the priority contract.

You still supply a url (and usually interval) so the core knows how to mark members up or down. If you omit sensible timeouts, a single blackholed node can stall the group longer than users tolerate. Some operators place a DIRECT member at the end of a fallback chain as emergency breakout. That is valid, but remember that DIRECT health checks still try to reach the probe without tunneling—use a probe that makes sense on the raw ISP path, not only through tunnels.

When combining fallback with region-specific blocks, keep legal and policy context in mind. Automatic failover is a reliability tool for networks you are authorized to use, not a way to bypass contractual restrictions. Document why ordering exists so future-you does not “sort alphabetically” and accidentally demote the production node.

Example: fallback chain 
proxy-groups:
  - name: Reliable
    type: fallback
    proxies:
      - Primary-IEPL
      - Secondary-Normal
      - Tertiary-Budget
    url: https://cp.cloudflare.com/generate_204
    interval: 30

Choosing a Latency Test URL That Reflects Reality

The probe URL should answer quickly with minimal payload. Static 204 endpoints are popular because they avoid downloading megabytes during every interval tick. Confirm the endpoint is reachable from each node location: a probe hosted only inside one country may look “fast” on local nodes and “dead” elsewhere, which mislabels good servers as offline. If you multihop through an upstream that rewrites DNS or SNI, validate probes both on clean broadband and on the exact LAN where the client runs.

HTTPS versus HTTP matters when middleboxes exist. Many modern templates prefer HTTPS probes to reduce tampering, but corporate SSL inspection can make every node look equally broken if certificates are not trusted uniformly. When troubleshooting, temporarily switch to a probe you can curl manually through the same outbound to see whether failure is group logic or plain transport.

Do not use a probe that is blocked by your own REJECT rules or hijacked by fake-ip edge cases. If the probe hostname resolves oddly in your DNS setup, Clash might measure DNS stalls instead of tunnel latency. Align dns settings with how rules send the probe—our FAQ on connectivity and DNS covers several resolver pitfalls that show up as “all proxies red.”

⚠ Provider etiquette: Pointing thousands of clients at a third-party micro-endpoint with one-second intervals can get your subnet flagged. Prefer documented vendor URLs or modest intervals, and avoid turning latency checks into accidental DDoS.

How DIRECT, REJECT, and Groups Interact in Rules

Rules return either a built-in policy (DIRECT, REJECT, REJECT-DROP, etc., depending on core) or a policy group name. Built-ins bypass your fancy url-test entirely—by design. If a domain rule sends tracking garbage to REJECT, no proxy latency is consulted. If LAN traffic uses DIRECT, Clash does not attempt to tunnel it through Auto. That separation is how you keep local printers, NAS devices, and captive portals working while still auto-picking nodes for everything else.

The usual pattern stacks specificity: put RFC1918 and DOMAIN-SUFFIX,local,DIRECT style coverage high in rules:, place ad or telemetry blocks on REJECT next, then route international services to a group that actually runs health checks, and end with MATCH to your cautious default. If MATCH points to a selector you never touch, you will feel like “auto fastest” failed—even when url-test works perfectly for rules that never reference it.

Nested groups interact with rules in one subtle way: the rule only names the outer group. Inner url-test selection still happens per flow, but policy overrides in the UI may target outer names. When debugging, trace from the connection log: which rule matched, which group name fired, and which concrete outbound won inside that group. Clients with live connection tables make this tracing much faster than reading YAML alone.

Minimal rules sketch showing DIRECT, REJECT, and a url-test group 
rules:
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - DOMAIN-KEYWORD,telemetry,REJECT
  - DOMAIN-SUFFIX,example.com,Auto
  - MATCH,Auto

load-balance Is Not “Pick the Fastest”

Readers searching for “load balancing” sometimes land on load-balance groups. Those spread connections across members using a strategy such as consistent hashing by destination or round-robin, depending on configuration and core support. That can improve aggregate throughput when each server has capacity limits, but it does not guarantee the lowest RTT for every session. If your intent is “always use the snappiest node,” stay with url-test and tune tolerance. If your intent is “shard heavy downloads,” evaluate load-balance deliberately and monitor error rates, because a bad member in the pool still receives a share of flows unless health checks mark it down.

Troubleshooting When Health Checks Lie

Symptom: every node shows red or “timeout.” Start outside Clash—can you ping or curl through one outbound with the same SNI and port your node uses? If plain TLS fails, Clash cannot magically fix upstream blocking. Next, simplify the probe to a vendor-recommended URL and lengthen interval to reduce concurrent pressure. Third, inspect whether system proxy or TUN loops are routing the health check back into Clash in a circle; circular routing produces absurd latencies and flaky marks.

Symptom: the UI shows a “best” node yet browsing is slow. Remember that HTTP probe RTT is not video bitrate, not UDP game latency, and not peak-hour bandwidth. Some servers optimize peering toward CDNs used in probes but deprioritize other prefixes. When that happens, split traffic: keep url-test for general web while using a dedicated selector for streaming or games, or maintain two url-test groups with different probes aligned to those use cases.

Symptom: constant switching every few seconds. Raise tolerance, lengthen interval, and enable lazy testing if supported. Also verify Wi-Fi power management is not introducing sleep-induced spikes that confuse measurements on laptops.

Symptom: fallback never leaves the first node even when it feels “down.” Your probe might still return 204 while application traffic fails due to UDP issues, wrong protocol, or server-side throttling that only hits long flows. Pair fallback with realistic user testing and consider splitting TCP-sensitive services to groups tuned for those paths—see our Steam, UDP, and TUN split routing guide for a concrete example of when latency probes and application needs diverge.

End-to-End Pattern You Can Adapt

The following skeleton ties together named nodes, a url-test auto group, a fallback reliability group, and simple rules. Replace names with your subscription’s identifiers, keep the YAML indentation strict, and reload the profile through your client’s validator so typos surface early.

Combined proxies, groups, and rules (template) 
proxies:
  - name: Node-A
    type: ss
    server: example-a.example.com
    port: 443
    cipher: aes-128-gcm
    password: "replace-me"
  - name: Node-B
    type: ss
    server: example-b.example.com
    port: 443
    cipher: aes-128-gcm
    password: "replace-me"

proxy-groups:
  - name: Auto
    type: url-test
    proxies:
      - Node-A
      - Node-B
    url: https://www.gstatic.com/generate_204
    interval: 60
    tolerance: 40
  - name: Stable
    type: fallback
    proxies:
      - Node-A
      - Node-B
      - DIRECT
    url: https://cp.cloudflare.com/generate_204
    interval: 45

rules:
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT
  - DOMAIN-SUFFIX,ads.example,REJECT
  - MATCH,Auto

After loading, open your client’s connection or log view and load a few sites. You should see the matched rule, the resolved group, and the chosen outbound updating over time as intervals elapse. If anything feels opaque, exporting the merged runtime config removes guesswork about provider expansions.

Putting It Together

Subscriptions give you ingredients; url-test and fallback groups are the recipes that turn a static list into behavior that matches user intent. Nail the probe URL, tame intervals and tolerance, keep DIRECT and REJECT rules where they belong, and verify that your MATCH line actually points at the automatic group—not a manual selector frozen on a random node. Compared with all-or-nothing VPN clients that hide outbound logic, Clash-family stacks reward this extra clarity with measurably smoother day-to-day browsing once the pieces line up.

Picking a maintained GUI matters because you will revisit these knobs whenever providers rotate endpoints. Our client selection overview highlights where each platform surfaces group editing, health-check visibility, and safe profile reload—details that separate a fiddly YAML lifestyle from a sustainable setup.

→ Download Clash for free and experience the difference once your policy groups reflect how you actually want traffic to fail over.