BrowserLeaks Tests Through a Carrier Line

BrowserLeaks is a collection of single-purpose test pages, each showing one thing a website can learn about a visitor: the address, WebRTC candidates, DNS resolvers, the TLS handshake, the TCP/IP stack, canvas and graphics output, fonts and more. It is popular with privacy researchers and with teams checking that a proxy setup does what they think it does. Because the pages are separate, it is also the clearest way to see which parts of a session a SpoofProxies line affects and which parts belong to your own browser and device. This page goes through the tests in that order.

Tests that show the line

The IP address page reports the public address, the network owner, a location and reverse DNS. Through a carrier line it should show AT&T, T-Mobile or Verizon, a location in the line's metro region and often no meaningful hostname, which is normal for CGNAT pools. The page also lists request headers. With an HTTP or SOCKS5 connection through our lines, you should not see forwarding headers that reveal an origin address; if you do, something else in your chain, such as a local tool, is adding them.

The DNS leak test shows which resolvers answered lookups for your session. With SOCKS5 and remote DNS resolution, or with an HTTP proxy, the resolution happens on the proxy side. If your office or home provider's resolvers appear instead, your client is resolving names locally, which is a configuration choice worth fixing for consistency.

WebRTC, the most common surprise

The WebRTC test shows the candidate addresses a browser offers when setting up peer connections. Browsers can reveal a local network address and, in some configurations, the public address of the real connection, which sits outside the proxy. That is not a failure of the line; it is the browser using a different path. The fix is a browser setting or policy that limits WebRTC to the proxied route. After changing it, reload the test and confirm that only the carrier address, or nothing public, appears.

Tests that show the machine in between

The TCP/IP fingerprint page is worth understanding because it confuses people. It reads properties of the TCP connection, such as window size and options, and guesses an operating system and a link type from them. With an HTTP or SOCKS5 proxy, the TCP connection a site receives starts at the proxy host, not at your laptop, so the guess describes the proxy side of the path. That is how every forward proxy works. A mismatch between that guess and your browser's user agent is a known pattern that some sites look at, and it is one reason platforms judge sessions on many signals rather than one.

The TLS page shows the handshake fingerprint, often summarised as JA3 or JA4. For HTTPS through a proxy, the handshake is still made end to end by your browser, so the TLS fingerprint belongs to your browser, not to the line.

Tests the line never touches

Everything in this group is produced locally. A proxy changes the network route and cannot alter any of it, and we do not supply tools that do. If a result here worries you, it is a question about the browser or device you are using, not about the carrier line.

• Canvas, WebGL and audio outputs come from your graphics stack and browser.
• Font lists come from the operating system and browser.
• JavaScript properties, screen and client hints come from the browser.
• Geolocation API results come from the device and only with your permission.

Putting it together

A clean run through BrowserLeaks for a line means the address page names the carrier and metro, the DNS page shows no local resolvers, WebRTC exposes nothing outside the proxy, and the time zone you have set in the browser matches the region. The fingerprint pages then simply describe your browser, and that is fine. Run the set once per profile and after changes, not every session. It is a diagnostic kit, and its job is to tell you where a problem lives.

If one test disagrees with the others, change one setting at a time and rerun only that page, so you know which change fixed it.

Setting up a BrowserLeaks proxy on SpoofProxies

1. Add a line and copy its host, port, username and password from the dashboard.
2. Configure a browser profile to use the line, choosing SOCKS5 with remote DNS or HTTP.
3. Open the BrowserLeaks IP page and confirm the carrier and metro.
4. Run the DNS leak and WebRTC pages and fix any local resolver or address that appears.
5. Set the browser time zone to the line's region and reload the IP page to compare.
6. Save the results as a baseline for that profile.

BrowserLeaks proxy questions