Clash Meta url-test & Fallback: Lazy Mode, Tolerance, and Failover Setup Guide

Why manual picking does not scale

Airport panels expose dozens of similarly named exits. Humans pattern-match on city labels and forget that congestion, routing changes, and QUIC-heavy stacks move faster than the calendar. Manual selection is workable for a short test, but daily browsing rewards repeatable automation: measure, compare, lock in a winner until evidence says otherwise, and fail over when probes show breakage—not when mood strikes.

Policy groups sit between your rules section and the underlying proxies list. A rule can send YouTube to PROXY-US while that symbol resolves to a url-test group containing only US-tagged servers, or to a fallback group that prefers wireguard first and only then commodity shadowsocks. The core does not magically know your intent; you declare structure in YAML, then let periodic health checks and ordering enforce it.

If you are still stabilizing subscriptions and DNS, start with the Clash beginner guide and the DNS and fake-ip troubleshooting article. This page assumes packets reach nodes and you mainly need smarter group types, not a firewall rescue.

How url-test chooses the fastest member

A url-test group periodically performs health checks against a URL you specify—commonly a small HTTPS object on a major CDN—and records latency for each candidate proxy in the group. After a round completes, the core ranks members and selects one as active, typically the lowest delay unless tolerance says the race was close enough to keep the incumbent.

The measurement is not a full-speed download of your real workload; it is a lightweight probe that approximates reachability and RTT toward whatever host you pointed at. That is a feature: you want something stable, cache-friendly, and geographically honest for your exit, not your neighbor’s speedtest vanity URL that blocks datacenter ranges on Tuesdays.

Key fields you will edit

• url: HTTP(S) endpoint used for timing. Must answer reliably from every healthy exit; avoid endpoints that rate-limit or challenge bots.
• interval: Seconds between scheduled test rounds for non-lazy groups, or baseline cadence for background scheduling—keep it sane; sub-minute storms can look like DDoS to tiny endpoints.
• lazy: When true, delays broad parallel probing until the group is actually used, reducing idle chatter. Great on laptops; know that the first selection after idle may still need a quick measurement burst.
• tolerance: Milliseconds band within which the core may prefer the current node over a slightly faster alternative, curbing flip-flop when two exits sit ten milliseconds apart.

lazy and tolerance in real life

Lazy mode is the polite houseguest of policy groups. Without it, a crowded url-test bucket can spend CPU and upstream allowance proving that thirty shadowsocks profiles still answer a health check even while you are editing Markdown offline. With lazy: true, measurements focus on the moments you actually route traffic through the group, which keeps battery-powered machines quieter and airport dashboards less spicy.

The trade-off is predictability of warm-up. Right after you wake the machine or flip Wi-Fi, your first browser tab might arrive a hair earlier than the probe finishes reordering ranks. If that annoys you, either accept one slightly sluggish hop once in a while, shorten intervals modestly, or stage a dedicated fallback group with a always-warm premium node before bulk test winners.

Tolerance deserves more love than most profiles give it. Raw minimum-latency selection sounds optimal until CDN edges wobble five milliseconds every few seconds and your SOCKS hop changes upstream twice a minute, resetting keep-alives and annoying HTTP/2 sites. A tolerance of tens of milliseconds tells the core: “If the challenger is not materially better, stay put.” Raise it when you see log spam about switches; lower it when one exit is consistently superior and you are okay with quicker promotions.

How fallback chains priorities

A fallback group walks its proxies array in order. The core checks each candidate until it finds one that passes its health criteria, then uses that member until it fails—at which point it advances. This maps neatly to human intent: “Try my premium relay first, then the backup airport line, then direct,” without writing ten brittle per-app exceptions.

Unlike url-test, fallback is not trying to compute a winner among near-equals; it encodes preference. You might place a domestic low-latency hop first even if a farther node occasionally bests it by two milliseconds, because the first hop carries your subscription contract terms or fewer captchas. That distinction matters when someone shares a starter YAML where every group is blindly set to url-test even though business logic wanted strict ordering.

You can nest smartly: a fallback entry can point to another group symbol that is itself url-test, yielding “ordered macro-tiers, each tier internally optimized.” The opposite pattern—url-test whose members include fallback groups—is less common but valid when each macro node needs its own sub-chain.

Minimal YAML you can adapt

Replace names with your subscription’s proxy entries; keep group symbols consistent with what your rules reference.

# Illustrative proxy-groups — adjust proxy names and URLs to your provider
proxy-groups:
  - name: AUTO-BEST
    type: url-test
    proxies:
      - 🇸🇬 SG-01
      - 🇸🇬 SG-02
      - 🇯🇵 JP-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: RESILIENT
    type: fallback
    proxies:
      - 🇺🇸 US-PREMIUM
      - AUTO-BEST
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300

rules:
  - GEOIP,CN,DIRECT
  - MATCH,RESILIENT

Notice the split responsibilities: AUTO-BEST hunts the snappiest SG/JP test result, while RESILIENT honors premium first, only then borrows the test group, and finally steps down to DIRECT if everything collapses—useful on captive portals or partial airport outages.

Choosing a health-check URL responsibly

Community configs often reuse a handful of well-known endpoints. That is fine when the host tolerates volume, serves small bodies, and does not discriminate VPN egress aggressively. Avoid novelty endpoints that return huge pages, demand JavaScript, or rotate per-request—your core is not a browser.

When every millisecond matters semantically, experiment with alternate probes in a lab profile clone before pushing to production phones. Log lines that show alternating failures with HTTP 403 often mean the endpoint dislikes automated GETs from certain ASNs; swapping the URL beats rage-cycling nodes.

Goal	Probe mindset
General browsing balance	Small static asset on a neutral CDN; verify 204/200 behavior consistently.
Region-faithful exits	Probe toward hosts in the same rough geography your rules expect.
Fail fast on brownouts	Slightly shorter interval paired with sane tolerance, not absurd one-second polls.

Step-by-step setup

For automated merging of remote snippets—where group names collide—see the Clash Meta rule-providers path and interval article so local overrides remain on top.

Common pitfalls and how to read them

Everything toggles every few seconds. Raise tolerance, lengthen interval, or reduce the candidate pool to exits that are not racing at identical speeds through the same congested peering point.

“Fast” group feels slow for one site. The site may front a different continent than your probe, or QUIC may fall back differently. Add domain rules or a split DNS strategy; the group is doing its narrow job.

Fallback never reaches backups. Health criteria might still mark degraded nodes as “okay enough,” or a higher rule sends traffic elsewhere. Trace the actual rule hit and member health flags in the UI or API snapshot.

FAQ

First connection after idle feels laggy with lazy: true

Expected occasionally: measurement needs a moment. Mitigate with a staged fallback that includes a stable premium first hop, or accept lazy: false for desktops plugged into power.

Should the probe URL be HTTPS?

Usually yes for realism with TLS handshakes similar to browsing. Ensure certificate validation aligns with your stack; exotic MITM profiles belong in labs only.

Mihomo vs older Clash forks

Field names for groups stay broadly compatible across Meta-class cores, but always diff after large jumps—feature flags and default tolerances evolve. Validate in a throwaway profile first.

Checklist before you call it done

Keep the client transparent

Readable YAML beats opaque UI toggles: when something misbehaves at 11 p.m., you want logs, group semantics, and DNS to tell one coherent story. Clash Meta rewards profiles where tests, tolerances, and failover ladders align with how you actually use the internet—not how a benchmark said Thursday looked.

Download Clash for free and experience the difference