IP Judge ipjudge.org
Muse Claude

Guides ·

DNS leaks: why your lookups still go to your local ISP behind a proxy

Before a browser can open a site, a DNS resolver has to turn the domain name into an IP address. That lookup is a separate step from the connection: a proxy can carry your traffic without ever touching your DNS. When your exit is in one country but your lookups still go to your local ISP’s resolver, that is a DNS leak. What it mainly reveals is the network you are really on: whoever runs the resolver sees every domain you look up, and a site that runs a test like ours sees where the resolver is. Whether ChatGPT, Claude or other platforms look at this is not publicly documented.

At a glance: exit abroad, DNS at homePage connections go through the proxy to an exit abroad. DNS lookups don’t necessarily follow the proxy and still go to your ISP’s resolver, which sees the names you look up, while sites see where that resolver is. At a glance: exit abroad, DNS at home Page connections Proxied Browser Proxy app Exit abroad Sites see your proxy exit DNS lookups (name → IP) Leak Device Skips proxy ISP resolver Your ISP sees the names; sites see where it is Fix: put DNS on the same side as your exit.
A proxy can carry your traffic without touching your DNS. An exit in one country and a resolver in another is an inconsistency.

How a lookup travels

A lookup normally has two legs. Your device sends the name to a resolver — the one your ISP or router hands out, or a public one you configured — and the resolver asks the domain’s authoritative DNS server. As RFC 7871 puts it, most queries reach authoritative servers through recursive resolvers, so the authoritative server sees the resolver’s address, not yours.

Classic DNS is unencrypted. Mozilla’s DNS over HTTPS article notes that this makes it easy for third parties to see which site you are about to visit.

Who sees what

  • The resolver operator sees every name you look up. If that is your home ISP, your ISP knows what you visit, whatever your exit is.
  • Networks on the path can read plain DNS and may tamper with it. Keeping on-path devices from interfering with DNS is one of the two use cases RFC 8484 (DNS over HTTPS, or DoH) was designed for.
  • A site’s own authoritative DNS sees your resolver’s IP, and from that its country and network. Leak tests work this way; any site that watches queries for its own domain could do the same.
  • With EDNS Client Subnet (ECS), some resolvers pass part of your IP on to the authoritative server. Section 11.1 of RFC 7871 says your network address then becomes visible to every server involved in the resolution and to any network the DNS packets cross. It recommends truncating to 24 bits for IPv4 and 56 bits for IPv6, so what leaks is your address block rather than your exact IP.
The two legs of a DNS lookupLeg one: your device sends the name to a resolver; classic DNS is unencrypted, so networks on the path can read it, and the resolver operator sees every name. Leg two: the resolver asks the site’s authoritative DNS, which sees the resolver’s IP, not yours; with ECS, part of your IP is passed on too. The two legs of a DNS lookup Your device Leg 1: device → resolver Unencrypted: the path can read it Resolver Sees every name you look up If it’s your ISP’s, your ISP knows Leg 2: resolver → site’s DNS ECS can pass on your address block Site’s DNS Sees the resolver’s IP Not yours: this is what tests see ECS: part of your IP goes along Suggested cut: 24 bits for IPv4, 56 for IPv6 DoH hides lookups from the path, not from the resolver.
The leak happens on leg one: whichever resolver gets the query sees your lookups, and sites learn where it is from leg two.

The AI platforms don’t publish their risk rules or say whether they check visitors’ resolvers. A DNS leak is not a guaranteed ban, but it is an inconsistency: an exit in one country, DNS answered from another.

How IP Judge detects it

The check runs on the home page and on the Claude, ChatGPT and Muse pages. The result is the “DNS resolver” row under “Browser and connection checks”.

  1. The page generates a random 12-character string and loads four subdomains no one has ever looked up: random-1.t.ipjudge.org through random-4.t.ipjudge.org.
  2. No cache has these names, so your resolver has to ask the authoritative DNS for t.ipjudge.org — our own probe, on a separate IP and not behind a CDN. It records the address of every server that asks about your string, plus the ECS subnet when a query carries one.
  3. The page fetches that list and looks up each resolver’s country and network (ASN) in a local IP database, then compares it with the country of the exit you used to open ipjudge.org. Up to six resolvers are listed.

The verdicts:

  • Exit outside mainland China and at least one resolver inside it: Leaks to China.
  • Exit outside mainland China and an ECS subnet that geolocates there: also Leaks to China, because your real network was passed on to sites’ DNS servers.
  • Resolver in a different country from the exit, but neither case above: Different region, shown as information only.
  • Same country: No leak. No resolver recorded this time: Unknown; reload to test again.
How IP Judge rates DNSThe page loads fresh random subdomains, so your resolver has to ask our authoritative DNS probe, which records it; its country is then compared with your exit’s. Exit outside mainland China with a resolver or ECS subnet inside it: Leaks to China. Any other country mismatch: Different region, information only. Same country: No leak. No resolver recorded: Unknown. How IP Judge rates DNS The test: new names every run Fresh names Our probe Country No cache has them, so resolvers must ask us Verdicts Leaks to China Exit outside mainland China,resolver or ECS subnet inside Different region Other mismatch; info only No leak Same country as the exit Unknown No resolver recorded; reload The probe keeps its records in memory for 10 minutes.
Only an exit outside mainland China with a resolver or ECS subnet inside it counts as “Leaks to China”; “Different region” costs no points.

