Who This Article Is For

How to configure fallback groups in Clash Verge Rev—with honest health URLs and sane timeouts—is one of the fastest ways to stop treating ordered failover like a mystery latency contest. You run Clash Verge Rev on Windows with the embedded mihomo core, imports land fine, and routing basically works—yet the words fallback and url-test still blur together in subscription YAML. You want one reliable policy group that behaves like classic failover: a primary node, then backups that activate only when the active path actually fails checks—not one that hopscotches whenever two cities tie on a millisecond leaderboard. This page is scoped tightly to proxy-groups whose type is fallback, with practical notes on health-check URL, interval, per-probe timeout in milliseconds, lazy probing, optional expected-status, and how that differs from the latency-ranked automation covered in the dedicated url-test tuning article. Conceptual rule plumbing stays in the rules deep dive; everyday Verge Rev panes and logs appear in the Windows usage guide.

If you have never opened the profile editor after install, walk through the Windows 11 first-run guide first so reload, backup, and Patch workflows feel familiar. Expect to think in YAML even when the GUI applies a Patch layer for you—names must match exactly, indentation must stay honest, and subscription refreshes will cheerfully revert naive hand-edits if you forget the merge discipline.

What Makes fallback Different from url-test

Both group kinds can share the same machinery for asking “is this child alive?”: a probe url, a time cadence, and a client-side wait budget. The decision diverges. A fallback group honors the explicit proxies list order. The core tries to stick with the first member that passes health checks. When that active member times out or otherwise fails the probe policy, the engine walks forward and selects the next healthy outbound in the array. It is not trying to discover the “fastest” sibling on every tick; it is enforcing priority with automatic escape hatches. By contrast, url-test ranks candidates by measured latency to the probe and may jump whenever another node wins by enough margin—tolerance there is the hysteresis brake on those competitive jumps, which is why tolerance stars in the companion url-test article rather than here.

That distinction drives real symptoms. Misconfigured url-test feels like nervous channel flipping; misconfigured fallback often feels like stubbornness—staying on a dead primary too long—or, if your probe is cruelly strict, prematurely tumbling down the backup chain whenever café Wi-Fi hiccups. Fixing the former leans on tolerance and interval damping; fixing the latter leans on realistic timeout budgets, a truthful health URL, and sane ordering so backups are genuinely reachable when promoted.

Hybrid designs are normal: a fallback group might list several concrete nodes, or it might nest another policy group as a child—say a regional select you pin manually—so long as the YAML names line up. Keep the mental model crisp: fallback chooses positionally among children that look alive to the probe, while url-test chooses competitively among children by probe timing. If you need both behaviors, use two groups and point rules deliberately rather than hoping one magical group will read your mind.

Inventory Your Profile: Find Every fallback Group

Open the effective configuration Verge Rev feeds the core after merges—not merely the raw subscription download if providers rewrite names. Scan proxy-groups for type: fallback. For each, record four facts: the canonical YAML name, the ordered proxies list, every rules entry that references the group directly, and any parent select or nested group that embeds it. Renamed remotes and duplicated labels from sloppy merges produce “I clicked Auto but nothing moved” support threads because the UI bound to a different identifier than the rule stack expects.

Pay attention to use: versus explicit proxies:. Provider inclusions expand behind the scenes; a fallback group health-check examines the members you listed concretely in proxies per upstream documentation—surprises here often explain why some imported nodes never participate. If your vendor ships ready-made fallback chains, translate their marketing labels to YAML names before patching. A sticky note with mappings—UI label, YAML name, rule destinations—saves hours the next time a subscription rotation shuffles titles but preserves structure.

While inventorying, glance at sibling url-test autos you still depend on. If a rule points to the wrong automatic group, you might blame fallback semantics when url-test tolerance was the true oscillation source. Separating concerns cleanly—fallback for “home circuit then travel circuit,” url-test for “any of these three datacenters”—makes later debugging reproducible instead of atmospheric.

ordering: The Real failover Policy

Before touching numeric knobs, justify the order itself. Place your preferred outbound first: the dedicated IPLC port you trust, the fixed residential hop, or the closest geography. Follow with deterministic backups that should absorb load when the primary blackholes, handshakes stall, or your provider’s control plane marks the node sick. Avoid alphabetical accidents from generator scripts; treat order as product policy, not cosmetic sorting. If two entries are symmetric in role, duplication does not help—collapse them or separate into distinct groups with clearer intent.

