Your network environment is switched, your IP address looks right, and your browser language and time zone are set correctly. So why does a site still recommend content from your old region?
In that situation, checking the exit IP isn't the only thing worth doing — you can also look at whether DNS resolution is taking the path you expect. That said, localized recommendations can also be shaped by cookies, account region, and browsing history. You can't call it a DNS leak based on recommended content alone.

DNS (Domain Name System) turns website domain names into IP addresses. When you visit a site, your device usually has to resolve the domain first, then connect to the target server.
Under normal conditions, DNS queries go to the resolver specified in your current network configuration. A DNS leak happens when the rest of your traffic follows the expected path, but DNS requests bypass it and go to a resolver you never intended to use.
Traditional DNS typically runs over UDP port 53, and queries are unencrypted by default. DoH (DNS over HTTPS) and DoT (DNS over TLS) can encrypt the query itself, but encrypted DNS isn't a cure for DNS leaks — whether requests actually travel the right path matters just as much.
Common causes include leftover DNS settings on the system, IPv6 pointing at a different resolver, a browser with its own DNS enabled, and a router pushing its default settings back down.
No extra software needed — you can run the check online with ToDetect. Open ToDetect, run the network environment detection feature it provides, and pay close attention to these signals:
• Exit IP: confirm the IP address and region your current connection shows.
• DNS servers: check the resolver IPs detected, along with their provider and location.
• WebRTC info: a secondary check on whether the network addresses your browser exposes match what you expect.
The DNS server list is the key evidence for judging the resolution path.
For example, if the exit IP shows the US but the DNS results include local carrier servers that shouldn't be in use at all, it's worth digging into your system, browser, and IPv6 settings.
Note that a DNS server sitting in a different region from your exit IP isn't automatically a leak. Public DNS services use distributed nodes, and IP geolocation databases can be off. What matters is whether the resolver provider matches what you expected — not a simple country-by-country comparison.
Once the test finishes, use the cases below to interpret what you're seeing:
| Test Result | Likely Cause | Suggested Action |
|---|---|---|
| DNS provider matches expectations | Resolution setup is probably fine | No immediate change needed |
| An unexpected carrier DNS appears | System or IPv6 configuration is out of sync | Check your DNS settings |
| Several different providers show up | Browser and system may be resolving separately | Verify the resolution configuration |
| DNS results don't match your settings | Router or a network tool may be altering the resolution path | Check each item in turn |
For example, one test might show two DNS servers: one belonging to the public DNS provider you specified, the other belonging to your current network carrier. That alone doesn't prove a leak, but it does suggest more than one resolution path may be in play.
At that point, check the browser and system settings separately, make your changes, then re-test and see whether the server list changes.
Some devices run IPv4 and IPv6 side by side, but the two use different DNS servers.
Try disabling IPv6 temporarily and re-test. If the unexpected DNS entry disappears, the issue is probably tied to your IPv6 configuration. Once you've confirmed the cause, configure IPv6 DNS properly and turn IPv6 back on, rather than leaving it off long term.
• On Windows 11, go to Settings → Network & Internet, find the DNS server assignment for your current connection, and switch it to manual configuration.
• On macOS, go to System Settings → Network → your current connection → Details → DNS to review or adjust your resolvers.
When you make changes, pick a DNS provider you trust and that fits your current network needs. Simply swapping in a public DNS address doesn't guarantee every query takes the path you expect.
Chrome, Edge, and Firefox all support their own encrypted DNS settings.
If the browser points to a different DNS provider than the system does, test results may show multiple resolvers. Align the two with your actual needs so the browser and the system don't drift apart unexpectedly.
Some routers hand out DNS addresses to devices automatically over DHCP. Even if you've changed the system settings by hand, reconnecting to the network can put things right back.
Log in to your router's admin page and check the IPv4, IPv6, and DHCP-related DNS settings to confirm they match your device configuration.
• On Windows, open Command Prompt and run: ipconfig /flushdns
• On macOS, run this in Terminal: sudo dscacheutil -flushcache
After flushing, reconnect to the network and check the DNS server list in ToDetect again. Keep in mind that browsers may hold their own cache, and flushing the cache won't fix a resolution path that's already wrong.
Possibly. Some public DNS services run distributed infrastructure, so server locations don't have to match your exit IP. Judge by the provider and your actual configuration.
Not necessarily. Encrypted DNS mainly protects query contents in transit. On its own, it doesn't guarantee that queries always go out over the network path you specified.
They can be tested when needed. Both Android and iOS support encrypted DNS configuration, though the exact steps depend on the OS version, and some apps may use their own resolution method.
The browser may be using its own DNS, the IPv6 configuration may not be in sync, the router may have pushed addresses down again, or cached results may be interfering. Check one item at a time instead of changing several settings in a row.
DNS settings can change as you switch networks, adjust your router, or update your system. After connecting to public Wi-Fi in particular, it's worth re-checking whether your current resolvers match expectations.
It helps to save a test result from a known-good state, then compare DNS providers, server IPs, and exit information against it later.
With ToDetect's online test, you can cross-reference DNS, IP, and WebRTC signals to trace anomalies in your network environment. When it comes to DNS leaks, the goal isn't getting every result to show the same region — it's confirming that domain queries follow the configuration you intended.
Efficiently solve multi-account management, environment isolation, and account security