When the Tunnel Works but the Page Does Not

Many support threads start the same way: the tray icon is green, latency to a test host looks normal, streaming or chat works, and then one bank portal, corporate SSO page, or long-tail blog simply never finishes loading. Sometimes the tab stays white forever; sometimes the spinner dies after thirty seconds with a generic network error. Those symptoms feel random until you realize that DNS mode, rule granularity, and what the core can infer about the intended hostname must stay in agreement.

Mihomo (the core commonly bundled with modern Clash GUIs) can answer DNS locally, forward it through encrypted upstreams, or synthesize temporary addresses when you run enhanced-mode: fake-ip. Each choice shifts when the real IP is known and therefore when IP-based rules fire. Misalignment between what your YAML assumes and what the stack actually does is the fastest path to “some sites only.”

If you have not read how resolver capture interacts with TUN and system proxy yet, start with our DNS leak prevention guide; this article focuses on breakage rather than privacy tests.

Fake-IP versus Redir-Host in Plain Language

Both strings live under the dns: section as enhanced-mode values. They are not “speed modes” or “security levels.” They describe how aggressively the core rewrites DNS answers so domain-aware routing can stay coherent with the way operating systems and browsers open connections.

Fake-IP hands out synthetic addresses

With Clash Fake-IP enabled, the core may return addresses from a private range (for example 198.18.0.0/15 in many templates) even before it has finished resolving the real origin. Applications connect toward that synthetic target; the tunnel intercepts the flow and only then completes resolution and policy selection. The upside is crisp domain-based routing: the engine already knows which name the user wanted, so DOMAIN and DOMAIN-SUFFIX rules line up with user intent more often.

The downside is that anything in your stack that insists on “real” answers early—certain desktop clients, older VPN coexistence tricks, or exotic split-DNS setups—can misbehave unless you carve out exceptions with fake-ip-filter and disciplined nameserver-policy. When those exceptions are missing, you see mysterious partial loads rather than clean error pages.

Redir-host resolves earlier

Redir-host (sometimes written redir-host in docs) pushes the resolver toward returning real addresses that match what upstream DNS actually said. That can feel more familiar to administrators who are used to watching A and AAAA records in packet captures, and it can simplify debugging when you want the same IP the public resolver announced.

Yet redir-host shifts more work onto the relationship between your nameserver list, fallback chains, and outbound policy. If a domain is resolved “direct” to an IP that only answers on a network path your proxy was supposed to provide, the browser still breaks even though DNS technically succeeded. You also increase the surface area for race conditions where IP-based rules trigger before the core has attached the domain context you cared about—especially if you lean on GEOIP or CIDR matches without accompanying domain rules.

Map the Failure Before You Toggle Anything

Grab one broken site and classify what you observe in three buckets. First, DNS never completes: the status line hangs on “resolving host,” and your core log shows repeated queries or timeouts toward an upstream. Second, TCP connects but TLS or HTTP stalls: resolution finished, yet handshakes retry or reset. Third, content loads partially: the HTML arrives, then dozens of third-party hosts sit pending—often a rules issue masquerading as DNS.

That quick triage keeps you from flipping enhanced-mode blindly. DNS-mode changes help primarily when hostname visibility or resolver timing is wrong; they will not fix a dead outbound, an MTU black hole, or a rule that sends API calls to the wrong group. For log vocabulary and port-level errors, pair this walkthrough with our log diagnosis article.

Sniffer, SNI, and HTTP Host — Power and Risk

Modern Mihomo builds ship a sniffer that inspects the first bytes of a flow to recover a hostname when the connection was opened by IP after Fake-IP or when metadata would otherwise be opaque. In theory that restores domain rules for TLS ClientHello SNI and plain HTTP Host headers. In practice, poorly scoped sniffing interacts badly with uncommon ports, non-standard clients, or middleboxes that reuse certificates across unrelated names.

When users say “everything broke after I enabled sniffing,” the underlying story is often double matching: the core thinks it sees one name while the application believed it was talking to another, or QUIC/HTTP3 shortcuts bypass the code path you tuned for TCP. Conversely, when sites not loading correlate with IP-only rules and Fake-IP together, cautious sniffing with explicit skip-domain and skip-src-address style exclusions (per your GUI and core version) can be the bridge that makes DOMAIN rules fire again.

Treat sniffing as a scalpel. Turn it on to validate a hypothesis, watch logs for rewritten destinations, then narrow scope so you are not inspecting traffic that does not need help.

Step-by-Step Fault Tree for Blank or Timing-Out Sites

Follow the steps in order. If a step resolves the symptom, stop and document what you changed so the next upgrade does not erase your reasoning.

Step 1 — Confirm capture path. In TUN mode, verify that the browser process is actually inside the tunnel. On laptops with multiple profiles, it is easy to test Safari while Firefox still bypasses the adapter. Switching capture mode without retesting is a classic source of false negatives.