Consider operational scenarios. Travel mode might want a different ordering than desk mode; maintaining two profiles with distinct fallback stacks often beats one giant compromise list whose middle nodes never make sense in either context. When children themselves are select groups, remember fallback only advances after the active child fails probes as seen from the parent; user pinning inside the child can mask upstream death until traffic actually flows and checks fail loudly.

Document expected failover time informally: with interval in seconds between scheduled rounds and timeout milliseconds per attempt, rough worst-case sensibilities emerge. Precise numbers depend on internal scheduler details, but the point remains—ordering without honest timing can strand users on primaries that are “technically alive” per an overly forgiving URL yet unusable for real pages.

Health-Check URL and expected-status

The url field defines what “healthy” means for every child in this group. Pick something small, widely reachable over HTTPS, and consistent with how you evaluate connectivity in daily browsing. Vendor defaults often favor vendor-hosted endpoints; that can be fine until captive portals, geographic bias, or resolver oddities under fake-ip mode make probes lie. If every node suddenly fails together, suspect the probe before suspecting the entire subscription—especially on guest Wi-Fi where splash pages answer HTTP oddly.

Optional expected-status narrows success: when set, only matching HTTP status codes count as healthy. Classic synthetic 204 endpoints pair naturally with 204 or patterns documented in mihomo syntax; wildcards exist, but mis-specified ranges turn good nodes into apparent corpses. Align this with TLS capabilities of every child transport; exotic ciphers or MITM appliances on corporate LANs may break handshakes before status codes even arrive, which logs reveal faster than UI guesswork.

Because fallback does not chase the lowest latency, a slightly slower but universally reachable probe generally beats an aggressive URL that amplifies geographic noise. If you also run demanding DNS setups, cross-check against your dns stanza so probe host resolution behaves identically for health checks and the apps you care about. For Windows mode differences—system proxy versus TUN capture—revisit the modes guide when probes succeed in one mode and flap in another.

interval: Seconds Between Probe Rounds

interval controls how often scheduled health checks rerun for members of this policy group when periodic testing is enabled (non-zero). Shorter intervals detect dead primaries sooner but increase background traffic and wake-ups—noticeable on laptops on battery. Longer intervals calm the network but may leave you on a failed hop until the next sweep completes. Fallback workloads are less jitter-prone than url-test leaderboards, yet interval still shapes how quickly you descend the backup chain after an outage begins.

A practical desk workflow is to start near vendor defaults, then lengthen interval if logs show needless probe storms during idle hours, or shorten modestly if you genuinely need snappier promotion during unreliable uplinks. Pair interval thinking with lazy: a long interval plus lazy true means the group might discover staleness only after traffic returns—good for intermittent usage, questionable for always-on monitoring unless you disable lazy or accept the trade-off consciously.

When merging multiple YAML sources, verify you did not accidentally duplicate interval keys with conflicting values. The effective runtime view should show a single coherent policy; surprises after subscription refresh usually mean a stale Patch target name or a shadowed merge fragment you forgot.

timeout: Millisecond Budget per Health Check

timeout sets how long each individual probe attempt may wait before the core treats it as failure for health purposes. This is the parameter users most often conflate with tolerance on url-test groups. Here the units matter critically: timeout is milliseconds, not seconds. Too tight, and transient Wi-Fi blips or TLS slowpaths knock a perfectly good primary offline, triggering premature failover down your ordered list. Too loose, and real outages linger while the client waits politely on a dead socket.

Windows environments add variance: resume-from-sleep NIC delays, VPN handoffs, and adapter resets can all stretch probe latency independent of remote server quality. Travel profiles often deserve slightly more generous timeouts than wired Ethernet baselines, not because the protocol changed, but because the last-mile noise floor did. Capture short connection log excerpts when tuning; subjective “it feels flaky” reports rarely convince you, but timestamped probe failures aligned with radio events do.

If promotion feels sluggish, profile whether the delay is timeout-dominated or interval-dominated before twiddling both. Changing two timing axes at once produces unmaintainable anecdotes weeks later when you forget which knob fixed which symptom. Consider documenting baseline triples—URL, interval, timeout—for each profile variant you actually run, not an aspirational union of every trip you might someday take.

lazy: Idle Quiet versus Warm readiness

