BrowserScan is a free website that tests your browser fingerprint. It reads what your browser and connection reveal: the IP address and its location, the time zone, the language, WebRTC and DNS results, hardware values and signs of automation. From these it builds an "authenticity" score, which drops when the signals disagree with each other. With a proxy, three warnings come up most often: different time zones, a second IP address found through WebRTC, and bot control.
We ran BrowserScan 15 times on 11 October 2026, in five setups with three runs each. Every setup changed one thing, and every fix won back exactly the points of its own check. The score measures how well your signals agree. It does not measure whether you use a proxy, and it does not measure privacy.
How does BrowserScan score you?
BrowserScan starts from 100% and takes points off for each mismatch it finds. These were the three deductions in our runs:
| Warning | What it compares | Points | The fix |
|---|---|---|---|
| Different time zones | The browser's time zone with the IP's | -10 | Set the time zone to the proxy's |
| IP addresses are different | The page's IP with the address WebRTC finds | -10 | Chrome's WebRTC policy |
| Bot control | Signs that a program drives the browser | -5 | A normal, non-automated browser |
The texts behind the deductions are short. For time zones, BrowserScan writes: "It appears you have used a proxy or altered your local timezone". For the second warning: "It looks like you are hiding the actual IP". Both describe a mismatch. Neither proves a proxy, as the next section shows.
What happened in our test?
We used headless Chrome 143 on our own server and loaded BrowserScan in a fresh profile for every run. Setups A and B went direct. Setups C, D and E went through a free elite proxy in Frankfurt from our own list. We masked our addresses before anything was saved.
The direct runs scored as low as the proxy runs. The best score, 95%, came through the proxy, once the time zone matched and WebRTC was closed. The last 5 points went to bot control in every run, because our Chrome was headless.
What do the warnings mean?
Different time zones
A browser reports the time zone of the system it runs on. In JavaScript the value "is an IANA time zone name". MDN adds: "The default is the runtime's default time zone". BrowserScan compares it with the time zone it links to your IP address.
Our server's clock ran on Europe/Berlin, while its IP address sat in the America/Chicago zone. That cost 10 points. Setting Chrome to Chicago removed the deduction. Through the German proxy the problem reversed: the Chicago setting now cost 10 points, and Berlin removed them. The rule is simple. Your time zone has to match the country of the exit, not your own.
IP addresses are different
WebRTC is the browser's channel for calls and video. To find a route, it asks STUN servers which public address they see. RFC 8828, the standard for WebRTC address handling, puts the proxy problem plainly. "WebRTC's STUN checks will bypass the proxy and reveal the public IP address of the client", unless that direct path is blocked.
That is what we saw. Through the German proxy, the page saw the proxy's exit, while WebRTC found our server's own IPv4 address. BrowserScan took 10 points off for it.
The same warning also hit our direct runs, with no proxy at all. Our server has an IPv6 and an IPv4 address. The page loaded over IPv6, while WebRTC reported IPv4. BrowserScan counted that as a hidden IP, took 10 points and showed "Proxy: Yes". A dual-stack connection can trigger a proxy warning by itself.
Bot control
All 15 runs lost 5 points here, with "Bot Detection: Yes". The cause is documented. The navigator.webdriver property "indicates whether the user agent is controlled by automation". In Chrome it is true in one of these cases: "The --enable-automation or --headless flag is used". Our test ran headless, so BrowserScan saw an automated browser. A browser that you open and use by hand does not set this flag.
Which Chrome setting stops the WebRTC leak?
Chrome calls it the WebRTC IP handling policy. Its value disable_non_proxied_udp means that "WebRTC uses either UDP SOCKS proxying or will fallback to TCP proxying". RFC 8828 calls this mode "Force proxy". Chrome lets you set it in three ways, and in our tests they did not all work.
- The privacy setting for extensions. Since Chrome 48, an extension can set
chrome.privacy.network.webRTCIPHandlingPolicy. We wrote a ten-line extension that sets it todisable_non_proxied_udpand ran the full Chrome 143 build. In both runs, WebRTC found no address and BrowserScan showed "Proxy: No", although every request went through the proxy. - A command-line flag,
--force-webrtc-ip-handling-policy=disable_non_proxied_udp. It worked in Chrome's headless shell in all three runs of setup E. In the full Chrome build, the same flag changed nothing: in two runs, WebRTC still found our server's address. - The enterprise policy
WebRtcIPHandling, supported since Chrome 91 on managed computers. Chrome's policy list says it "allows restricting which IP addresses and interfaces WebRTC uses". We did not test this one.
So check the result, whichever way you set it. A test page that still shows your own address over WebRTC means the setting did not take.
The trade-off is call quality. RFC 8828 notes that sending WebRTC over a proxy means TCP: "Use of TCP will result in reduced media quality". A SOCKS5 proxy that supports UDP can carry WebRTC traffic itself, as we explain in SOCKS5 UDP explained.
What BrowserScan is not
It is not a privacy grade. A high score says your signals agree. It says nothing about who runs the proxy, what the destination logs or how unique your fingerprint is. Real sites also combine checks that a test page cannot show, as we cover in how websites detect proxies.
It is not neutral ground either. Its privacy policy says it may collect your IP address "to help diagnose problems with our servers" and may keep access logs "up to six months". The policy does not name the company behind the site. Run the test in the browser profile you want to check, and treat the score as one hint among several.
If you need an exit in a chosen country to match your time zone to, our residential proxies let you pick the country.
What this page could not check
- All runs used headless Chrome on a Linux server, which BrowserScan detects as a bot. A desktop browser would not lose those 5 points, and its hardware and font values would differ.
- We tested one free proxy, an elite HTTP proxy in Frankfurt. A residential, mobile or SOCKS5 proxy may behave differently.
- BrowserScan's code is not public. What each deduction means comes from the texts it shows and from our runs.
- We tested the WebRTC setting in two Chrome 143 builds, with four follow-up runs after the main 15. We did not test the enterprise policy or desktop Chrome on Windows or macOS.
- We did not test the checks that need a BrowserScan account, Anonymous and Blacklist.
- Three runs per setup on one morning. One direct run found no WebRTC address at all, so that deduction can come and go.
- BrowserScan and Chrome change their checks without notice. We will run the five setups again by 11 January 2027.
Sources
- RFC 8828, WebRTC IP Address Handling Requirements, IETF, January 2021: rfc-editor.org.
- Chrome Enterprise policy list, WebRtcIPHandling, read 11 October 2026: chromeenterprise.google.
- Chrome for Developers, chrome.privacy API, webRTCIPHandlingPolicy, read 11 October 2026: developer.chrome.com.
- MDN Web Docs, Navigator.webdriver, read 11 October 2026: developer.mozilla.org.
- MDN Web Docs, Intl.DateTimeFormat resolvedOptions, read 11 October 2026: developer.mozilla.org.
- BrowserScan, privacy policy, undated, read 11 October 2026.
- HProxy, free proxy list API, read 11 October 2026: hproxy.com/docs/free-proxy-list.
- Our own test: 15 runs of headless Chrome 143 on our server, 11 October 2026, 04:44 to 05:05 UTC, and four follow-up runs of the WebRTC setting in the full Chrome build, 05:52 to 05:55 UTC.