In the Claude score, “DNS to China” costs 8 of the 20 points for leaks; the Muse score deducts 5. These are IP Judge’s weights based on common risk signals, not rules any platform has published. The full rules are on the Method page. The probe keeps the “random string → resolver” mapping in memory for 10 minutes and never writes it to disk.

Common causes

1. The proxy handles connections but not DNS. Lookups go wherever the operating system sends them, usually the router or the ISP’s resolver. TUN mode doesn’t always fix this. The TUN documentation of mihomo, an open-source proxy core, notes that on macOS and Windows it cannot automatically hijack DNS requests sent to the local network, and on Android it cannot when Private DNS is enabled.

2. Names are resolved locally before reaching the proxy. SOCKS5 lets a client hand the proxy a domain name instead of an IP (the DOMAINNAME address type in RFC 1928), but programs don’t always use it. The curl manual is a clear example: --socks5 (socks5://) resolves the hostname locally, while --socks5-hostname (socks5h://) lets the proxy resolve it.

3. IP-based routing rules trigger local lookups. A rule that routes by destination IP — a country’s IP ranges, for example — needs the domain’s IP first. mihomo’s rules documentation says matching such a rule triggers DNS resolution, and the no-resolve option skips it. The lookup goes to whatever DNS server the app is configured with; if that is a resolver back home, the query stays there.

4. Exceptions to fake-ip modes. In fake-ip mode, programs on your machine get placeholder addresses from the fake-ip-range instead of real ones (mihomo’s DNS documentation uses 198.18.0.1/16 in its example). Domains listed in fake-ip-filter don’t get placeholders and have to be resolved for real. Whether the DNS servers themselves are reached through the proxy is a separate setting: in the same docs, respect-rules makes DNS connections follow the routing rules and requires proxy-server-nameserver to be set.

5. The browser’s own secure DNS. According to Chrome Help, secure DNS is on by default in automatic mode, and if a lookup has problems Chrome falls back to unencrypted mode. The DnsOverHttpsMode policy adds that, when the policy is unset on an unmanaged device, the browser may send DoH queries to a resolver associated with your configured system resolver — so an ISP resolver can become the same ISP’s encrypted resolver. Firefox’s Default Protection falls back to the default resolver when there are problems, and disables DoH when a VPN, parental controls or enterprise policies are active. DoH also normally runs over HTTPS on port 443, so a DNS takeover that only catches port 53 won’t see it.

6. IPv6 DNS servers. On IPv6 networks, routers can hand out DNS server addresses directly in Router Advertisements (RFC 8106). If you only changed the IPv4 DNS, or your proxy only captures IPv4, lookups may still reach your ISP’s resolver over IPv6.

How to fix it

Put DNS on the same side as your exit: either hand domain names to the proxy and let the far end resolve them, or send the connection to your resolver through the proxy too. Option names differ between apps; the principles don’t.

  1. In your proxy app, look for settings along the lines of remote DNS or taking over DNS. In TUN mode, turn on DNS hijacking and keep the platform limits above in mind.
  2. Check whether IP-based rules are causing local lookups, which DNS servers the app is configured with, and whether those connections go through the proxy.
  3. Pick one approach for the browser’s secure DNS: leave DNS to the proxy, or choose a custom provider and make sure that encrypted connection itself goes through the proxy. In Chrome it is under Settings > Privacy and security > Security > Advanced > Use secure DNS; Chrome Help notes that with a custom provider it won’t fall back to unencrypted mode. In Firefox, open Settings, click Privacy and security and scroll to the DNS over HTTPS section.
  4. On dual-stack networks, make sure the proxy also captures IPv6, or change the IPv6 DNS settings too.
  5. For command-line tools that support SOCKS5, such as curl, use the socks5h:// form so the proxy does the resolving.
  6. Test again on the home page. Every run uses fresh random subdomains, so an earlier result can’t be served from cache.

WebRTC can also hand a page a different IP; see WebRTC leaks.

FAQ

Is “Different region” a leak?

IP Judge doesn’t count it as one and doesn’t deduct points for it. When your resolver is far from your exit, sites that tailor answers to where a query comes from, such as CDNs, may send you to servers far from your exit. The introduction of RFC 7871 describes exactly this problem.

If I turn on secure DNS in the browser, am I covered?

Not necessarily. Encryption stops networks on the path from reading or altering lookups, but the resolver operator still sees them; Mozilla says its DoH partners can see users’ queries. Automatic modes can also stay with your system resolver’s provider and fall back to plain DNS. Go by the test result, not the setting.

Why is the resolver IP on the page different from the DNS address I set?

The probe records the address of the server that actually asked. What you configured may be your router, your proxy app or a public resolver’s service address, and those forward to upstream servers or send queries out from other machines. Look at the country and network, not the exact IP.

Will ChatGPT or Claude ban me for a DNS leak?

There is no public information that answers this. What a platform sees most clearly is the exit IP you connect from; see which IP ChatGPT and Claude actually see. The more direct cost of a DNS leak is that your home ISP can see the domains you visit. Fixing it keeps your network signals consistent and exposes less.

Which kind of IP do you have?

Check my IP for free