Direct Answer
To check if your proxy is leaking, run three tests: confirm your exit IP, ASN and geolocation read as the German mobile network you expect; run a WebRTC leak test to be sure the browser doesn't reveal your real public IP; and run a DNS leak test to confirm lookups don't fall back to your own resolver. If all three match, your setup is clean.
Why You Should Test Your Own Proxy Setup
A proxy only does its job if every part of your connection actually travels through it. In practice, three things can quietly go wrong: your traffic uses the proxy but your browser exposes your real IP through WebRTC; your DNS lookups skip the proxy and resolve through your own ISP; or the exit IP simply isn't the network type or location you paid for.
These are configuration leaks, not provider failures, and they are invisible until you look for them. The fix is a short, repeatable self-check you run once after setup and again whenever you change tools, browsers or rotation settings. The goal is simple: verify your own setup matches what you expect before you build a workflow on top of it.
This guide walks through all three checks in order. None of them require special software — a browser, a terminal, and a couple of public test pages are enough.
The 3 Leak Types at a Glance
| Leak type | What it exposes | Where it happens | How you test it |
|---|---|---|---|
| IP / ASN / geo mismatch | Wrong exit IP, network type or country | Proxy not applied, or wrong endpoint | Load an IP-info page through the proxy |
| WebRTC leak | Your real public IP via the browser | Browser WebRTC stack bypasses the proxy | A WebRTC test page in the same browser |
| DNS leak | Which resolver answers your lookups | DNS sent outside the proxy tunnel | A DNS leak test page through the proxy |
All three are independent. A connection can pass the IP check and still leak through WebRTC or DNS, which is exactly why you run all three rather than just one. For the mechanics behind the last two, see our explainers on what a WebRTC leak is and what a DNS leak is.
Step 1 — Check Your Exit IP, ASN and Geolocation
The first check answers the basic question: when a website looks at your connection, what does it see? Send a request through your proxy to a public IP-information page and read four things:
- The IP address. It must be the proxy's exit IP, not your own. If you still see your home or office IP, the proxy isn't being applied at all.
- The ASN and network type. Every IP belongs to an Autonomous System. A real German mobile IP reports a mobile carrier ASN, not a datacenter or hosting range. This is the single most telling signal — see what IP reputation is for why the network type matters more than the IP itself.
- The country and region. A German mobile proxy should geolocate to Germany. Small city-level inaccuracy is normal on mobile networks because of CGNAT — many subscribers share one public IPv4, so the registered location is approximate by design.
- Consistency across pages. Different IP databases can disagree. Check two or three independent pages; the ASN and country should be stable even if the precise city varies.
A quick command-line version of the same check, using a placeholder endpoint:
# Replace with your real host, port and credentials
curl -x "http://USER:PASS@PROXY_HOST:PORT" https://api.ipify.org
# Then read full details (ASN, org, country):
curl -x "http://USER:PASS@PROXY_HOST:PORT" "https://ipinfo.io/json"
If the returned IP, org/ASN and country match a German mobile network, Step 1 passes. For SOCKS5 instead of HTTP, swap the scheme to socks5h:// (the h makes the proxy resolve DNS — relevant for Step 3). See the difference between HTTP and SOCKS5 for when to use which.
Step 2 — Run a WebRTC Leak Test
WebRTC is the browser feature behind real-time audio and video calls. To set up a direct peer connection, it discovers your network addresses — and it does this outside your normal proxy path. Modern browsers already hide your local network IP behind a random .local hostname (mDNS), so the address that actually matters is your real public IP: WebRTC learns it from a STUN server over UDP, which sidesteps the proxy entirely. A proxy that handles HTTP traffic perfectly can still leak that public IP through WebRTC, because the request never goes through the proxy in the first place.
To test it:
- Configure the proxy in the same browser or browser profile you'll actually use.
- Open a WebRTC leak test page (any reputable one reports the IPs WebRTC reveals). Our own WebRTC leak test page explains exactly what to look for.
- Read the detected IPs. If you see your real public IP — the one from before you connected — WebRTC is leaking.
What a clean result looks like depends on your tooling. Browser-level proxying (or an OpenVPN profile that routes the whole device) should show only the proxy's IP or no public IP at all. If you route a scraper at the request level instead of the browser, WebRTC isn't even in play — there is no browser making peer connections. This is one reason request-based Python setups and headless browser scraping are simpler to keep leak-free than a full desktop browser.
If your browser does leak, the standard fixes are disabling or restricting WebRTC in the browser's settings, using a dedicated profile, or routing the entire device through the proxy so there's no path around it.
Step 3 — Run a DNS Leak Test
DNS is the lookup that turns a domain name into an IP address. A DNS leak happens when those lookups travel outside the proxy tunnel — typically straight to your own ISP's resolver — even though the rest of your traffic uses the proxy. The page loads through the German mobile IP, but the lookup that found it came from your real network. That mismatch is a tell.
To test it:
- Connect through the proxy.
- Open a DNS leak test page, which triggers lookups to several test domains and reports which resolvers answered. Our DNS leak explainer covers how to read the result.
- Check the resolvers and their locations. They should sit on the proxy's network path, not your own ISP. Seeing your home ISP's resolver means DNS is leaking.
The most common cause is a SOCKS5 setup that resolves names locally. Using socks5h:// instead of socks5:// tells the client to send DNS through the proxy, which closes the most frequent DNS leak in scraping tools. For device-wide routing, an OpenVPN profile that pushes DNS through the tunnel achieves the same thing.
Run all three checks in this order — IP, then WebRTC, then DNS — and you have a complete picture of whether your traffic, your browser and your lookups all agree.
A Repeatable Verification Routine
Treat leak-checking as a habit, not a one-off. The four moments worth re-testing:
- After first setup, before any real work.
- After switching tools or browsers — a new browser profile can reintroduce a WebRTC leak.
- After changing rotation or sessions — confirm a sticky session holds the same exit IP for the duration of a task, and that on-demand rotation actually changes it.
- When results look off — an unexpected block or a wrong-country response is often a quiet leak, not a dead proxy.
For a guided, copy-paste version of this whole routine against a live connection, use our proxy setup checks guide. If you're choosing a provider in the first place, how to choose a mobile proxy provider covers what to verify before you buy.
Why Mobile Proxies Make the IP Check Easy to Pass
The IP/ASN check in Step 1 is where proxy types differ most. Datacenter ranges are published and instantly identifiable as hosting, so the ASN gives them away. Real German mobile IPs report a mobile carrier ASN and, thanks to CGNAT, represent thousands of genuine subscribers on one shared address — which is why they read as ordinary consumer traffic. See mobile vs residential vs datacenter proxy and ISP vs mobile proxy for the full comparison.
That doesn't change how you test — the three checks are the same for any proxy — but it does change what "clean" looks like. With a real German mobile connection, a passing Step 1 means the exit reads as exactly what it is: a German mobile user. The remaining work is just making sure your browser (WebRTC) and your resolver (DNS) don't tell a different story.
FAQ
How do I know if my proxy is actually working?
Send a request through it to a public IP-information page and read the returned IP, ASN and country. If they match the proxy's exit — a German mobile network, in our case — rather than your own connection, the proxy is being applied. Then run a WebRTC and a DNS test to confirm nothing leaks around it.
Can a proxy pass the IP test but still leak?
Yes, and this is the most common mistake. The IP check only covers your main HTTP/S traffic. WebRTC can expose your real IP through the browser, and DNS lookups can resolve through your own ISP — both independently of whether the IP check passes. That's why you run all three tests, not just one.
What is a WebRTC leak in plain terms?
WebRTC is the browser feature behind video and voice calls. To connect peers directly, it can read your real public IP and reveal it outside your proxy path. If a leak test shows your real IP while you're connected through a proxy, that's a WebRTC leak. Our WebRTC leak explainer covers the fixes.
How do I fix a DNS leak?
For SOCKS5, use socks5h:// instead of socks5:// so the proxy resolves domain names instead of your local machine. For device-wide routing, use an OpenVPN profile that pushes DNS through the tunnel. After the change, re-run a DNS leak test to confirm the resolvers now sit on the proxy's path, not your ISP's.
How often should I check for leaks?
Test after first setup, after switching tools or browsers, after changing rotation or session settings, and any time results look unexpected. It takes a couple of minutes and catches configuration drift before it affects real work.
Does a clean leak test mean I'm anonymous?
No. A clean test means your setup behaves as configured — your exit IP, browser and DNS all agree. It is a correctness check on your own configuration, not a claim about anonymity. How a platform treats your traffic still depends on IP reputation and on using the connection within each platform's terms.
CTA
Want an exit IP that reads as a real German mobile user when you run these checks? GermanProxy.io's German 5G mobile proxies run on real CGNAT mobile connections (Blue and Red Premium Mobile Network), with HTTP, SOCKS5 and OpenVPN — browse the plans or see how to test your setup.
Get a German mobile proxy: Real 4G/5G IPs from Germany, fair-use 20 GB/day — compare German mobile proxy plans or start with a dedicated 5G proxy.