Manual STUN and ICE check
WebRTC leak test
A WebRTC leak test checks whether your browser can expose local or public IP candidates outside the VPN or proxy identity you expected. ping123 keeps the test manual and transparent: no STUN checks run until you choose the WebRTC action.
Example ping123 result screenshot
The screenshot below uses the designated sample IP 89.116.88.34, not a current visitor IP. Use it as a visual reference for the fields explained on this page.
What WebRTC can reveal
WebRTC uses ICE candidates, STUN servers, TURN relays, and browser privacy mechanisms to discover network paths for real-time communication. In some VPN or proxy setups, those candidates can reveal a public IP or network clue that differs from the visible web request.
Modern browsers often mask local addresses with mDNS, but behavior still depends on browser version, profile settings, extensions, VPN routing, proxy configuration, and enterprise policy.
Which candidates matter
Relay or mDNS-only candidates are usually easier to accept. A server-reflexive public candidate that matches your VPN exit is often normal. A public candidate that points to your home, office, or mobile ISP is the signal to investigate.
Proxy users should be especially careful because many proxies affect web traffic but not peer-connection discovery.
Fixes differ by browser
Firefox can be locked down with WebRTC preferences when the workflow does not need peer connections. Chrome and Edge often require trusted extensions, enterprise policy, or VPN-level leak protection. Brave and privacy-focused browsers may still need per-profile testing.
After every browser, VPN, proxy, or extension change, rerun the test instead of assuming the previous result still applies.
How ping123 reviews WebRTC leak test results
This page is maintained as an editorial companion to the live ping123 tool. It explains which signals are collected, what a normal result usually looks like, and which mismatches deserve a second check before a login, payment, account review, or VPN/proxy workflow.
The sample screenshot is a fixed reference image, not a current visitor result. Use it to understand field names and result layout, then run the live check in your own browser session because IP, DNS, WebRTC, timezone, and reputation signals can change after every network switch.
- Start with the visible public IP and ASN.
- Compare country, timezone, DNS, and WebRTC signals instead of trusting one score.
- Treat risk labels as troubleshooting evidence, not as a guarantee of anonymity or safety.
- Rerun the check after changing VPN, proxy, browser profile, DNS, or network.
What the result fields mean
Normal signals vs. risk signals
Usually normal
- Only mDNS, relay, or VPN-consistent public candidates appear.
- Public candidates match the same region and network path as the VPN exit.
- No original ISP public address appears after the VPN is connected.
- Different STUN servers return the same expected result.
Needs attention
- WebRTC shows a home, office, or mobile ISP while a VPN is active.
- A proxy is enabled but candidates still show the direct network path.
- WebRTC region differs from the public IP country.
- One browser profile leaks while another profile does not.
Next action
Run WebRTC after the public IP check
The public IP can look correct while WebRTC still exposes a different route. Test both before sensitive browsing.
Fixes and next steps
- Disable or restrict WebRTC in browsers that do not need peer connections.
- Use VPN leak protection that covers WebRTC and IPv6 routes.
- Avoid split tunneling for browsers used with sensitive accounts.
- Test Chrome, Edge, Firefox, Brave, and anti-detect profiles separately.
- Reconnect to a different VPN node and rerun the manual test.
- Pair WebRTC results with DNS and browser fingerprint checks.
- Record the IP, ASN, country, DNS result, WebRTC result, browser timezone, and final decision when the check is part of an account or team workflow.
- Change only one setting at a time, then rerun the same ping123 page so the cause of a warning is easier to identify.
FAQ
What is a WebRTC leak?
It is a WebRTC candidate that exposes an IP or network path inconsistent with the VPN or proxy identity you intended to use.
Does WebRTC always leak my real IP?
No. Modern browsers often mask local addresses, and many VPNs route candidates safely. Manual testing confirms the current setup.
Is mDNS masking enough?
It helps with local address exposure, but you should still check public and server-reflexive candidates.
Do Chrome and Firefox behave the same?
No. Browser version, settings, extensions, and policy can change candidate behavior.
Should proxy users test WebRTC?
Yes. Proxies may not control WebRTC candidate discovery, so a separate manual test is important.
How does ping123 keep this page useful for review and real users?
We keep the page tied to a working tool, show example result screenshots, explain limits, and avoid saying that one score proves identity, anonymity, or account safety.
Does advertising affect this result?
No. Ads or partner links may support the free site, but they do not change IP results, DNS results, WebRTC results, risk labels, screenshots, or editorial conclusions.
Before you continue
Keep WebRTC testing explicit
ping123 does not run STUN checks silently. You decide when the browser should create WebRTC network candidates.