Short answer: Chrome can expose browser network candidate signals through WebRTC. Modern Chrome often masks local addresses with mDNS, but VPNs, proxy extensions, enterprise policies, browser permissions, and network changes can still create confusing results.
If a VPN is connected, the page IP can look correct while WebRTC candidates tell a different browser-level story. The goal is not to prove anonymity. The goal is to see whether Chrome's current browser session exposes candidates that need review.
Problem
- This reads the Chrome profile you run it in. A second profile with different extensions can return a different answer.
- Chrome offers no setting that turns WebRTC off, so everything actionable here is a profile or an extension.
- Other applications on the machine do not share Chrome's candidate list and are not covered by this result.
Run the test
Start with WebRTC Leak Test. Keep the same browser and network when comparing before and after.
- Open the WebRTC Leak Test in the same Chrome profile you normally use.
- Run the test before changing VPN, proxy, extension, or Chrome privacy settings.
- Connect or change the VPN, keep the same Chrome profile, and run the test again.
- Compare WebRTC candidates with What Is My IP, DNS Leak Test, and IPv6 Leak Test when the result is unclear.
- Use Safe Copy after the final run so you keep a reduced summary without raw candidate strings.
How to read the Chrome WebRTC Leak Test result
| Result | Usually means | What to do next |
|---|---|---|
| mDNS or masked local candidates | Often normal in modern Chrome. | Still compare with VPN state if you are troubleshooting. |
| No public WebRTC candidate | Chrome did not expose a public candidate in this session. | Good sign, but not a full privacy guarantee. |
| Public candidate matches VPN route | The browser may expose the VPN-facing route. | Usually less concerning than an ISP candidate, but still document it. |
| Public candidate matches real ISP | Chrome may be bypassing the expected VPN route or using a mixed path. | Review VPN split tunneling, proxy extensions, IPv6, and OS routing. |
| Blocked or inconclusive | Chrome policy, extension, network, or browser API limits may block the check. | Retest in a clean profile or another browser if needed. |
Chrome-specific checks
- Test the exact Chrome profile that has your extensions enabled.
- Disable only one extension at a time if a candidate changes unexpectedly.
- Check whether browser proxy extensions are bypassing the VPN route.
- Retest after Chrome updates because WebRTC and mDNS behavior can change.
What to do after the result
Chrome gives you no preference to turn WebRTC off, so the two levers are the profile and its extensions, in that order. Local host candidates are already replaced by mDNS hostnames by default, and the only supported way to unmask them is the managed WebRtcLocalIpsAllowedUrls policy, which an administrator sets and which you cannot reach from Settings. If a masked local candidate is all you see, that is Chrome behaving normally and there is nothing here to change.
A public candidate pointing at your ISP while the VPN is connected is the result worth acting on, and in Chrome that is usually an extension carrying its own proxy or a profile the VPN does not cover. Re-run the test in a fresh profile with no extensions enabled. If the ISP candidate disappears, switch them back on one at a time until it returns. If it survives a clean profile, the route is being set below the browser, in split tunneling or OS routing, and this page cannot narrow it further.
Frequently asked questions
Does a clean Chrome WebRTC result certify browser privacy?
No. It is one browser-session signal. Accounts, cookies, IP route, DNS, IPv6, browser fingerprinting, and app traffic can still identify or correlate a session.
Why does Chrome show mDNS instead of a local IP?
Modern Chrome can mask local network candidates with mDNS hostnames. That is often normal and does not mean every WebRTC risk is gone.
Should I test Chrome with the VPN on and off?
Yes. A before and after comparison is more useful than one isolated result.
Limits and methodology
MyIPScan checks show observable browser and network signals for the current session. Results can change with browser profile, app route, VPN server, router, OS, carrier, DNS, and time. See the methodology and editorial policy.