DNS Leak Test: Do Your DNS Lookups Go Around Your Proxy?

Before your browser opens a site, a DNS resolver turns the site's name into an IP address. The resolver sees every name you look up and the address that asked, or a subnet of it. With a proxy or VPN, those lookups should happen on the proxy or VPN side. A DNS leak is when they go to a resolver outside it, usually your internet provider's: the names of the sites you visit go to your provider, and your provider's network shows up next to an IP that is supposed to replace it.

For a site, a resolver in another country than your IP, or a home ISP's resolver next to a datacenter IP, is a sign that the traffic is relayed. Any page can run a lookup like this test does, without asking, so a leak shows up on more sites than leak test pages.

The page has your browser look up 6 random names under a ProxyField test domain. Each name is new, so no cache holds the answer: the lookup has to travel from your device, or from the proxy side, to a recursive resolver, and from that resolver to ProxyField's DNS server, the authoritative server for the test domain. That server records which resolver asked and, when the resolver includes one, the client subnet. The page then shows each resolver with its ISP, ASN and country from the DB-IP Lite databases, next to the IP the page itself loaded from.

Several lookups show more of your setup: one resolver service often answers from several outgoing addresses, and your system may ask more than one configured server. The IP checker runs a quick version with 2 lookups as one of its 10 checks.

• HTTP and HTTPS proxies. The browser sends the site's name to the proxy, and the proxy side resolves it. Your own resolver is not asked about the pages you load through the proxy, so the test shows the proxy side's resolvers.
• SOCKS5. Either side can resolve. With remote DNS, your client sends the name and the proxy resolves it; with local DNS, your device looks the name up first and sends only the IP, and the lookup leaks. In Firefox, tick "Proxy DNS when using SOCKS v5". In scripts, use socks5h:// instead of socks5://, or --socks5-hostname in curl.
• Lookups outside page loads. Chromium's notes on SOCKS proxies warn that parts of the browser other than page loads, such as DNS prefetching, can still resolve names locally. The test shows whether that happens in your setup.
• VPN. The VPN app must send DNS through the tunnel, to its own resolver or to another one reached through it. Leaks happen when the system keeps the router's or the provider's resolver, when IPv6 lookups go outside the tunnel, or when Windows sends a lookup over every network adapter at once (smart multi-homed name resolution) and the VPN app does not stop it.
• Secure DNS (DNS over HTTPS). The browser sends lookups encrypted to the provider you chose, such as Cloudflare or Google. Your internet provider can no longer read or redirect them, but the DNS provider sees them, and without a VPN or proxy it sees your real IP. With a VPN, they go through the tunnel like everything else.

Large public resolvers answer from many locations at once (anycast), and the outgoing address this test sees usually belongs to the location nearest to whoever sent the lookup. That makes it a location signal: Google's resolver in Germany next to a US proxy IP means the lookup started in Germany, on your side. The same resolver in the US suggests the proxy side made it.

So a public resolver is not a leak by itself: what counts is where it answered from and whether the lookup started on your side. That is also why the verdict says Possible DNS leak: a proxy service's own resolver can sit in another country than its exit IP. Compare with your run without the proxy: if none of those resolvers remain, your own lookups are not leaking.

Some resolvers, such as Google Public DNS, can pass a shortened client subnet to the DNS server, which shows the network the lookup came from; Cloudflare's 1.1.1.1 does not send one. And your provider's resolver can show up even when you set another one: some providers catch all DNS traffic on port 53 and answer it themselves (a transparent DNS proxy). Secure DNS in the browser, or DNS through a VPN, avoids that.

The setting names below are the ones the apps show; labels can differ slightly between versions.

In the browser

• Chrome: Settings, Privacy and security, Security, Use secure DNS.
• Edge: Settings, Privacy, search, and services, Security, Use secure DNS.
• Firefox: Settings, Privacy & Security, DNS over HTTPS.
• Brave: Settings, Privacy and security, Security, Use secure DNS.

Choose a named provider rather than your current service provider, so lookups stop going to your internet provider's resolver. Safari follows the system's DNS settings.

With SOCKS5 and in scripts

Let the proxy resolve names. In Firefox, tick "Proxy DNS when using SOCKS v5". In curl and Python, use socks5h://; ProxyField's examples use it so the gateway resolves the site's name:

curl -x socks5h://gate.proxyfield.io:7000 -U "<login>-country-us:<password>" https://api.ipify.org

In Python, run pip install "requests[socks]" and pass socks5h://<login>-country-us:<password>@gate.proxyfield.io:7000 as the proxy. HTTP proxies resolve on the proxy side in every client.

With a VPN

Turn on the app's DNS leak protection, or its own DNS, so lookups go through the tunnel. Turn off split tunneling for the browser, and if the app does not tunnel IPv6, turn IPv6 off for the network adapter.

In the operating system and the router

• Windows: the adapter's DNS servers are in Settings, Network & internet, under the connection's properties; a VPN app with leak protection also stops lookups on other adapters.
• macOS: System Settings, Network, your connection, Details, DNS.
• Router: a router hands its resolver to every device on the network, usually the provider's; change it there, or rely on Secure DNS or a VPN on each device.

In antidetect browsers

Set the proxy type your provider gives (HTTP or SOCKS5) in the profile, and the profile resolves names through the proxy. If this test inside the profile still shows your provider's resolvers, check the proxy type and any DNS option the app has. Setup for each app: antidetect browsers.

A resolver tells a site three things: the country it answers from, the network that runs it and, with a client subnet, the network the lookup came from. Anti-fraud systems can compare all three with your IP. A home ISP's resolver in one country next to a proxy IP in another reads as relayed traffic, a company or school resolver ties the session to that network, and your own provider's subnet next to a datacenter IP ties the proxy session to you. None of this needs a permission prompt, and it works the same in every browser.

• Number of lookups. A test with 1 lookup can miss a second resolver your system uses; longer tests catch more.
• Outgoing addresses. Large resolvers answer from many addresses, so two runs can show two IPs of the same service.
• IP data. Each test looks resolvers up in its own database, so the ISP name or the country can differ.
• Caches and blockers. A test that reuses names gets cached answers, and a content blocker can stop the lookups entirely.
• What is compared. Some tests list resolvers without comparing them with the IP they see, and that comparison is what turns a list into a verdict.