Clash Connected but No Internet? Fix DNS Leaks and Fake-IP Step by Step

Name the failure: three kinds of “false OK”

Users often describe the same outage in vague terms. Before editing YAML, bucket what you see:

• Browsers only: chat apps or terminals work, which points to per-app DNS (DoH), extensions, or a browser that ignores system proxy settings.
• Everything hangs while Clash still logs connections: classic DNS leak or broken nameserver reachability—the tunnel exists, but names never resolve consistently.
• Domestic sites load, foreign sites time out: could be dead proxy groups, but DNS should still be ruled out first so you do not chase nodes for hours.

Step 1: decide if DNS or the tunnel is lying

Pick one domain you know should use the proxy. Then:

1. Run ping or nslookup in a terminal. If the command itself stalls before any IP prints, you are still in DNS or local-network territory.
2. Use curl -v https://example.com (swap in your target) and note whether it stalls before TCP connects or after TLS starts—pre-connect stalls usually mean DNS or routing; late failures lean toward SNI, certificates, or node quality.
3. Open Clash’s connection or log view and read the policy and final outbound for that hostname. A foreign site marked DIRECT is almost always rule order, not magic packet loss.

DNS leaks: the OS still talks to ISP resolvers

A DNS leak means Clash is not the only resolver in the room. Windows may still point adapters at 8.8.8.8 or your router; the router’s DHCP option may force a captive DNS; corporate portals hijack UDP/53; browsers with “secure DNS” can bypass the OS entirely. Clash routes using one answer while the app connects using another, so the UI looks healthy even though HTTPS never lines up with the policy you think you wrote.

Desktop triage should include adapter IPv4/IPv6 DNS settings, competing virtual adapters from game boosters or legacy VPNs, and whether TUN mode is actually redirecting DNS per your fork’s documentation. System-proxy-only setups cannot see traffic from apps that never consult the OS resolver stack.

fake-ip vs redir-host: where the “fake” addresses come from

enhanced-mode: fake-ip hands synthetic addresses to applications so rules can trigger quickly and real lookups leak less often. The trade-off is complexity: cached fake addresses, overlapping fake-ip-range with LAN subnets, or mismatched domain/IP rules can produce “sometimes it loads, sometimes it does not until I flush DNS.”

redir-host stays closer to traditional behavior—resolve, then policy—which can be easier on older clients or UDP-heavy games. Neither mode wins every network; match the mode to your rule provider’s expectations and your client fork’s feature set.

• After switching modes, flush the OS resolver cache and restart browsers; stale records are the silent culprit.
• Review subscription-provided fake-ip-filter lists: they force real resolution for listed domains and can interact oddly with custom DOMAIN rules.
• Keep RFC1918 destinations and management portals on explicit DIRECT rules near the top so LAN traffic never rides the tunnel by accident.

nameserver, fallback, and “cannot bootstrap DNS”

dns.nameserver lists the upstreams Clash queries. If every entry requires a working proxy to reach, but the proxy needs DNS first, you have a chicken-and-egg outage that looks like a dead node. A robust template almost always includes at least one resolver that is reachable without the tunnel on your current ISP.

Splitting nameserver (fast local) from fallback (encrypted or offshore) plus fallback-filter is standard in modern Meta configs. When in doubt, start from your provider’s stock YAML and adjust one field at a time so logs stay interpretable.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://dns.cloudflare.com/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

The snippet illustrates structure only; keyword availability varies between Premium, Meta, and community builds—always confirm against the manual for the binary you actually run.

Rule priority: specific rules beat broad ones

Clash evaluates rules from top to bottom and stops at the first match. Placing GEOIP,CN,DIRECT above fine-grained proxy rules can strand overseas traffic on a broken direct path. Putting a catch-all proxy before LAN exceptions nukes printers and NAS web UIs. Forgetting a final MATCH leaves unmatched flows undefined.

When debugging, never “fix” order from memory. Search the YAML for the rule name shown in the log and check its physical line number relative to broader matches. A shocking number of “my DOMAIN rule does nothing” reports are simply rules appended after MATCH.

Browser DNS-over-HTTPS and half-proxied stacks

Major browsers can enable DoH independently. Clash may see no DNS query at all for those tabs, while the browser happily resolves through Cloudflare or Google and builds TCP sessions outside the policy you tested in curl. Turn secure DNS off for a controlled test, use a clean profile, and disable extensions that inject proxies or “optimize” traffic.

If only one browser reproduces the bug, treat it as a client-stack issue before rewriting your entire subscription.

TUN vs system proxy: who owns DNS

System proxy mode is lightweight but leaky: anything that ignores OS proxy settings or speaks QUIC may bypass your carefully crafted rules. TUN mode pushes traffic through a virtual interface so DNS redirection and routing stay coherent, at the cost of conflicting with corporate VPNs or zero-trust agents.

If you live in system-proxy land and keep seeing flaky browser behavior, enable TUN once (with documented DNS options), compare logs, and decide whether the trade-offs are acceptable on that machine.

Optional CLI evidence (ping, dig, curl)

Power users should collect short transcripts: resolver output, Clash log slices, and curl verbose traces from the same minute. That trio answers most forum threads without guessing. When sharing logs publicly, redact tokens and subscription hosts, but keep policy names intact so others can see which rule fired.

On Windows, ipconfig /flushdns clears stale resolver entries after you toggle fake-ip or rename rules. macOS users can restart mDNSResponder or reboot once when caches refuse to cooperate. Linux desktops vary by resolver (systemd-resolved, NetworkManager, dhcpcd); the actionable point is the same—after any DNS-facing change, prove with a fresh lookup that the answer matches what Clash expects before loading heavy pages.

When the tunnel is fine but the upstream is not

Sometimes every DNS check passes, rules look perfect, and you still see endless TLS retries. That is the moment to widen the lens: congested exit datacenters, exhausted data quotas, or provider-side filtering can masquerade as local misconfiguration. Cross-test the same profile on a different network, swap to another node region, and ask whether only one protocol (UDP vs TCP) fails. If multiple regions and protocols fail together while plain ICMP to the node still works, you may be dealing with application-layer blocking rather than Clash DNS. Document timestamps and traceroutes before opening a ticket—support teams move faster when you show that DNS alignment was already verified.

Printable checklist: connected but offline

FAQ

Ping works but HTTPS does not?

Ping may target a different address family or a CDN edge that does not reflect your browser’s SNI path. Trust the hostname from the browser devtools or Clash logs, not a single ICMP sample.

Only Google properties fail?

Often a combination of policy misrouting and resolver pollution. Temporarily switch to Global to confirm, then return to Rule and tighten DOMAIN/SNI coverage based on evidence.

IPv6 suspicion?

Disable IPv6 briefly at the OS level as an experiment. If symptoms vanish, fix IPv6 handling in rules instead of leaving IPv6 off forever.

Closing thought

Most “Clash connected but no internet” cases resolve once DNS, fake-ip behavior, and rule precedence line up with what the logs say—not with forum folklore about which city is “fastest.” Work the checklist top to bottom, change one variable per iteration, and you will usually know within twenty minutes whether you are fighting DNS or fighting a dead upstream.

Download Clash for free and start with a maintained client build—clearer defaults and up-to-date templates beat hand-merging mystery YAML when you are already under stress.