ping123 Transparent IP Check
Auto IP check No silent WebRTC

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.

Run WebRTC leak test Open DNS leak test

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.

ping123 WebRTC leak test result showing STUN servers, ICE candidates, and exposed IP signals
WebRTC results should be compared against the public IP, DNS resolver, VPN route, and browser profile.

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.

What the result fields mean

Host candidate A local network candidate, often private or mDNS-masked.
Server-reflexive candidate A public-facing candidate discovered through STUN.
Relay candidate A TURN relay candidate that usually hides the direct route.
mDNS masking A browser privacy feature that hides local IP details.
STUN server The server used to discover network candidates.
Mismatch A candidate that conflicts with your intended VPN or proxy identity.

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.

Open DNS leak test

Fixes and next steps

DNS leak Turn on DNS leak protection in the VPN or proxy client, disable browser Secure DNS if it bypasses the tunnel, set system DNS to the provider's DNS or a trusted encrypted resolver, then rerun the DNS check.
WebRTC leak Limit or disable WebRTC direct candidates, use a browser profile that blocks WebRTC IP exposure, restart the browser, then rerun the WebRTC check before logging in.
Datacenter ASN If the task needs a consumer-looking account environment, switch from a datacenter/VPS ASN to a stable residential, mobile, or dedicated ISP exit and keep the region consistent.
Blacklist or abuse history Do not keep using a high-risk or listed IP for important accounts. Change the IP range or provider, wait for reputation to stabilize, and retest before continuing.
Timezone or language mismatch Align the IP country, system timezone, browser language, account region, and DNS/WebRTC routes so the session tells one consistent location story.
  1. Disable or restrict WebRTC in browsers that do not need peer connections.
  2. Use VPN leak protection that covers WebRTC and IPv6 routes.
  3. Avoid split tunneling for browsers used with sensitive accounts.
  4. Test Chrome, Edge, Firefox, Brave, and anti-detect profiles separately.
  5. Reconnect to a different VPN node and rerun the manual test.
  6. Pair WebRTC results with DNS and browser fingerprint checks.

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.

Before you continue

Keep WebRTC testing explicit

ping123 does not run STUN checks silently. You decide when the browser should create WebRTC network candidates.

Run WebRTC leak test Open DNS leak test