Why DNS mode matters more than “faster lookups”
Most tutorials describe Fake-IP as a performance trick and redir-host as a compatibility fallback. That summary is directionally true yet undersells the failure modes. In Clash-class cores, DNS is tightly coupled to rule matching: the moment a hostname enters the pipeline, the core must decide whether to resolve it immediately, synthesize a temporary answer, or defer resolution until an outbound path is chosen. When that coupling disagrees with how your browser, captive portal, or file server expects DNS to behave, you see vague symptoms—endless loading spinners, certificate name mismatches, or “server not found” only while Clash is on.
If you already maintain a large ruleset, the interaction between DNS and MATCH order is documented in our YAML routing guide. Here we stay focused on the two DNS modes users toggle most often—and the LAN and intranet edge cases that send people back to search.
What Fake-IP does (in practical terms)
Under Fake-IP, the proxy core often returns a synthetic address from a dedicated pool (commonly a private range reserved for mapping) when an application asks the system for a domain’s IP. The real resolution can happen later, inside the core, once policy routing has chosen an outbound. The benefit is crisp: applications connect to a stable local-looking address quickly, and the core can attach the original hostname to connections that need Server Name Indication or HTTP Host headers intact. For browsing patterns dominated by public sites and encrypted HTTPS, that model feels snappy.
The tradeoff shows up around split expectations. Some software assumes that if ping internal-nas returns an address, that address is literally reachable on the LAN. With Fake-IP in play, the answer may be a mapped placeholder that only makes sense after Clash rewrites the flow. When a rule accidentally sends that flow through a remote proxy—or when the core never gets a chance to map the return path—you experience classic local resolution failure: the name “resolves,” yet nothing answers, or you reach the wrong interface entirely.
Another subtle issue is double resolution: the operating system may still consult a corporate resolver for some queries while the tun interface advertises the core as the DNS handler. If those two worlds disagree on split-DNS or search domains, you can see intermittent failures that look like “the site works once, then not again.” Pairing Fake-IP with transparent modes is covered from the adapter angle in our TUN and system proxy troubleshooting guide, which is worth reading if your symptoms span all applications rather than a single browser tab.
What redir-host changes
Redir-host (sometimes described as redirecting based on the real hostname) biases the pipeline toward resolving names closer to what traditional resolvers produce before connections are classified. Implementations vary slightly by fork, but the user-visible pattern is consistent: fewer synthetic early answers, more reliance on upstream DNS results feeding rule decisions. That tends to be kinder to intranet portals, router GUIs on RFC1918 addresses, and devices that hardcode assumptions about PTR or split-horizon DNS.
The cost is less exciting in benchmarks: you may pay for an extra resolver round trip in some paths, and poisoned or slow upstreams surface as slower page starts rather than being masked by immediate placeholder IPs. For many home labs and mixed LAN setups, that honesty is preferable to mysterious breakage. If your profile already pins domestic CDNs or geo-sensitive hosts with fine-grained rules, redir-host can also make misconfigured nameserver-policy entries obvious sooner—which is good when you are debugging, even if it feels worse for five minutes.
Which mode should you start with?
Use this as a first-pass heuristic, then refine with the checklist later. Start with Fake-IP when you mostly browse public internet destinations, you run a mature ruleset with explicit LAN bypass (DIRECT for private IP ranges and local domain suffixes), and you are on a client stack known to integrate tun DNS hijack cleanly. Treat redir-host as the default when you regularly touch local domain resources—Active Directory short names, university VPN split tunnels, multi-subnet Wi-Fi with captive portals, or NAS discovery protocols that combine multicast DNS with unicast fallbacks.
On mobile, battery and vendor DNS “helpers” amplify DNS weirdness. If you are chasing timeouts alongside mode questions, layer the device-side steps from our Android subscription and DNS checklist after you stabilize the YAML DNS section; phones rarely fail for a single reason.
Symptom cluster: LAN hostnames and admin consoles
When router.lan, nas.local, or a numeric gateway page fails only with Clash enabled, assume three concurrent stories: routing scope (did the packet leave the machine on the intended interface?), resolver scope (who was asked, and which search suffix was applied?), and mapping scope (Fake-IP pool versus real LAN address). Begin by verifying bare IP access—if https://192.168.1.1 works but the hostname does not, you are overwhelmingly in DNS territory.
Confirm your rules send RFC1918 and typical multicast DNS ranges to DIRECT before any aggressive MATCH that grabs “everything else.” A common mistake is a catch-all GEOIP or ASN rule that races ahead of LAN exceptions. Our rule splitting article shows how to keep exceptions readable as the profile grows.
If bare IP works and rules look sane, switch the experimental variable: move from Fake-IP to redir-host temporarily. If intranet access returns instantly, your profile likely needs tighter nameserver-policy mapping for local suffixes—or Fake-IP is simply the wrong default for that network. Some users maintain two profiles: “home lab” with redir-host and “travel” with Fake-IP. That is a valid operational pattern as long as you name files so future you picks the right one.
Symptom cluster: some public sites never finish loading
Not every stubborn page is LAN-related. When only certain publishers, app backends, or regional CDNs fail, collect whether the failure is DNS (NXDOMAIN, no A/AAAA), TLS (handshake stalls), or TCP (RST after SYN). Fake-IP can expose TLS mismatches if a remote middlebox expects different SNI timing relative to address selection. Redir-host may shift you to a different CDN node, which fixes or breaks geo-routed content depending on your outbound.
Log the resolver path: ensure encrypted DNS upstreams are reachable from every outbound you use. A profile that forces domestic queries through a foreign resolver (or the reverse) can yield empty answers or filtered responses that masquerade as “slow internet.” Align proxy-server-nameserver (or your fork’s equivalent) with the nodes that must resolve while connected, and avoid routing the resolver’s traffic through the same failing tunnel in a tight loop.
For streaming-style destinations where DNS and exit region must agree, see the dedicated split in our Netflix region guide; the same discipline applies to other geo-sensitive hosts, not only video.
nameserver-policy, fallback, and split DNS
Modern Clash Meta (mihomo) profiles often define multiple upstreams: a fast public resolver for general browsing, a secondary for on-proxy queries, and targeted policies for specific domains. Use nameserver-policy (or your engine’s equivalent) to pin *.corp.example to the office resolver, *.lan to the gateway, and leave the default pool for everything else. Without that split, you may query a resolver that legitimately knows nothing about your private zone—producing resolution failure that no outbound can fix.
Fallback groups deserve attention too. If the primary DoH endpoint is blocked on your access network, a well-constructed fallback prevents total DNS collapse. Conversely, an overly aggressive fallback that always prefers a distant resolver can steer you to CDN nodes that violate your content expectations. After any change, reload the profile and test with a small script or dig-style tool through the same interface the browser uses; guessing from a single favicon spinner wastes time.
Ordered troubleshooting checklist
Work top to bottom; skip steps only when you already have hard evidence.
- Confirm interface and bypass: Can you reach the same host by IP? If not, fix interface metrics, VPN overlap, or firewall before DNS.
- Audit rule order: Ensure LAN, loopback, and metadata rules precede wide catch-alls.
- Isolate DNS mode: Flip Fake-IP ↔ redir-host once, retest both a LAN name and a public name.
- Map resolvers: Add or refine nameserver-policy for private suffixes; remove dead DoH URLs.
- Break routing loops: Verify on-proxy DNS queries are not forced through a broken outbound.
- Check IPv6: If AAAA exists but your tunnel mishandles IPv6 on that network, test with IPv4-only temporarily.
- Read engine logs: Look for repeated lookup failures, TLS errors to resolvers, or policy drops.
- Retest on a second network: Captive portals and hotel DNS interception mimic Clash bugs—compare LTE versus home fiber.
This sequence deliberately places heavy YAML surgery last. Most painful tickets become obvious once IP reachability, rule order, and resolver split are honest.
Symptom quick map
| What you see | What to try first |
|---|---|
| LAN hostname fails; IP works | Rule bypass, nameserver-policy for local suffix, try redir-host |
| HTTPS error or wrong cert on intranet | Routing to wrong outbound; disable path that re-encrypts internal names |
| Only some regions or CDNs break | Resolver geography vs exit node; avoid resolver↔tunnel loop |
| Everything resolves but pages hang | MTU/TUN issues; see TUN guide; test non-HTTP tools |
Jump back to the matching section instead of restarting from scratch each time you tweak the profile.
Open source and engine differences
Feature names and YAML keys drift across forks. When something in this article does not match your UI verbatim, compare against the documentation for your exact core build. The mihomo repository is a common reference for Clash Meta behavior—use it for source, issues, and protocol details, not as the primary channel to distribute installers.
Closing thoughts
Fake-IP and redir-host are not rivals where one is always correct; they are different contracts between your operating system, the resolver chain, and the proxy core. Picking the right DNS mode is less about chasing synthetic benchmarks and more about matching how your networks actually name things—from a boring gateway page to a geo-split public API. Once resolver splits and rule order are clean, most local domain mysteries disappear, and the remaining site load issues shrink to ordinary routing or TLS problems you can measure.
Compared with opaque one-switch VPNs that hide DNS behind marketing copy, a Clash-class client rewards a little structure: you see which resolver answered, which outbound carried the flow, and why a name failed. That transparency pays off the first time you debug a finicky LAN without unplugging everything in the rack.
For desktop-wide capture and rollback when the whole machine loses DNS, continue with the TUN troubleshooting tutorial; for more topics, browse the full tech column.