DNS and IP Leaks: What They Are and How to Check for Them
You've turned on the tunnel, the indicator glows green — and the test still shows your ISP and city. That's how DNS, IP and WebRTC leaks show up: the channel is encrypted, but individual requests slip out directly and give you away.
A tunnel encrypts whatever travels inside it, but it doesn't by itself guarantee that all your traffic ends up there. Some requests can slip out directly, bypassing the protected channel — and it's exactly those that give you away: your ISP, your city, and sometimes your real IP address. Below are the three most common gaps and a way to check each one in five minutes.
Three types of leaks in simple terms
Before checking anything, it helps to know what you're actually looking for. Leaks come in three types, and the mechanisms differ:
- DNS leak. Every time you open a site, your device asks a DNS server which IP corresponds to the domain name. If that request goes to your internet provider's server instead of through the tunnel, the provider sees the list of sites you visit — even if the traffic itself is encrypted.
- IP leak. A site or service detects your real address instead of the VPN server's address. Your IP makes it easy to work out your provider and approximate location.
- WebRTC leak. The video-calling technology built into browsers can learn your local and public IP addresses directly, bypassing proxy and tunnel settings.
Why DNS gives you away most often
DNS is the internet's address book: it translates readable names like example.com into numeric IPs. The problem is that classic DNS requests go out as plain text and are often directed to a server set in the network settings or assigned by the provider. Even with an active tunnel, the system may out of habit ask its "own" DNS — and then the list of your domains is visible on the network side.
The protocol-level fix is to encrypt the DNS requests themselves. The RFC 8484 standard describes DNS over HTTPS (DoH): the request is wrapped inside a regular HTTPS connection, so it's indistinguishable from other web traffic and protected against tampering. According to Cloudflare's documentation, such a request travels over port 443 — the same one regular sites use — making it hard to single out in the overall flow. We covered what encryption gives you in general in our piece on the basics of encryption, and how switching DNS differs from a VPN in the first place in VPN, proxy and DNS: what's the difference.
IP leaks and the trickiness of WebRTC
A "regular" IP leak is straightforward: if a site sees the VPN server's address instead of yours, all is well. WebRTC behaves in a much trickier way. It's a browser technology for calls and direct file transfer between devices; to establish a direct connection, it needs to know the real addresses of both parties.
To do this, WebRTC contacts so-called STUN servers. As MDN's WebRTC documentation explains, a STUN server returns a "server reflexive" candidate — essentially your public IP address as seen from outside your home network. The browser receives this address and can hand it to the web page via JavaScript, even if all other traffic goes through the tunnel. That's why a test sometimes shows two addresses at once: the "correct" one from the VPN, and the real one from WebRTC.
How to check yourself in five minutes
This is a deeper check than the basic one — if you haven't yet confirmed the tunnel is connected at all, start with how to check that your VPN is working. From there, specifically about leaks:
- Find out your address without the tunnel. Turn off the VPN, open any "my IP" service, and note the address and provider — this is your baseline.
- Turn on the tunnel and refresh the page. The IP should change to the VPN server's address and country. If it stays the same — that's an IP leak.
- Check DNS. Open a DNS leak test site. Your home provider's name shouldn't appear in the list of servers.
- Check WebRTC. Find an online WebRTC leak test. If it shows your public IP from step one — there's a leak.
- Repeat on a different network. This is especially important in cafés and airports — we covered the risks of open Wi-Fi in public network security.
What to do, and how a correctly built tunnel helps
A good client closes these gaps on its own, without requiring manual settings from you. What to look at:
- DNS inside the tunnel. All DNS requests should go through the same encrypted channel to the VPN's DNS server, not the provider's.
- Kill switch. If the connection drops, traffic shouldn't leak out directly until the channel is restored.
- WebRTC control. In a browser, the leak is closed with a setting or extension that blocks pages from requesting local addresses.
HamikVPN encrypts traffic in full and wraps DNS requests in the same protected channel, so site names don't leak to outside DNS servers and your real IP stays hidden from the resources you visit. If tests still consistently show leaks with the client turned on, that's a red flag — we covered what else to watch for in signs of an unreliable VPN.