DNS leaks, open ports and TLS fingerprints

A circumvention tool wraps your HTTP traffic in an encrypted tunnel, and that is the part everyone watches. But before you can connect to a site there is an earlier step, turning a name into an address, and it often happens outside the tunnel. Just as easy to forget: what doors your own machine has open to the internet, and whether the encrypted handshake itself talks too much. This site checks all three: ports from the IP page, DNS and TLS from their own pages in the fingerprint lab. The latter two depend on a separate deployment, so on some installs they show "not configured" instead of a result; the mechanics below tell you what to look for either way.

How a DNS leak happens

To reach example.com, the browser first asks the system resolver which IP that name maps to. With a proxy in place, that question should be answered by a resolver on the far end of the tunnel. A leak means it wasn't. The question went straight to your local ISP's DNS instead.

There are several ways this goes wrong. The most common one is that the tool intercepts TCP connections while the system keeps sending UDP port 53 queries to the ISP out of habit. Windows adds a twist of its own with parallel resolution: every network interface gets asked at once and the first answer wins, so if the tunnel is a little slower it loses. IPv6 is another classic hole. The tool proxies IPv4 only, while IPv6 lookups and connections go through the ISP untouched. And some ISPs run transparent hijacking, intercepting all port-53 traffic at the gateway and answering it themselves regardless of what you configured.

The consequences come in two layers. The first is privacy. Content is encrypted, but the ISP and whoever sits behind it know every domain you looked up, and that list alone says plenty. The second layer bites harder in China. A poisoned DNS answer hands you a wrong IP; the tool's log says "connected," but the connection went to an address that leads nowhere, and the page never loads. A large share of "why doesn't this work even though the proxy is on" questions trace back here.

How the check works

The detection trick is neat. The test site controls the authoritative DNS server for some domain. When the page loads it generates a one-off subdomain, say k3f9a2.dnsleak.example, and asks the browser to fetch it. Nothing has ever cached that name, so the lookup must travel all the way to the authoritative server. The server logs who asked, and the resolver that asked is your DNS exit. If it belongs to your ISP, you're leaking; if it belongs to your VPN provider or a public resolver, you're not.

That is exactly what the DNS leak page in the fingerprint lab does. Your browser resolves six one-off hostnames under a zone this site is authoritative for, our DNS server records which resolver asked for each one, and the page lists those resolvers with their ASN and country and calls it a leak when any of them sits in a different country from your exit IP. The one prerequisite is a DNS zone delegated to the site, which is a separate deployment from the web app. On an install where that zone isn't set, the page says "not configured" rather than guessing.

Whatever it says, it's worth cross-checking with an outside service: ipleak.net, dnsleaktest.com, or browserscan's dns-leak page. Two things to check in any result. The listed resolvers should not belong to your local ISP, and ideally resolver and exit IP sit in the same country. A Hong Kong exit paired with a Beijing China Telecom resolver is the textbook leak.

Plugging it

At the tool level, most modern clients offer "remote DNS" or something similar: the fake-ip mode in Clash-family clients, the DNS routing rules in sing-box. The idea is the same in both: either send name resolution through the tunnel too, or return a placeholder IP locally and defer the real lookup to the exit side. Turn it on and the leak mostly stops.

At the system level, you can switch to DoH (DNS over HTTPS) so the queries themselves are encrypted and the ISP can neither read nor poison them. DoH endpoints are blocked on some networks, though, so expect some trial and error. IPv6 should either be disabled or explicitly handled by the tool; don't let it be the path that slips through. One more common trap is "browser-only proxy" mode, where the browser uses the tunnel but nothing else on the system does, DNS included.

Why ports 22 and 3389 are worth a look

The IP page on this site makes one outbound connection from our server to your public IP on port 22 (SSH) and 3389 (RDP), with a two-second timeout, and reports open, closed or filtered. We picked those two because their meaning is the least ambiguous.

Seen from outside, a home network should have both closed or dropped by a firewall. If one shows open, it usually means one of two things: you're running a browser on a cloud server or VPS (remote-desktopping into it, for example), or your home router has port forwarding set up. The first is more common than you might think; plenty of people run a desktop inside an overseas VPS precisely to get a "clean" IP.

The trouble is how risk engines read it. browserscan's view is that a "user IP" with 3389 open tells the platform this is a remotely operated machine rather than a person's computer, and some platforms do treat it as evidence of a farm or an automation setup, then restrict or ban. We're not judging whether that's fair; we're pointing out that the signal is real.

Also worth knowing: if you're behind CGNAT (mobile data, some broadband), we're connecting to the carrier's gateway, not your device, and the result means nothing.

TLS fingerprints: the handshake gives you away

Finally, the check that matters more every year. When a browser opens an HTTPS connection, the first packet is the ClientHello, listing the TLS versions the client supports, the cipher suites in order of preference, the extensions and their order, the supported elliptic curves and point formats. For any given client this combination is quite fixed. Chrome has its ordering, Firefox has another, Python's requests library looks different again. Concatenate those fields, hash them with MD5, and you get a JA3 fingerprint. JA4 is the newer format, more structured and more resistant to randomisation. HTTP/2 has an analogue: the values in the SETTINGS frame, WINDOW_UPDATE, and the order of pseudo-header fields, which Akamai formalised into an h2 fingerprint.

The use is direct. A request whose User-Agent says Chrome but whose TLS handshake looks like Go's standard library is almost certainly a script. It's one of the most reliable ways to see through a spoofed UA, and anti-bot and fraud systems lean on it heavily.

For circumvention users the relevance is this: some proxies and relays terminate TLS in the middle and start a fresh handshake, so the server sees their fingerprint, not your browser's. Some tools deliberately mimic Chrome's fingerprint to evade blocking. To see any of this, a server has to terminate TLS itself; behind a CDN edge it only ever sees the CDN's handshake. So the TLS page on this site makes one cross-origin request to a separate, DNS-only hostname where the handshake terminates, and reports JA3, JA4 and the HTTP/2 fingerprint, plus whether that JA4 is one we normally see from the browser family your User-Agent claims. When that endpoint isn't deployed or can't be reached from your network, the page falls back to the third-party check.ja3.zone, which gives JA3 only and no comparison.

FAQ

If the proxy is on, does DNS automatically go through it? Not necessarily; it depends on the tool's configuration. Under default settings many clients proxy connections but not lookups. One run on the test sites above settles it.

What does "filtered" mean for a port? No response at all within two seconds, usually because a firewall dropped the packet. For a home network that's normal, even preferable.

Why does the DNS or TLS page say "not configured"? Both checks need something outside the web app: a DNS zone delegated to the site for one, a hostname that terminates TLS itself for the other. When a deployment hasn't set those up, the page says so rather than guessing; the TLS page still shows a JA3 from check.ja3.zone in the meantime.

Can JA3 be faked? Yes. Some libraries specifically imitate mainstream browser handshakes, which is part of why JA4 exists. But faking it consistently everywhere isn't easy, and it remains a useful signal.