Testing a Proxy on BrowserLeaks
BrowserLeaks gives no score and no verdict. It shows raw values, page by page, and leaves the judgment to you. That makes it the most precise of the public checkers and the easiest to misread. For testing a proxy, six of its pages matter: IP, WebRTC, DNS, TLS, canvas and the TCP/IP fingerprint. This guide explains what each one measures, what a clean proxied result looks like, and which differences are normal on a mobile carrier line.
Short answer
- Start with the IP page. It already summarizes WebRTC, DNS, the TCP/IP fingerprint, TLS and HTTP/2 for your current connection.
- A clean proxied result shows one address everywhere: the IP page, WebRTC and the DNS serversโ country all agree with the exit.
- The TCP/IP fingerprint reflects the device that opens the connection, which on a proxy is the proxy, not your computer. An OS mismatch there is expected unless the proxy can adjust it.
- TLS and canvas describe your browser. A proxy does not change them, so do not expect a new exit to fix them.
The IP page
BrowserLeaks lists its tests on the home page; the IP page is the place to begin. Its fields, as shown on October 30, 2026: the IP address and hostname; country, region, city, ISP and organization; the networkโs AS number and name with tags; a usage type; the time zone and local time for the address; then sections for a leak test of version 6 addresses, a WebRTC leak test, a DNS leak test, the TCP/IP fingerprint, the TLS fingerprint, the HTTP/2 fingerprint and the HTTP headers your browser sent. Its geolocation is credited to DB-IP.
For a proxy test, read three things first. The address should be the exit, not your home connection. The ISP and network should be the carrier or provider you expect; on a mobile line that is the operatorโs network. And the usage type and tags come from a database, so a carrier network can carry several tags at once. Labels from different data sources disagree often, and none of them is the websiteโs own classification.
WebRTC
WebRTC lets a page discover network addresses for calls and peer connections, which is why it can reveal an address the proxy does not carry. The IETFโs RFC 8828 defines four handling modes for browsers, from enumerating every interface to forcing traffic through the proxy, and recommends the default-route mode when the user has not consented to more.
Clean result: no public address other than the proxyโs, and no local network address if your profile restricts that. Red flag: your home or office public address in the candidates. Our WebRTC leak test shows the same candidate list with an explicit STUN check.
DNS
The DNS test reveals which resolvers looked up the test hostnames. Clean result: resolvers in the exit country, or the proxy providerโs resolvers. Red flag: your internet providerโs resolvers at home while your traffic exits elsewhere. With SOCKS5, let the proxy resolve names (the socks5h scheme in curl and the equivalent option in browser profiles). Our DNS leak test compares resolver country with IP country in one step.
TLS
The TLS page shows how your browser opens an encrypted connection, summarized as JA3 and JA4 values. JA4 comes from FoxIOโs JA4+ suite, which also defines JA4T for TCP and JA4H for HTTP. JA4 itself is open source under the BSD 3-Clause license.
An HTTP or SOCKS5 proxy relays the encrypted stream without rewriting it, so the TLS fingerprint belongs to your browser or HTTP library. Clean result: a fingerprint that matches the browser you claim to be. Red flag: a Chrome user agent with a fingerprint typical of a scripting library. Our JA4 fingerprint checker shows the fingerprint observed for your request.
Canvas
The canvas page draws hidden graphics and hashes the result, which differs slightly between devices, drivers and browsers. The W3Cโs fingerprinting guidance classes this as active fingerprinting, done by script and potentially detectable. A proxy has no effect on it. Clean result: a stable hash that matches your real device class. Red flag: a hash that changes on every reload because an extension adds noise, which is itself a recognizable pattern.
The TCP/IP fingerprint
This part surprises most proxy users. The TCP/IP section, also on its own TCP page, guesses the operating system, MTU, link type and hop distance from the first packets of the connection, in the passive style pioneered by p0f. Through a proxy, those packets come from the proxy device. So a Windows browser behind a Linux-based proxy shows Linux here.
OS mismatch. Expected on most proxies. On Coronium lines, some lines let you set the TCP/IP OS fingerprint (p0f) to match your device; the dashboard shows which lines support it.
MTU and link type. Tunnels reduce the usable packet size, a problem described in RFC 4459, and BrowserLeaks infers a link type such as โtunnel or VPNโ from a lower MTU. Mobile data is carried through tunnels inside the operatorโs core network, and 3GPPโs TS 23.060 describes networks giving devices a reduced link MTU to avoid fragmentation. A tunnel-like link type on a genuine carrier line is therefore weak evidence of a VPN.
A clean result, page by page
| Page | Clean proxied result | Red flag |
|---|---|---|
| IP | Exit address, expected carrier or provider, matching time zone | Your home address or an unexpected network |
| WebRTC | Only the proxyโs public address, or none | Your real public address in the candidates |
| DNS | Resolvers in the exit country or the proxyโs own | Your home providerโs resolvers |
| TLS | Fingerprint typical of the browser you claim | Library fingerprint behind a browser user agent |
| Canvas | Stable hash for your device class | Hash that changes on every reload |
| TCP/IP | Proxy deviceโs OS, or yours if the line can set it | Treat a tunnel link type as weak evidence on carrier lines |
Use the table as a checklist and test with the same IP throughout; on a rotating line, pause rotation first. With Coronium mobile proxies, the exit is a carrier address on a physical device with its own SIM, rented to one customer, so the IP page should show the operatorโs network for the country you chose.
Sources and review scope
Sources reviewed October 30, 2026. Each checker was reviewed on October 30, 2026 from its own documentation, its published page scripts or an archived copy of its page, as the article states. Checkers change without notice, and a checker verdict is not a websiteโs decision. We do not see any siteโs private risk rules.
- BrowserLeaks: test index
- BrowserLeaks: IP page, read October 30, 2026
- RFC 8828: WebRTC IP address handling requirements
- FoxIO: JA4+ network fingerprinting
- W3C: mitigating browser fingerprinting in web specifications
- BrowserLeaks: TCP/IP fingerprinting
- p0f v3 passive fingerprinting
- RFC 4459: MTU and fragmentation issues with in-the-network tunneling
- 3GPP TS 23.060: GPRS service description, stage 2
Clause 9.3 and Annex C discuss link MTU for mobile devices.
Frequently asked questions
Read another checker
How each public checker reaches its verdict, and which of its findings a real site can act on.
Related workflows
ICE candidates and public-address exposure.
The TLS fingerprint observed for your request.
Resolver country against IP country.
How passive OS detection works on proxies.
The layers a site can check, from IP to TLS.
The full set of error and checker guides.
Where to get a dedicated line
A Coronium mobile proxy is one physical device with its own SIM, rented to one customer. It connects over HTTP or SOCKS5, the IP changes by dashboard button, API link or timer, and data is not metered on dedicated lines. Brazil lines are the exception: 20 GB of data a month and a new IP on request only, with no timer. Stock and prices differ by country and carrier.