Clash All Nodes Red? Fix Lag Tests: UDP, DNS, STUN, and Health Check Steps

What “All Nodes Red” Actually Measures in Depth

In most of of of Mihomo-based Clash GUIs, the color beside a server is driven by a lag or delay test, not by a full quality audit of every protocol you will ever operate. The client asks the core to probe each outbound with a time-bound check—often a TCP connection attempt to a provider-defined test port, sometimes an HTTP request to a url-test or health-check URL embedded in the profile.

Reality is kinder and more boring: one shared failure mode can make every outbound look dead at once. Classic examples include Clash not actually capturing traffic yet (system proxy disabled while you expect TUN behavior), DNS returning unusable answers under fake-ip, a corporate firewall blocking outbound TCP to non-standard ports, or a subscription merge that produced zero usable nodes even though the dashboard still lists names.

Before you rotate every password on the provider side, separate “delay UI says red” from “browser still offline.” They overlap, but they are not identical signals.

Mechanically:This article is intentionally cross-platform. Desktop and mobile builds differ in labels, yet the diagnostic sequence repeats: confirm the profile is real, confirm the tunnel or system proxy path you think is active truly is, then walk DNS, UDP expectations, and health-check configuration.

For subscription fundamentals and add hygiene, keep the subscription add walkthrough open in another tab so you are not debugging DNS while the YAML never refreshed.

When that probe cannot everything included before the timeout, the UI paints the row red or shows a dash, and anxious readers assume the entire fleet collapsed overnight.

Step 1: Isolate the Delay Test from Real Browsing Mechanically

Operate two prompt experiments. First, with Clash disconnected, load a plain HTTP site you are allowed to visit. If that already fails, you are looking at underlying network or captive portal issues, not proxy tuning. Second, enable your usual policy group selection, pick whichever you pick node one at a time, and try a single HTTPS site through the browser you expect to be captured.

More strictly:Write down three facts: are you on system proxy, TUN, or a mixed setup; which DNS mode the profile uses; and whether the provider relies on exotic transports such as QUIC or Hysteria that need UDP end-to-end.

Those answers decide whether the next section is five minutes or an afternoon. For a deeper comparison of system proxy versus TUN and when global capture matters, read the TUN and global proxy guide—the mental model there prevents you from chasing UDP while HTTP never left the tunnel.

If browsing works while the node list stays red, your delay probe target or timeout is misfiring even though TCP relay is fine. Conversely, if browsing fails while ICMP ping to your router still works, capture mode or DNS is the more likely culprit than the remote datacenter.

Step 2: Subscription, Merge, and “Empty but Pretty” Profiles Step by Step

Lag tests iterate over outbounds the running config actually contains. If subscription refresh failed silently, certain GUIs still display cached names while the core merged an empty proxy list. Open the client log around the time you pressed refresh and search for HTTP status codes, TLS exceptions, and parser warnings.

At a different level:When in doubt, temporarily load a minimal profile with one well-known VMess or VLESS endpoint you control on a non-filtered network.

If even that single outbound goes red while a phone on cellular shows green for the same URI, you have localized the bug to the desktop OS path—firewall, loopback binding, or DNS—reasonably than to the remote machine. Always fetch fresh installers from our download page so you are not comparing behavior across years of core drift.

Rotate the subscription token if the provider returns HTML login pages or 403 responses. If you recently switched clients, confirm the new build supports every outbound type your provider ships; unsupported types may be skipped, which can leave you with fewer working nodes than you assume.

Step 3: DNS, fake-ip, and Why Everything Times Out Together Internals and Practice

Clash can answer DNS queries locally with fake-ip mapping so domain rules resolve quickly, but that power becomes a foot-gun when the rest of the stack disagrees about who owns resolution.

Thinking it through:Kick off by confirming which DNS section your profile uses: which nameservers are listed, whether fake-ip range matches your TUN subnet expectations, and whether nameserver-policy or proxy-server-nameserver entries send sensitive lookups down the tunnel.

Misconfigured DNS over HTTPS endpoints that cannot be reached without the proxy create a chicken-and-egg loop: Clash needs DNS to pick a node, but DNS itself waits on a path that is not up yet. Temporarily simplify: point to a single it holds up resolver, disable exotic DNS plugins you added for ad-blocking until the tunnel is not jumpy, and retest.

On Windows and Linux desktops, also check split DNS when VPN-style adapters appear. WSL2, Docker Desktop, and certain enterprise agents install competing resolvers.

First, a clarification:If Clash works for the host browser but not for a subsystem, you may need front-end-specific fixes such as those described in the Windows 11 and WSL2 routing article, because the delay test from the GUI uses the host stack while your project traffic uses another.

If the operating system still sends queries to a resolver that cannot see the same view as Clash, or if enhanced-mode and your TUN driver disagree, applications may attempt connections to addresses that never route through the tunnel you expect. The symptom is widespread failure: not one stubborn site, but everything classes of traffic, and delay tests that will want to resolve node hostnames may fail in unison.

Step 4: How the Lag Test Works (and What It Ignores) in Depth

Understanding the probe helps you interpret red rows fairly. Plenty builds measure TCP handshake time to a server-provided address and port, not ICMP ping. If your ISP or coffee-shop Wi-Fi blocks outbound TCP to high ports, every node hosted on those ports looks “dead” even though ICMP to 8.8.8.8 looks great.