lazy defaults to true in many templates bundled with community subscriptions. In that posture, if the policy group is not currently selected for traffic, periodic health chatter may defer—useful to silence idle probes on machines that spend hours off the tunnel. When you do select the group, probing catches up so failover can still operate, but the exact interplay between lazy, interval, and your manual clicks depends on scheduler details—empirical log observation beats armchair certainty.

Set lazy: false when you want health information warm before traffic arrives—think unattended servers, monitoring-heavy stacks, or nested selectors that might land on this fallback without you watching the dashboard. The cost is background polling even when you are not using the path. Neither setting replaces a bad url; they only modulate when questions get asked.

Laptops roaming between corporate SSIDs illustrate the trade-off: lazy true saves battery during domestic direct browsing yet might defer discovering a dead primary until you flip a rule-heavy tab; lazy false keeps scores fresh at the price of Wi-Fi beacon churn waking radios. There is no universal winner—pick per profile and accept that copying a stranger’s YAML wholesale ignores your power and mobility constraints.

tolerance: Pair With url-test, Not the Main fallback Lever

Readers arrive from mixed tutorials mentioning tolerance alongside every automatic group. On url-test, tolerance is the hysteresis margin that stops millisecond tie-breakers from thrashing winners. On pure fallback, selection among healthy children is not a latency race down the whole list; the core is not promoting node three just because node three pinged five milliseconds better while node one remains healthy per probe rules. Your primary tuning axes here remain order, timeout, interval, and probe correctness. If you need tolerance semantics explained end-to-end with worked examples, treat the url-test guide as the canonical companion rather than duplicating its tables here.

Nested designs blur lines: a fallback parent might contain a url-test child, so tolerance still matters—just inside the child group where competitive ranking happens. Debug those layers separately: confirm the child auto behaves, then confirm the parent order promotes when the entire child group fails upstream expectations. Mixing concerns in one mental model guarantees fruitless Reddit threads.

max-failed-times and Transient Blips

General mihomo group fields include max-failed-times, bounding how many consecutive failures escalate into forcing a health re-evaluation pattern distinct from everyday gentle probing—consult current upstream docs for exact semantics as releases evolve. Practically, users employ it to buffer brief transport glitches without instantly demoting a primary that has been otherwise solid for weeks. Combine thoughtfully with timeout: two harsh knobs stack into sudden ladder falls, while lenient stacks let wounded primaries linger.

When logs show oscillation that does not match theory, export a minimal reproducer profile redacting secrets and diff behavior across builds. Fallback logic rarely changes dramatically between minor versions, but health-check plumbing occasionally tightens defaults—your “golden YAML” from last year is a hypothesis, not a law.

YAML Shape Under proxy-groups

A minimal illustrative skeleton—not copy-paste gospel—shows how fields sit together conceptually:

proxy-groups:
  - name: "FAILOVER-PRIMARY-FIRST"
    type: fallback
    proxies:
      - Preferred-Node
      - Backup-A
      - Backup-B
    url: "https://www.gstatic.com/generate_204"
    expected-status: 204
    interval: 90
    timeout: 5000
    lazy: true
    max-failed-times: 5

Real files add filters, Unicode names, provider includes, and merge overlays—validate indentation after every edit. When unsure, compare merged runtime output before and after a single change; YAML mistakes produce spectacularly terse unmarshal errors that waste evening plans. If unmarshalling explodes mysteriously, cross-check patterns in the YAML recovery notes before blaming fallback itself.

When multiple fallback groups exist—perhaps per region—tune independently. A timeout comfortable for trans-Pacific circuits might be nonsense for a three-node domestic list. Symmetry across unrelated pools is a subscription author’s convenience, not your operational requirement.

Applying Changes in Clash Verge Rev: Patch versus Raw YAML

Provider refreshes love to erase hand-touched downloads. Clash Verge Rev supports merge Patch layers—small YAML fragments reapplied after each import so your fallback timing survives vendor churn. Ideal patches touch only the known name blocks you control, leaving the rest of the upstream template pristine. The failure mode is silent: rename a group server-side and your patch floats harmlessly until you notice defaults returned—hence the inventory habit advocated earlier.

Raw edits remain fine for fully user-authored profiles checked into Git. You see the whole document, you review diffs like an adult, and you accept manual merges when upstream scaffolds change. Avoid maintaining duplicate truths—one forgotten Patch plus one edited file both mutating the same group invites contradictory intervals and imaginary debugging sessions. Pick a single source of truth per profile and enforce it with boring discipline.

