The first time this bit me, the proxy was "working" perfectly. The site showed the proxy's IP. Everything looked clean. And the account still got flagged within a day.

The reason took me embarrassingly long to find: the browser was quietly handing out my real IP over WebRTC, completely around the proxy. The HTTP traffic went through the tunnel like it should. A little JavaScript API didn't care that the tunnel existed.

That's the thing about leaks — your proxy can be doing its job and you can still be exposed. So before you trust a setup, test it.

The four places a proxy leaks

1. WebRTC. This is the big one. WebRTC is the browser tech behind video calls, and to set up a peer connection it asks a STUN server "what's my public IP?" — using the real network interface, not your proxy. If a site runs that same query in the background, it sees the IP your proxy was supposed to hide. The fix is to disable WebRTC (or force it through the proxy) in whatever browser or automation profile you're running.

2. DNS. You can route HTTP through a SOCKS5 proxy and still resolve domain names using your own ISP's DNS resolver. Now your ISP — and anyone watching — knows every host you visited, even though the connections themselves went through the proxy. Using socks5h:// instead of socks5:// keeps DNS resolution on the proxy side, which is a one-character fix that a lot of people miss.

3. Timezone and locale. Your exit IP says you're in Chicago. Your browser says Europe/Warsaw and your Accept-Language is pl-PL. A fingerprinting script notices that contradiction instantly, and a mismatch like that is more suspicious than a plain datacenter IP, because it looks like someone actively hiding.

4. Proxy-tell headers. Cheap or misconfigured proxies add headers like Via or X-Forwarded-For that announce "a proxy touched this request." A good proxy is transparent to the destination — the request should look like it came straight from the exit.

Actually testing it

Turn your proxy on, then run a proxy leak test. It compares the IP a site actually sees against what your browser leaks through WebRTC and reports the timezone and header mismatches in one pass. The number you care about: does the WebRTC check surface a different public IP than your exit? If it does, that's your real one, and you're leaking.

While you're at it, confirm what category your exit IP is with what-is-my-IP — a leak-free setup on a flagged datacenter IP still gets blocked, just for a different reason.

Closing the holes

• Disable WebRTC in the browser (media.peerconnection.enabled in Firefox, an extension or a launch flag in Chromium) or in your Playwright/Puppeteer profile.
• Switch your proxy URL to socks5h:// so DNS resolves remotely. The proxy code generator spits out the correct syntax for curl, Python, Node and the rest if you're not sure.
• Set the browser timezone and locale to match the exit's country. Headless frameworks let you override both.
• Use a proxy that doesn't add tell-tale headers in the first place. Real carrier mobile proxies present a single genuine IP with nothing bolted on.

None of this is exotic. It's a ten-minute checklist. But it's the difference between a proxy that looks private and one that actually is — and you only find out which you have by testing before it matters, not after the ban.