ICMP-based ping tests, when exposed in a GUI, may be blocked by the remote firewall or by local security products that treat raw sockets differently from user-space TCP.

Mechanically:Treat ping and delay as related but not interchangeable metrics. If your client exposes both, compare them; wide divergence more often than not maps to filtering, not to packet loss on the ocean cable.

Timeouts deserve attention. Aggressive timeout values make flaky Wi-Fi look like total outage. If your profile sets deeply low thresholds for url-test or health checks, consider realistic values for wireless environments.

Conversely, if timeouts are enormous and the UI still freezes, the core may be stuck on DNS or TLS trust validation reasonably than on distance.

More strictly:Certain providers publish alternate test ports; others expect you to rely on url-test against an HTTPS endpoint on port 443, which survives more hostile networks.

Step 5: UDP, STUN, and Transports That Are Not TCP Delay Tests Mechanically

TCP delay success does not guarantee UDP readiness. Voice chat, certain games, and QUIC-heavy stacks stress UDP paths that your proxy may not forward unless you operate the correct mode. TUN-style capture generally offers broader UDP coverage than plain system proxy for applications that ignore OS proxy settings.

STUN sessions, used by WebRTC for NAT discovery, combine UDP timing with signaling plane behavior that bypasses naive “all TCP works, so UDP must work” assumptions. If a site shows relay or host connectivity exceptions while HTTP loads, capture browser console WebRTC diagnostics when policy allows.

The fix may be turning on UDP forwarding, choosing a node region closer to the STUN server, or accepting that certain networks block UDP entirely and forcing TCP-only tooling instead.

Protocols built on QUIC or custom UDP wrappers may need explicit outbound support in the core build. If your provider migrated to a UDP-first stack, re-sync the client from the maintained release channel and verify the feature matrix in release notes.

At a different level:Running a years-old GUI against a brand-new subscription is a frequent source of “everything times out” reports that are actually parser gaps.

If you require full-device UDP on desktop, align with the TUN guidance above; on mobile, VPN APIs differ, and OEM battery policies add noise—pair with the Android stability checklist when only handheld tests fail.

Step 6: Health Checks, url-test, and Automatic Group Selection Step by Step

Policy groups that use url-test or fallback depend on health check targets defined in YAML. When those URLs sit behind Cloudflare or regional edges that block datacenter IPs, automatic selection may oscillate or mark every member unhealthy. Confirm the url is reachable from a neutral network without Clash, then reintroduce the proxy.

Intervals matter for battery and log noise. Extremely frequent checks on mobile can wake radios and look like instability when the real issue is aggressive polling.

Thinking it through:On desktops, the opposite risk appears: long intervals hide transient blackholes. Balance your interval against reality: home fiber tolerates shorter probes, hotel Wi-Fi may need patience.

Certain providers ship stock health URLs that work globally; others assume you will edit them. If you operate private infrastructure, host a tiny static endpoint on port 443 dedicated to probes reasonably than reusing a heavy application URL that returns 302 chains.

Step 7: Local Firewall, Antivirus, and Corporate TLS Inspection Internals and Practice

Third-party security suites sometimes intercept loopback traffic or inject certificates into TLS streams. Symptoms include partial breakage: HTTPS sites load in one browser but not another, or delay tests fail while long downloads work.

Corporate networks with HTTPS inspection can break subscription fetch and health checks simultaneously. If you must use such a network, ask whether a transparent proxy expects a custom root of trust on your device.

First, a clarification:Without it, TLS failures cascade into empty profiles and red lag rows—not because Clash is broken, but because the middlebox terminates trust differently than your upstream provider assumes.

Temporarily pause on-access scanning only on a test machine you trust, or add explicit allow rules for the Clash binary and the TUN helper. On Windows, confirm both private and public firewall profiles allow the listening ports you configured for mixed inbound, especially when LAN sharing is enabled.

A Short Repeatable Checklist in Depth

When time is tight, operate this ordered list: verify plain internet without Clash; refresh the subscription and read logs; confirm system proxy versus TUN matches how you test; simplify DNS and validate fake-ip consistency; rerun delay tests with realistic timeouts; validate UDP and STUN-sensitive apps separately from TCP delay; review health-check URLs for automatic groups; scan firewall and antivirus rules.

After connectivity is predictable, deepen your setup through the configuration documentation hub for fine-grained rule tuning.

Mechanically:Compared with ad-hoc YAML copied from forums, a maintained client build plus disciplined DNS and health-check hygiene more often than not yields faster screens and fewer mystery regressions after OS re-syncs.

Most of of of “all red” tickets close before the last step because the failure was shared infrastructure—DNS or capture—not a worldwide outage.

Closing Thoughts Mechanically

Clash lag tests are a convenience layer. Treat red rows as a prompt to inspect DNS, UDP and STUN needs, capture mode, and health check targets—not as a verdict that every server on Earth failed.

For installers that match current core features and fewer parser surprises, kick off from one place instead of chasing scattered release threads. → Download Clash for free and experience the difference.

More strictly:When you methodically isolate those layers, you spend less time swapping nodes and more time using the connection you already paid for.