What is a DNS or WebRTC leak?

Think of DNS as the phone book of the internet. Every time you type a web address, your device cannot use the name on its own. It has to turn that name into a number, an IP address, and to do that it asks a DNS resolver. On most networks the resolver belongs to whoever runs the network. That is your ISP at home, or the IT team at work.

So the little request that says “where is example.com?” travels to a machine you do not control, and it carries the name of the site you are about to open. A DNS leak is when that lookup escapes whatever protection you thought was covering you. You might be using something that encrypts the traffic itself, but if the hostname lookup still goes out to the network’s own resolver, the network still learns the name of every site you reach.

The important thing to notice is what leaks. A DNS leak does not reveal what you sent or read. It reveals where you were going, which for a lot of people is the sensitive part.

WebRTC is a set of features built into every modern browser so that video calls, voice chat, and some direct file sharing can work without a separate app. To connect 2 people to each other, WebRTC first has to figure out the addresses each side can be reached at. It gathers candidate addresses, including your device’s local network address and, with the help of a server called a STUN server, your public IP.

The catch is that this address gathering can run straight from JavaScript on a page, and it can reach out along its own path rather than the one the rest of your tools are using. So a page can quietly ask the browser “what is this visitor’s real IP?” and get an answer back, even when the main connection looks locked down.

That is a WebRTC leak. It can hand a web page your real IP address through a feature you never chose to turn on, which is exactly why it has caught out people who assumed a single tool had them covered.

Put them side by side. A DNS leak tells the network the names of the places you visit. A WebRTC leak tells a website the number that identifies your connection. If you are on a device or network someone else controls, that pairing is the whole game.

The reason you reach for a proxy or a privacy tool in the first place is to keep one of those 2 facts to yourself. A leak in either channel undoes that effort with no signal at all. Nothing looks broken. The page still loads. You simply handed over more than you meant to.

• DNS leak: what leaks is the site name, who sees it is the network (your ISP or the local resolver), and you catch it with a DNS leak test.
• WebRTC leak: what leaks is your real IP address, who sees it is the web page you are visiting, and you catch it with a WebRTC leak test.

This is where a rewriting web proxy earns its place, and where it pays to be precise about what it does and does not do.

When you open a site through TrickyBird, you are really loading TrickyBird’s own address. The target’s address is encoded inside the path, so your browser only ever talks to TrickyBird. The lookup for the site you actually want happens on our side, not on your device. In plain terms, the target’s hostname stays out of the DNS queries your browser sends to the network around you. So if you are asking does a web proxy hide my IP and keep my destinations off the local resolver, that is the job this scheme does. It is the same zero domain leakage that keeps the target’s name out of the URL bar and off the page you see (see which sites currently render cleanly on /status). There is no download and no app, which is what matters when the block is on a device that will not let you install anything.

There is one honest limit worth stating plainly. The gateway itself still has to resolve and connect to the target in order to fetch it, so that leg is not hidden. We keep a deliberately small record of it: a shortened IP address cut to a /24 or /48 so it points at a neighborhood rather than a single house, plus the destination hostname and basic response details, for at most 48 hours. Full retention and deletion detail is on /security. That is verifiable minimal short-lived logging, and the point is that you can check it instead of taking our word for it. That is a very different posture from an absolute promise you have no way to check. See how the policies compare.

No, and it is worth being clear about this one. TrickyBird rewrites the pages it serves, but it does not intercept WebRTC. WebRTC runs as a separate browser subsystem on its own network path, so a page you open through the proxy can still reach a STUN server directly and get your real IP back, even while the rest of that page loads through TrickyBird.

So treat WebRTC as something you switch off yourself, not something the proxy handles for you. Turn it off in your browser using the steps below, then run a WebRTC leak test on the exact device and network you care about to confirm your real IP no longer shows. It is worth checking yourself rather than trusting any claim, this one included.

You do not have to rely on any single tool. WebRTC can be turned down at the browser level too, and it is worth knowing how. In Firefox you can open about:config and set media.peerconnection.enabled to false, which switches the feature off. Chrome does not expose a native toggle, so people usually reach for a well-reviewed extension that blocks WebRTC, though on a managed device you may not be allowed to add one.

On mobile the picture differs by platform. iOS Safari is more restrictive about what WebRTC will hand a page, while Android Chrome behaves much like the desktop. So if you are asking whether iOS leaks over WebRTC, it can, just less freely than a desktop browser does.

DNS has its own browser-level option worth mentioning. DNS over HTTPS, or DoH, sends your lookups to a resolver over an encrypted channel instead of the network’s default one, which is where many people start when they first read about DNS leaks. None of these replaces testing. They are levers to try, and then verify.

You do not have to trust a marketing line, and you should not have to. A leak test takes about a minute. Open a DNS and WebRTC leak test page, a neutral checker such as browserleaks.com or ipleak.net, and it will show you which resolvers your lookups are reaching and which public IP a page can see for you, WebRTC included.

Do it once on the network you actually care about. If the resolver listed is your ISP’s or the local network’s, your DNS is leaking. If the public IP shown is your own address, WebRTC or the connection is exposing it. Turn your tool on and run the same check again to see whether the numbers change.

TrickyBird’s /proof page checks something different, and it is worth keeping them separate. It shows that the address of the site you open never appears in your URL bar, in the page source, or in the Referer and Origin headers your browser sends. That is a domain-leak check, not a DNS or WebRTC one, and it does not display an IP or tell you whether WebRTC is exposing yours. For that, run one of the leak-test pages above and disable WebRTC in your browser. A tool worth using is one that survives someone opening the developer tools and looking. That is the same standard worth applying to any free web proxy, ours included.

Keep reading if you want the ground underneath this one.

• What is a web proxy?
• Web proxy vs VPN
• Is using a proxy legal?
• Unblock a site
• Our logging and security policy