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

What “All Nodes Red” Actually Measures

In most Mihomo-based Clash GUIs, the color beside a server is driven by a latency or delay test, not by a full quality audit of every protocol you will ever run. 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. When that probe cannot complete before the timeout, the UI paints the row red or shows a dash, and anxious readers assume the entire fleet collapsed overnight.

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.

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 import hygiene, keep the subscription import walkthrough open in another tab so you are not debugging DNS while the YAML never refreshed.

Step 1: Isolate the Delay Test from Real Browsing

Run two quick 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 any node manually, and try a single HTTPS site through the browser you expect to be captured. 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.

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.

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

Latency tests iterate over outbounds the running config actually contains. If subscription refresh failed silently, some 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 errors, and parser warnings. 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.

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—rather than to the remote machine. Always fetch fresh installers from our download page so you are not comparing behavior across years of core drift.

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

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. 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 whole classes of traffic, and delay tests that need to resolve node hostnames may fail in unison.

Start 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 reliable resolver, disable exotic DNS plugins you added for ad-blocking until the tunnel is stable, and retest.

On Windows and Linux desktops, also check split DNS when VPN-style adapters appear. WSL2, Docker Desktop, and some enterprise agents install competing resolvers. If Clash works for the host browser but not for a subsystem, you may need interface-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.

Step 4: How the Latency Test Works (and What It Ignores)

Understanding the probe helps you interpret red rows fairly. Many 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. Some 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.

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. Treat ping and delay as related but not interchangeable metrics. If your client exposes both, compare them; wide divergence usually 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 very 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 rather than on distance.

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

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

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 errors 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 some 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, update the client from the maintained release channel and verify the feature matrix in release notes. Running a years-old GUI against a brand-new subscription is a frequent source of “everything times out” reports that are actually parser gaps.

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

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. Some providers ship stock health URLs that work globally; others assume you will edit them. If you run private infrastructure, host a tiny static endpoint on port 443 dedicated to probes rather than reusing a heavy application URL that returns 302 chains.

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. 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.

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

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. 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.

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. Without it, TLS failures cascade into empty profiles and red latency rows—not because Clash is broken, but because the middlebox terminates trust differently than your upstream provider assumes.

A Short Repeatable Checklist

When time is tight, run 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. Most “all red” tickets close before the last step because the failure was shared infrastructure—DNS or capture—not a worldwide outage.

After connectivity is predictable, deepen your setup through the configuration documentation hub for fine-grained rule tuning. Compared with ad-hoc YAML copied from forums, a maintained client build plus disciplined DNS and health-check hygiene usually yields faster screens and fewer mystery regressions after OS updates.

Closing Thoughts

Clash latency 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. When you methodically isolate those layers, you spend less time swapping nodes and more time using the connection you already paid for.

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