What Is a WebRTC Leak? How to Tell If Your Real IP Is Exposed

You turn on a VPN. Your normal IP check now shows the VPN server.

Then you open a WebRTC test and see another address.

That is usually the moment people ask us:

“Is WebRTC leaking my real IP?”

Sometimes the answer is yes. Often, it is not.

The mistake is treating any address shown by WebRTC as proof of a leak.

What we actually care about is much simpler:

Did WebRTC expose a public IP or network path that should have stayed hidden?

If you are checking a VPN, proxy, or isolated browser profile right now, start with the EnvTrace WebRTC Leak Test. Then use the guide below to read the result.

Quick answer: is this actually a WebRTC leak?

Assume your connection looks like this:

Public IP before VPN: A
Public IP after VPN:  B

Now compare that with the WebRTC result.

That table is the main thing we wish more WebRTC leak pages explained clearly.

An IP appearing in the test is not the problem by itself. An unexpected public IP is.

How we check for a WebRTC leak

When we want to verify a connection, we prefer a before-and-after comparison. It is easier to understand and much harder to misread than staring at a list of ICE candidates.

1. Record your public IP before the VPN

Disconnect the VPN or proxy you want to test.

Open an IP address lookup and write down the public IP.

For example:

198.51.100.8

This is your baseline.

2. Connect the VPN or proxy and check again

Now connect the network route you actually plan to use.

Refresh the IP lookup.

You might now see:

203.0.113.20

At this point, normal web traffic is reaching the site through the new public exit.

3. Run the WebRTC test

Open the WebRTC Leak Test.

Now look for the IP you recorded in step one.

If you see:

Before VPN:
198.51.100.8

After VPN:
203.0.113.20

WebRTC:
198.51.100.8

that is the kind of result we would treat as a real leak signal.

The browser is exposing the public address you expected the VPN to hide.

If WebRTC shows only:

203.0.113.20

then WebRTC is exposing the same public exit as the VPN. That is not a leak just because an IP is visible.

Why can WebRTC show a different IP at all?

You do not need to understand WebRTC internals to use a leak test, but one small piece of the protocol explains most of the confusing results.

WebRTC is built for real-time browser communication: video calls, voice chat, screen sharing, and peer-to-peer data.

To make those connections work, the browser has to answer a practical question:

Which network route can actually reach the other side?

So it gathers possible routes.

WebRTC calls them ICE candidates.

You will often see three broad types.

Host candidates: addresses on the device

A host candidate comes from a network interface available to the browser.

That may include a private local address such as:

192.168.1.25

This is not the same thing as your public ISP address.

Server-reflexive candidates: what STUN sees from outside

A STUN server helps the browser learn how its connection appears from the public internet.

That can produce a server-reflexive, or srflx, candidate.

This is the one we pay close attention to when testing a VPN.

If the candidate reflects the VPN’s public exit, that is expected.

If it reflects the ISP public IP you had before connecting to the VPN, something is bypassing the route you expected to use.

Relay candidates: traffic goes through TURN

Sometimes a direct WebRTC path does not work.

In that case, the connection can go through a TURN server.

The browser then uses a relay candidate.

A relay address belongs to the relay path. Seeing it does not mean the browser has handed the other side your real ISP address.

Why a VPN or proxy can still produce an unexpected WebRTC route

This is where a lot of explanations become too broad.

A VPN and a browser proxy are not the same thing, and not every proxy handles every type of browser traffic in the same way.

The proxy may only handle part of the browser’s traffic

Some proxies are mainly used for HTTP or HTTPS requests.

WebRTC can use other network paths, including UDP-based connectivity.

If those paths are not covered by the same proxy rules, WebRTC may discover an address that normal page requests do not use.

That does not mean every proxy leaks WebRTC. It means you need to test the actual setup you are using.

Split tunneling may be enabled

A VPN can intentionally send some traffic through the tunnel and let other traffic use the normal network.

That feature is called split tunneling.

There is nothing inherently wrong with it.

But if your goal is to make the entire browser use one network identity, a WebRTC path outside the VPN becomes a mismatch worth investigating.

Your device may have more than one network interface

A laptop can have:

