Fake-IP and DoH: Optimizing Clash's DNS Configuration

Why DNS Configuration Deserves Its Own Attention

DNS-related problems usually show up in two forms: DNS poisoning (domain resolution results get tampered with, causing broken access or redirects to the wrong page) and DNS leaks (the proxy is on, but DNS requests are still being resolved by your local ISP instead of going through the proxy, exposing what you're actually trying to access). The fixes differ, but both can be resolved with proper configuration of the dns section.

Fake-IP Mode: Skipping an Unnecessary Round Trip

The standard DNS resolution flow is: app requests a domain → a DNS server resolves the real IP → then the connection is made. This adds an extra network round trip, and if the DNS server itself isn't trustworthy, the result can also be poisoned.

What Fake-IP mode does: when a resolution request comes in, it immediately returns a "fake IP" from a reserved address range, and the client remembers which domain that fake IP maps to. Only when a connection is actually made does it perform real resolution as needed, or just forward through the proxy directly. The effect is that most scenarios skip the round-trip lookup entirely, and since most traffic ends up going through the proxy anyway, the IP resolved on the proxy node's end is much less likely to be poisoned.

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "time.*.com"
    - "dns.msftncsi.com"

fake-ip-filter: Which Domains Need to Be Excluded

Fake-IP works fine for the vast majority of cases, but a few categories of domains absolutely need to be excluded, or you'll run into things like "devices can't discover each other," "game accelerators stop working," or "internal network services behave abnormally":

Domains related to LAN device discovery (like *.lan, router admin page domains) — these need the real LAN IP to communicate properly.
Network quality detection domains (like dns.msftncsi.com) — Windows uses this to check network connectivity, and a fake IP will make the system misjudge your connection status.
Domain forwarding services for local devices like NAS/Synology — similarly, these need a real IP to establish a direct local connection.
Some games and real-time communication apps — sensitive to IP stability and authenticity, so it's a good idea to add them to the exclusion list.

Most mainstream clients ship with a fairly complete exclusion list already pre-configured by default, so you generally don't need to write one from scratch. If a specific LAN service isn't connecting, adding its domain to fake-ip-filter usually fixes it.

DoH / DoT: Encrypting the DNS Query Itself

Fake-IP addresses "whether to do real resolution at all," while DoH (DNS over HTTPS) / DoT (DNS over TLS) address "whether the resolution process itself can be eavesdropped on or tampered with." They wrap what would otherwise be a plaintext DNS request inside an encrypted channel before sending it out — your ISP or any intermediate node can't see which domain you're querying, and can't tamper with the result either.

dns:
  enable: true
  nameserver:
    - "https://doh.pub/dns-query"
    - "https://dns.alidns.com/dns-query"
  fallback:
    - "https://1.1.1.1/dns-query"
    - "https://8.8.8.8/dns-query"

nameserver is the default resolution upstream, and fallback is the backup upstream used when the result from a mainland China resolver isn't good enough — the client automatically decides whether to fall back to it based on the resolution result.

Split Resolution: Different Upstreams for Mainland China Domains and Everything Else

A more refined approach is to use nameserver-policy to assign a mainland China DNS resolver to mainland China domains and an encrypted overseas DNS resolver to everything else, balancing resolution speed with resistance to poisoning:

dns:
  nameserver-policy:
    "geosite:cn":
      - "https://doh.pub/dns-query"
    "geosite:geolocation-!cn":
      - "https://1.1.1.1/dns-query"

This way, mainland China sites resolve faster over a local route, overseas sites resolve more securely through an encrypted upstream, and neither side interferes with the other.

How to Tell If You're Actually Dealing With a DNS Problem

If the proxy already shows a normal connection (your exit IP has already switched), but certain sites load abnormally slowly or content redirects to a page it shouldn't, that's most likely a DNS-level issue rather than a proxy line problem. You can watch the client's "Connections" panel to see exactly which domain is resolving abnormally, then check it against the configuration above item by item. If a LAN device can't connect, first check whether fake-ip-filter is missing that domain.

Final Thoughts

DNS configuration falls into the "set it up once and forget about it" category — most subscription providers' default configs are already good enough for everyday use. The scenarios where you actually need to tweak it by hand are usually LAN device access issues or wanting stronger DNS privacy — just adjust the relevant fields following the approach above.