Step 2 — Isolate DNS upstream health. Temporarily set a single well-known DoH or TLS resolver in nameserver, remove exotic fallbacks, and reload. If the broken site suddenly works, your previous chain was starving or looping—not proving anything about Fake-IP versus redir-host yet.

Step 3 — Compare Rule versus Global. If Global mode loads the site but Rule mode does not, you have a policy problem, not a DNS-mode problem. Inspect whether the domain or its CDN aliases are hitting DIRECT while the IP path requires the proxy, or the opposite.

Step 4 — Audit Fake-IP filters. For Fake-IP deployments, ensure internal TLDs, captive portal hosts, and provider-specific domains that must resolve “for real” on LAN appear in fake-ip-filter (or equivalent GUI fields). Missing filters often show up as intranet or carrier-grade NAT services that work on plain Wi-Fi but not through the tunnel.

Step 5 — Sniffer on/off A/B test. Disable sniffing entirely, reload only one broken tab, and observe. If behavior improves, re-enable with tighter port and domain allow lists rather than running wide open.

Step 6 — Switch enhanced-mode intentionally. Move from Fake-IP to redir-host (or back) as a controlled experiment after the upstream and rules are sane. Note that some GUIs relabel these options; verify the generated YAML. Give each mode five minutes of ordinary browsing so DNS caches are not fooling you.

Step 7 — Revisit QUIC and HTTP3. Some breakage is simply parallel UDP flows that your rules never matched. If disabling QUIC in the browser makes the site reliable, duplicate the policy for UDP in the core instead of leaving QUIC off forever.

Habit: For every change, keep one terminal tailing the core log and one window on the connections panel. Correlating timestamps beats guessing whether DNS or dial failed first.

Align DOMAIN Rules With the DNS Mode You Chose

Rulesets downloaded from the community are written for generic averages. Your employer, bank, or regional CDN may need explicit DOMAIN entries above broad GEOIP shortcuts. Under Fake-IP, the core usually sees the clearest hostname story; under redir-host, lean on explicit domain rules earlier in the file because IP-only matches may activate before you expect.

When you import third-party providers, watch for duplicates and contradictions—two files that disagree will not always fail loudly; they often yield “works on Tuesday” behavior as providers reorder lines. For sustainable performance tuning once routing is stable, see our speed and DNS tuning notes.

When nameserver-policy Saves Fake-IP Deployments

Fake-IP shines when global policy is consistent, yet real networks still contain zones that must be resolved on specific resolvers. Corporate split DNS, country-local CDNs, and captive portals are not theoretical edge cases; they are everyday reasons why a synthetic answer must never mask a critical lookup.

Pin those suffixes with nameserver-policy so the core asks the right upstream before it synthesizes anything misleading. If you skip that step, you will chase ghosts in the sniffer while the real bug was always “wrong resolver for this subtree.”

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://cloudflare-dns.com/dns-query
  nameserver-policy:
    "+.corp.example":
      - tls://internal-dns.corp.example:853
    "+.lan":
      - system

Adapt suffixes and transports to your environment; the structure matters more than copying public endpoints verbatim.

Choosing a Default Mode for 2026 Networks

Neither Fake-IP nor redir-host wins every network. As a pragmatic default, many Mihomo users stay on Fake-IP because it keeps domain rules honest on busy rule lists, then maintain a short fake-ip-filter list for the handful of names that demand real records immediately. Choose redir-host when you are debugging with packet captures, when a legacy application fights synthetic addresses, or when your operator documentation explicitly assumes classical A/AAAA answers.

Whatever you pick, make the YAML match the GUI, restart the core cleanly, and invalidate browser DNS caches by closing the profile entirely—not just the active tab.

Documentation, Upgrades, and Parser Drift

Field names and defaults move between releases. After every upgrade, diff your effective config against release notes instead of assuming yesterday’s Fake-IP behavior survived intact. The documentation hub on this site links the concepts this article cites; use it as the authoritative glossary when a GUI label disagrees with YAML.

Legal use: Route only traffic you are permitted to route. Respect employer device policies and local regulations; this material is for troubleshooting networks you own or administer.

From Mysterious Blanks to Predictable Fixes

Sites not loading behind a working proxy are rarely magic. They are almost always a story about resolver timing, hostname visibility, sniffing scope, or a rule that sends one CDN hostname down the wrong outbound. Comparing Clash Fake-IP with redir-host is not about picking the cooler keyword—it is about choosing which phase of the connection your policy engine sees the truth, then making sniffer settings and DOMAIN rows match that truth.

Compared with juggling single-purpose VPN utilities, a maintained Mihomo-based client keeps DNS modes, sniffer toggles, and policy groups in one place so each experiment stays reversible. When you are ready to test on a current build with up-to-date DNS defaults, install a fresh client from our download page and pair it with the configuration reference while you iterate. → Download Clash for free and experience the difference.