• Wi-Fi;
• Ethernet;
• a VPN interface;
• a mobile hotspot;
• virtual network adapters.

WebRTC may discover more than one possible route.

So if a test shows multiple addresses, our first question is not “Who is tracking me?”

It is:

Which interface or route did this address come from?

That question is usually much more useful.

Is a 192.168.x.x address a real IP leak?

Not in the same sense as leaking your public ISP address.

Addresses such as:

192.168.x.x
10.x.x.x
172.16.x.x - 172.31.x.x

are private addresses.

They are reused on millions of unrelated home and office networks. Someone on the public internet cannot take 192.168.1.25 and use it like a public IP to locate your internet connection.

So if a test shows a private IP:

Do not automatically label it a “real IP leak.”

There is still a privacy angle.

A local address can reveal something about the network environment and may add another signal to the browser’s overall fingerprint.

That is a different issue from exposing the public address assigned by your ISP.

If you want to see how network data fits into the wider browser identity, read What Is Browser Fingerprinting?.

What does a .local address mean?

Modern browsers often avoid exposing the raw private IP directly.

Instead of:

192.168.1.25

you may see something like:

7f3d2a1b-xxxx-xxxx-xxxx.local

That is usually related to mDNS.

In plain English, the browser is replacing the local private IP with a temporary hostname.

So when we see .local, we do not treat it as a mysterious second public IP.

It usually means the browser is reducing direct local-IP exposure.

What if the WebRTC test shows no extra IP?

That is a useful result, but it does not prove that the whole browser environment is private or consistent.

A WebRTC test answers a narrow question:

Did WebRTC expose an unexpected network path during this test?

It does not tell you whether:

• DNS queries are using the route you expect;
• IPv6 is bypassing a VPN;
• the current IP is residential or hosted;
• the IP has abuse or blacklist history;
• the browser fingerprint is consistent;
• a website can identify the VPN through other signals.

For the current public IP and network owner, use IP Address Lookup.

For proxy, hosting, blacklist, and abuse signals, use IP Address Check.

And if your question is broader — “Can a site tell that I am using a VPN?” — we cover that separately in Can Websites Detect a VPN?.

How to fix a real WebRTC leak

If your pre-VPN public IP really does reappear in the WebRTC result, we would troubleshoot the route before changing random browser settings.

Confirm that the result is repeatable

Run the comparison again.

Make sure you know all three values:

• public IP before VPN;
• public IP after VPN;
• public IP exposed through WebRTC.

A repeatable mismatch is much more useful than a one-off result.

Check how the VPN or proxy is routing the browser

Look for:

• split tunneling;
• browser-specific proxy settings;
• extensions that override the system proxy;
• multiple active network interfaces;
• a proxy that only covers web requests rather than the browser’s other network paths.

The exact fix depends on the setup.

That is why we avoid generic advice such as “WebRTC is unsafe” or “just disable WebRTC.”

Change the route, then test again

After changing the VPN or proxy configuration, rerun both:

• IP Address Lookup;
• WebRTC Leak Test.

Do not rely on the setting looking correct. Verify the result.

Disable or restrict WebRTC only if you actually need to

WebRTC is not malware. It is a browser feature used by legitimate sites for:

• video meetings;
• voice calls;
• screen sharing;
• real-time data connections.

Blocking it completely can break those features.

If you do not use WebRTC, restricting it may be reasonable. But if you do need it, the better outcome is usually:

WebRTC works, but it uses the network route you intended.

WebRTC leak vs. DNS leak vs. IPv6 leak

These problems get grouped together because they can all reveal something about the network behind a VPN or proxy.

They are still different tests.

A clean result in one test does not automatically guarantee a clean result in the others.

The one rule we use when reading WebRTC results

If you remember nothing else from this guide, remember this:

Record your public IP before the VPN. Connect the VPN. Then check whether WebRTC exposes that old public IP again.

Do not panic just because a WebRTC page shows:

• the current VPN IP;
• 192.168.x.x;
• a .local hostname;
• a TURN relay address.

Those results mean different things.

The result that deserves attention is the one that exposes a public route you meant to keep hidden.

You can run the EnvTrace WebRTC Leak Test now and compare it with your current public IP.