Proxy Leak Checklist: Verify Your IP, DNS, WebRTC and Timezone in 4 Layers

The lazy way to "verify" a proxy is opening an IP lookup site, seeing the right country, and moving on. Modern risk systems look much further — DNS egress, WebRTC, timezone and browser language. Any layer that disagrees with your exit IP gets flagged, and the signals compound. This post breaks the check into 4 layers, each with code you can run right now, and ends with the right troubleshooting order.

Layer 1: Exit IP — check the type before the location

The most damaging tag in IP databases is not the city. It is the ASN type: residential ISP, hosting/datacenter, or mobile.

curl -s ipinfo.io

Look at the org field. If you see AS14061 DigitalOcean or AS16509 Amazon, the IP is a datacenter IP no matter what the country says — real users don't browse from AWS. Plenty of "residential" proxies are just datacenter IPs resold with a better label, and the price premium only makes sense for genuine ISP-backed addresses. The risk-score difference between the two is covered in our residential vs datacenter IP breakdown.

Layer 2: DNS egress — the invisible leak

HTTP traffic goes through the proxy, but by default DNS resolution still happens locally — the OS asks your ISP's resolver. From the server side, a CDN can observe that the HTTP request comes from Frankfurt while the resolver that just looked up the domain sits in Shanghai. Providers like Cloudflare run global DNS infrastructure and see exactly this kind of mismatch.

# Which DNS servers am I using right now? (macOS)
scutil --dns | grep nameserver | head -5
# Linux: resolvectl status | grep "DNS Servers"

If you are behind a proxy but the resolvers above are your router or your ISP's, and the proxy is not doing remote resolution (HTTP proxies never do; SOCKS5 only when SOCKS5h-style remote resolution is enabled), you are leaking. The rule in one line: DNS egress country should match the HTTP exit IP country. Suspect a leak? Run the DNS diagnostics tool to compare both paths directly.

Layer 3: WebRTC — the browser sells you out

WebRTC is built for P2P media, so it discovers your real network address by talking directly to STUN servers — bypassing HTTP proxies entirely. A few lines of JS in any page will do it:

const pc = new RTCPeerConnection({
  iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
});
pc.createDataChannel('probe');
pc.onicecandidate = (e) => {
  if (e.candidate) console.log(e.candidate.candidate);
};
pc.createOffer().then(o => pc.setLocalDescription(o));

The IP inside the srflx (server-reflexive) candidate is your real public address as seen from outside the proxy. Modern Chrome obfuscates local addresses with mDNS, but the public address still gets exposed. Behind a proxy, the safe move is a WebRTC-blocking extension or a fingerprint browser that genuinely isolates it.

Layer 4: Timezone & language — device vs. IP cross-check

No network leak here — pure inconsistency detection:

Intl.DateTimeFormat().resolvedOptions().timeZone  // OS timezone
navigator.languages                                // browser languages
// Accept-Language: DevTools → Network → any request header

An IP in New York with timezone Asia/Shanghai and Accept-Language: zh-CN is a textbook proxy profile: the device configuration tells on the network. The OS timezone follows the machine, not the proxy — which makes it the hardest layer to fake and the favorite cross-signal of professional risk systems. We covered the mechanics in timezone & language mismatch detection.

One-shot check and troubleshooting order

Checking four layers manually is tedious, and the DNS and WebRTC layers need dedicated detection infrastructure. The disguise score on our homepage combines timezone, language, WebRTC and DNS-egress consistency into a 0–100 rating — below ~80 means something is leaking, and the breakdown shows what.

Work through the layers from biggest to smallest payoff:

1. ASN type — if the IP itself is datacenter-grade, stop tuning the rest (see our proxy protocol guide when buying)
2. DNS consistency — a proxy configuration issue; switch to remote resolution or change providers
3. WebRTC — a browser configuration issue; install an extension or switch browsers
4. Timezone/language — a device-level issue; solve with a fingerprint browser

For multi-account work: different accounts need more than different IPs. Timezone, language and font fingerprints must be consistent per identity, or accounts remain linkable regardless of IP rotation. For the full picture of how sites detect proxies, start with how proxy detection works.

Once the four layers pass, make the check a pre-flight routine rather than a one-time setup — proxy pool IPs rotate, and an IP that passed today may be burned by next week.