You run an IP purity check and the score comes back at 96. Location and network type both look right. Then the DNS leak test tells you the resolver sits in a different region.
That combination isn't a contradiction, and it doesn't automatically mean anything is leaking. IP purity and DNS leak tests look at completely different pieces of network data. To decide whether something is actually wrong, you need to find out who is handling your DNS queries — not just measure the distance between two addresses.

An IP purity check assesses the network characteristics and reputation of your exit IP — which ASN it belongs to, whether it's residential or datacenter, any history of abuse reports, and a risk score. Different tools draw on different data sources and scoring rules, so results don't always agree.
A DNS leak test, meanwhile, looks at which servers your domain lookups pass through. When you visit a site, your device has to turn a domain name into an IP address via DNS. If those queries leave through a path you didn't intend and land on some other resolver, that's a DNS leak.
So a high purity score only tells you the IP performs well within that particular rating system. It says nothing about whether your DNS setup is correct.
Not necessarily. Your exit IP might show Los Angeles while the test reports a resolver in another US city — or even another country.
Many public DNS services use Anycast, where the same address is served by machines in multiple regions. The location a test reports doesn't always reflect where your query actually went.
To judge whether a leak is real, focus on three things: whether the exit IP is the one you expect, which provider the resolver belongs to, and whether the queries follow the network path you intended.
A resolver sitting in a different region from your exit IP is not, on its own, evidence of a leak.
Inconsistent DNS across network interfaces. A computer often has several active interfaces — Ethernet, Wi-Fi, and so on. When they're pointed at different DNS servers, what actually resolves your queries may not be what you expected.
The browser has its own Secure DNS turned on. Chrome, Firefox, and others offer a Secure DNS feature that can override the resolver set at the system level. That's why the same machine can produce different results in different browsers.
IPv6 wasn't updated along with IPv4. Plenty of devices run both stacks. If you only changed the IPv4 DNS settings while IPv6 still points elsewhere, the test can come back with something you didn't anticipate.
The router or the network is handing out DNS. Home routers, office networks, and public Wi-Fi can all push DNS servers to your device automatically. Even if you've set things manually on the computer, it's worth confirming which resolver is actually in use.
Security software changed the resolution path. Some network utilities, browser extensions, and security tools take over DNS requests, which leaves test results out of step with your system settings.
When your purity score looks good but the DNS results don't, use ToDetect to review IP quality and DNS resolution side by side. Comparing the different metrics is the quickest way to tell whether you're looking at a real configuration problem.
| Check | What to look at | How to read it |
|---|---|---|
| IP purity | Quality score, network type, abuse history | Shows how your exit IP is rated; a high score doesn't mean DNS is fine |
| IP geolocation | Country, city, ASN, and ISP | Confirms the exit IP belongs where you expect it to |
| DNS leak test | Resolver IP, location, and provider | Checks whether the resolver in use matches your DNS settings |
| IPv6 test | IPv6 address and related network settings | Rules out IPv6 taking a different DNS path |
| WebRTC leak test | Any network addresses the browser exposes | Flags addresses being exposed that you didn't intend |
| Browser environment | Time zone, language, and fingerprint details | Gives context on how the device and browser are configured |
One caveat: a resolver in a different city or country from your exit IP doesn't necessarily mean a DNS leak. Confirm who owns the resolver and how the queries actually travel before comparing map pins.
Start by pinning down where the problem occurs, then change the setting that corresponds to it.
On Windows, open Settings → Network & Internet, go into the properties of your current connection, and check how DNS servers are assigned. After making changes, run this in Command Prompt: ipconfig /flushdns
That command clears the local DNS cache. It doesn't substitute for fixing the configuration itself.
On macOS, go to System Settings → Network, select the active connection, and review the DNS servers listed there.
If needed, run sudo dscacheutil -flushcache. And if only one browser shows the problem, check that browser's Secure DNS setting — the resolver it's using may not be the one you intended.
IPv6 keeps its own DNS settings. Review them separately, or you may fix IPv4 and leave the other path untouched.
Depending on your network, you can also switch to an encrypted DNS service that supports DoH or DoT, which lowers the risk of your queries being read in transit. Keep in mind that encryption protects the transmission, not the resolver's location — it won't necessarily line up with your exit IP.
Once you've made changes, reconnect to the network and run the DNS leak test again.
Testing in more than one browser helps confirm the resolver being reported matches what you set. If the results still don't line up, keep working through the network interfaces, IPv6, and any software that might intercept DNS.
There's no need to wait ten minutes or keep flushing the cache to decide whether the fix worked. Tools that test with freshly generated domains aren't usually showing you a stale resolver because of local caching.
Go by who actually owns the resolver and how the queries travel — not by whether every test happens to name the same city.
No. Purity mainly reflects IP reputation and network characteristics. DNS resolution, WebRTC exposure, and browser settings all need to be checked separately.
Not necessarily. If you're deliberately using the DNS provided by your ISP, that's expected behavior. It's only worth investigating when the actual path diverges from what you configured.
Work through Secure DNS in your browser, your IPv6 settings, the router, and any network management software — and confirm the change actually took effect.
A high IP purity score and a DNS leak warning aren't mutually exclusive — and a resolver showing up in another region doesn't prove a leak either.
Chasing a higher IP score matters far less than understanding how your exit IP, your resolvers, and your device's network settings relate to one another.
Use ToDetect to review IP quality, DNS resolution, and browser network details one at a time, then compare them against your actual setup. That's how you locate the real problem instead of misreading a difference in geography as a broken environment.
Efficiently solve multi-account management, environment isolation, and account security