Troubleshoot DNS pollution and lookup errors

Decide first whether DNS is even involved

The phrase cannot open the site covers far too many faults, and DNS is one layer of them. Matching the symptom first saves most of the guesswork.

• An overseas site resolves to 127.0.0.1, 0.0.0.0, or an address with no connection to that service. Classic poisoning.
• The first load stalls for several seconds, then everything is fine: a resolver is not answering and the query retries past a timeout.
• Some hostnames fail, but the same service reached by IP works. The path is fine; resolution is where it breaks.
• The proxy is running and a few sites still will not open. Resolution may be happening outside the proxy, or DNS may be innocent here.

Ask two resolvers the same question

The fastest test is asking twice: once through whatever DNS the system currently uses, once against a public resolver you name explicitly.

nslookup www.example.com
nslookup www.example.com 8.8.8.8
dig +short www.example.com @1.1.1.1

One side returns a working address, the other gives 127.0.0.1 or an unrelated range: strong evidence the default path is tampered with. Caveat — plain port 53 to 8.8.8.8 can be forged in transit too, so this proves the two differ, not that the second answer is genuine.

If both sides agree but both are slow, the answer is not your problem, the path is. nslookup retries after a timeout, so a command that takes seconds to print anything is the signal.

With Fake-IP on, the address is supposed to be fake

With dns.enhanced-mode set to fake-ip, the system resolves a placeholder the core invents on the spot, from the range in fake-ip-range, commonly 198.18.0.0/16. Seeing 198.18.x.x is not poisoning; the real lookup happens at the node.

So a system-level nslookup is close to useless here: you get the placeholder either way, and pinging it proves nothing. For the real result, read the target hostname and exit in the connections list, or switch back to redir-host for one test.

Cache, browser DoH, and answers that look correct

1. Flush the cache after any DNS change. Windows uses ipconfig /flushdns; macOS wants the mDNSResponder routine, whose exact command has shifted between releases; on Linux it depends on systemd-resolved or dnsmasq. Skip it and you are testing an old record.
2. Browsers resolve on their own. Secure DNS in Chrome and DNS over HTTPS in Firefox bypass the system resolver, so turn them off while diagnosing or the command line and the browser describe different worlds.
3. The client caches too. After editing nameserver or nameserver-policy, reload the profile and close the stale entries in the connections list.

One case deserves separating out: nslookup returns an ordinary IP and the browser still will not load. Resolution already succeeded. Look next at which rule the connection matched, which exit it took, and whether the node works.