After any merge, reload the core, open the effective config view your build provides, and confirm numbers match intent. Then run real traffic—not only synthetic dashboard buttons—while watching connection logs for promotions that follow your declared order when you block the primary artificially. Thought experiments rarely reproduce Wi-Fi weirdness; five minutes of honest browsing does.

Windows Realities: Sleep, Wi-Fi, and Adapter Flaps

Notebooks suspend, radios roam, and TUN adapters occasionally need help after resume. Each event perturbs probe timing in ways remote server status pages will never mention. That is why corporate road warriors and home desk users rarely share identical fallback recipes even on identical subscriptions—transport noise dominates. When problems hit only after sleep, suspect local timing stacks before rewriting provider order dramatically.

Transparent HTTP proxies on some enterprise WLANs may answer generic probe hosts differently than the domains your browser visits for real work. If only automated health fails while manual HTTPS succeeds, logs comparing probe SNI and certificate paths point to remediation: relocate the URL, relax timeout modestly, or accept that automation will never be truthful on that SSID and pin manual selectors during office hours.

System proxy versus TUN changes which flows participate in complex DNS stories; after switching capture modes revalidate fallback timing because split routes you forgot about rearrange which child can complete TLS to the probe. Consistency beats optimism—retest instead of assuming yesterday’s timeout still fits today’s mode.

Verification Loop: Promote in Order, Without Mystery

After tuning, validate behavior with deliberate cruelty: block the primary’s egress briefly using an external firewall rule or provider-side disable if available, then watch logs as the group selects the next healthy child. Restore primary availability and confirm the stack eventually preferentially returns upward consistent with documentation—some designs prioritize stability of the active child, others re-evaluate top-of-list aggressively; know your core version’s narrative rather than assuming nostalgia from an old fork.

Avoid judging health purely from rainbow latency badges when your actual workload rides different AS paths. Load a long video, sync a large artifact, or hold a voice call while noting whether promotions align with genuine pain. Fallback should feel measured—occasional orderly steps—not rhythmic dance like an over-caffeinated url-test.

When anomalies persist, change one variable per experiment: timeout alone, then interval alone, then URL, documenting each outcome. Multivariate tweaks produce folk religion, not reproducible engineering. If local infrastructure is rotting independently of Clash, no probe saintliness rescues TCP stalls—verify plain network health before filing proxy drama tickets.

Frequently Asked Questions

Will fallback always pick the fastest node? No. It picks the first healthy node in list order, not the lowest-latency peer globally. Fastest-node behavior belongs to well-tuned url-test.

Is a lower timeout always safer? No. Too low yields false failures; grow it when jitter misreports healthy primaries as dead.

Can I nest url-test inside fallback? Often yes at the YAML graph level—ensure names resolve and debug child oscillation separately from parent promotion rules.

Does lazy prevent failover? It changes when idle probing runs, not whether eventual checks can demote a bad hop once traffic engages the group—validate with logs rather than intuition.

Should beginners avoid fallback? Beginners can use it if ordering is intentional; chaos arrives from imported templates you never audited, not from the group type itself.

Closing Thoughts

Configuring fallback under proxy-groups is how you tell mihomo the story executives articulate—“primary circuit first, backups only on real failure”—without babysitting buttons all day. Clash Verge Rev on Windows exposes that contract transparently, whether you merge a Patch after each subscription refresh or curate a fully owned file. Many commercial VPN clients hide failover ordering inside opaque server logic: convenient until the day you need to prove whether slowdowns live in the café portal or the tunnel. Subscription dashboards that bundle glossy maps but lock probe parameters often produce the same user helplessness with prettier icons. Even well-known closed proxy front-ends sometimes sand down advanced policy knobs unless you pay for “pro” feature tiers, which is a strange tax on defining your own backup chain. The Clash ecosystem trades glossy obfuscation for inspectable YAML: once health-check URL, interval, millisecond timeout, and lazy line up with how your network actually fails, fallback groups stop feeling mystical—and you still keep ordered resilience without confusing them for latency-ranked url-test. Maintained clients from official distribution channels preserve that clarity better than one-click repacks of unknown lineage.

If this was your first time separating fallback from url-test mentally, stack a bookmark to both guides and add a one-line comment in your Patch explaining why the primary sits first—future you, refreshed subscription in hand, will read that sentence and say thank you.

→ Download Clash for free and enjoy a seamless browsing experience