BrowserLeaks Proxy Test: Which Lines Matter and Fixes

BrowserLeaks is a set of separate privacy tests, not a single scanner, so it never gives you a pass or fail. With a proxy, five lines decide whether your setup holds: WebRTC, DNS, ISP and usage type, timezone, and IPv6. Canvas, WebGL, fonts and TLS hashes describe your browser, not the proxy, and get fixed in the browser profile.

What is BrowserLeaks, and why is there no score?

BrowserLeaks is a collection of test pages, including /ip, /proxy, /javascript, /webrtc, /canvas, /webgl, /fonts, /geo, /tls, /tcp, /http2, /client-hints, /dns and /quic. Each page prints raw values. None of them grades you.

Pixelscan works the other way: one page, one verdict. If you want the verdict first, the Pixelscan proxy guide covers how to read it. On BrowserLeaks you judge each line yourself, so you need to know which lines the proxy controls.

The /ip page is the summary. As of September 2026 it reports IP, hostname, location, ISP, Organization, Network (AS number), Usage Type, Timezone, Local Time, IPv6, WebRTC and DNS leak checks, a TCP/IP fingerprint, TLS and HTTP/2 fingerprints, request headers, Tor relay details and whois. Start there. Open the dedicated page for any line that looks wrong.

Which BrowserLeaks lines matter when you use a proxy?

Five lines matter, and you fix them in this order because each one can hide the next.

1. WebRTC shows your real IP

The /webrtc test asks a STUN server for your public address. If your home or office IP appears next to the proxy IP, any site can read the real one with a few lines of JavaScript.

Fix it in the browser. In an antidetect profile, set WebRTC to replace the address with the proxy IP. The label varies by browser ("altered", "replace", "fake"). In managed Chrome, the WebRtcIPHandling policy set to disable_non_proxied_udp stops WebRTC from using non-proxied routes. Confirm the fix with the WebRTC leak test.

2. DNS goes to your own resolver

The /dns test loads unique hostnames and lists the resolvers that looked them up. Through a proxy you want resolvers near the exit. If your home ISP's resolver appears, lookups are leaving your machine outside the proxy.

The usual cause is SOCKS5 with local resolution: socks5:// instead of socks5h:// in many clients, or "Proxy DNS when using SOCKS v5" unchecked in Firefox. A DNS-over-HTTPS resolver set in the browser shows up as that provider's servers, not the carrier's. Turn it off in the profile if you want lookups to match the exit. The longer version is in DNS leak: the silent proxy killer.

3. ISP, ASN and Usage Type read as hosting

The ISP, Network and Usage Type lines come from IP databases. On a mobile proxy they should name a mobile carrier and its ASN.

Every VoidMob exit is a real 4G/5G device on a consumer carrier connection. Its public IPv4 address sits behind the carrier's CGNAT and is shared with that carrier's ordinary subscribers, so these lines should read as the carrier. If Usage Type says hosting or data center, or ISP names a cloud company, first compare the /ip address with the exit IP your provider shows: a mismatch means the browser is not using the proxy you configured. Databases can misclassify a carrier range too. Work through mobile proxy shows as datacenter before touching anything else.

4. Timezone and local time do not match the IP

The /ip page shows the timezone and local time for the IP's location. Compare them with the time zone your browser reports. A London exit next to a browser clock set to New York is the classic mismatch.

Fix it in the profile. Set timezone, language and geolocation to follow the proxy IP. On a rotating US pool, one exit can sit in a different time zone from the next. Pin a region on the proxy list, or use a sticky session, so the profile and the exit stay matched. The location consistency test checks the pair in one pass.

5. IPv6 leaks

The IPv6 line checks whether your browser reaches BrowserLeaks over IPv6 outside the proxy. If an address from your own network appears there, the proxy is carrying your IPv4 traffic while IPv6 goes direct.

Disable IPv6 on the host's network adapter (or in the profile, where offered), then rerun /ip. The leaked address belongs to your own connection, not to the exit.

How do you keep the exit IP stable while you test?

BrowserLeaks fires several page loads and background requests during one test run. On a VoidMob shared list, the default rotation is per request (rotation_period_seconds: 0). Each request can exit from a different device, so /ip, /webrtc and /dns may show different IPs and cities. That looks like a leak, but it is rotation: a leak shows your own home or office address, not a second carrier IP.

Test on a list set to sticky (-1) or on a timed hold longer than your test run. A dedicated device also works, because it stays on one IP until you rotate it (unless you set a rotation timer). Check the exit before and after the run. The same public address on both checks is a good sign the run stayed on one exit.

Once a run comes back clean, rotate and test again. On a dedicated device, the private rotation link or the dashboard button changes the IP, with a 60-second cooldown. On a shared list, regenerating the list password forces a new identity.

Why does the TCP/IP fingerprint show a different OS than your browser?

The /tcp test fingerprints the packets that opened the TCP connection to BrowserLeaks. It shows a JA4T hash, a Satori fingerprint and signature match, a p0f link-type guess, Zardaxt OS scoring, and estimated MTU, initial TTL and hop distance. Through a proxy, the exit opens that connection, not your browser. The line therefore describes the exit side's network stack and path, whatever your User-Agent says.

A desktop User-Agent next to a different OS guess is a known mismatch, and no browser or profile setting changes it. The Link Type line can also name a tunnel: on a VPN connection it printed an OpenVPN/IPsec guess, which is one reason VPNs stand out here.

The line reports the real path from the exit to BrowserLeaks. Some detection stacks read passive TCP signals as one input among many, and you cannot tell from outside which sites weigh it. For how platforms use it, see TCP/IP fingerprinting explained.

Which BrowserLeaks lines belong to the browser, not the proxy?

The canvas, WebGL, fonts, TLS (JA3/JA4) and HTTP/2 (Akamai hash) lines belong to the browser. With an HTTP CONNECT or SOCKS5 tunnel, the proxy only relays bytes and the TLS handshake runs end to end between your browser and BrowserLeaks, so those hashes describe your browser build. Switching between such proxies does not change them.

These lines are the antidetect profile's job. Mobile proxies for antidetect browsers covers pairing a profile with an exit. The browser fingerprint test shows canvas, WebGL and fonts side by side. For the TLS side, read JA3 vs JA4.