How WebRTC Can Reveal IP Addresses Behind a VPN or Proxy

VPNs and proxies route many of your internet connections through another network endpoint. But your browser can also use other networking mechanisms. One worth understanding is WebRTC.

WebRTC powers real-time features such as video calls, voice calls, and peer-to-peer data exchange. As part of setting up a connection, the browser gathers network information called ICE candidates. Depending on your browser and network setup, some candidates may expose public IP addresses that differ from the address seen by a normal HTTP request.

This guide explains what those candidates mean, why they can differ from your VPN or proxy’s HTTP exit IP, and how to interpret the results of a WebRTC leak test.

1. What Is WebRTC?

WebRTC (Web Real-Time Communication) is a set of browser APIs and protocols for real-time communication without a separate plugin. It is used by applications such as:

• Video conferencing tools
• Browser-based voice calls
• Peer-to-peer file sharing
• Real-time collaboration apps

WebRTC uses ICE (Interactive Connectivity Establishment) to find possible network paths between peers. During this process, the browser gathers information about available network addresses and connection options. Each possible path is represented by an ICE candidate.

2. What Are ICE Candidates?

ICE candidates describe possible ways to establish a WebRTC connection.

Candidate type	Meaning
host	An address associated with a local network interface. Modern browsers may conceal local addresses using mDNS hostnames.
srflx	A server-reflexive candidate, typically a public-facing address discovered through STUN.
prflx	A peer-reflexive candidate discovered during connectivity checks.
relay	A candidate provided by a relay server, typically using TURN.

Candidates have different privacy implications. A private address such as 192.168.1.10 is not a public IP address. An mDNS hostname ending in .local should not, by itself, be treated as evidence that a public IP has leaked.

A public candidate deserves closer attention. It may reveal a public-facing network address, but the candidate type alone does not establish whether that address is unexpected.

3. How Does STUN Discover a Public Address?

STUN stands for Session Traversal Utilities for NAT. When a browser uses a STUN server during ICE gathering, the server can observe the source address of the request. The browser may then receive a server-reflexive candidate containing the public-facing address and port observed by that server.

The process looks roughly like this:

1. The browser creates an RTCPeerConnection.
2. ICE gathering begins.
3. The browser may contact a configured STUN server.
4. The STUN server observes the request’s source address.
5. The browser may receive a server-reflexive (srflx) candidate with that address.

This is normal WebRTC behavior; STUN is not inherently a security vulnerability. However, the STUN operator can observe the network address from which the request arrives.

4. Why Might a WebRTC Address Differ From a VPN or Proxy IP?

Suppose your browser sends an ordinary HTTP request through a VPN. The destination website sees the VPN’s public exit IP.

WebRTC traffic may take a different route, depending on the VPN, proxy, browser, operating system, and network configuration. That means a public WebRTC candidate can differ from the address seen by an HTTP lookup.

Observation	Example address
Expected HTTP exit IP	198.51.100.20
Public WebRTC candidate	203.0.113.45

These are documentation-only IPv4 addresses used as examples.

If a real test finds different public addresses, investigate the result. A mismatch alone does not prove that the VPN has failed or that your original IP address has been exposed. Possible explanations include:

• The browser has multiple network interfaces.
• IPv4 and IPv6 use different routes.
• HTTP and STUN requests follow different network paths.
• A VPN or proxy handles some traffic differently from other traffic.
• The HTTP lookup is reaching a different endpoint than expected.

The key question is whether the observed address differs from the network endpoint you intended to use.

5. How to Test for a Potential WebRTC IP Leak

A useful test gathers ICE candidates, classifies their addresses, and—when a comparison IP is available—checks public candidates against the expected HTTP exit IP.

The general process is:

1. Obtain the HTTP exit IP you expect.
2. Create an RTCPeerConnection.
3. Gather ICE candidates, allowing enough time for the process to finish.
4. Classify candidate types and addresses.
5. Compare all public candidate addresses, not just srflx candidates, with the expected HTTP exit IP.
6. Treat any mismatch as a signal to investigate, not a definitive conclusion.

Here is a simplified browser-side example:

const pc = new RTCPeerConnection({
  iceServers: [
    { urls: "stun:stun.l.google.com:19302" }
  ]
});

pc.onicecandidate = (event) => {
  if (event.candidate) {
    console.log(event.candidate.candidate);
  }
};

pc.createDataChannel("test");

pc.createOffer()
  .then((offer) => pc.setLocalDescription(offer))
  .catch(console.error);

This example starts ICE candidate gathering; it is not a complete leak detector. Production code should also handle timeouts, cleanup, unsupported environments, candidate parsing, and address classification.

The STUN server shown is an example. The detector’s default configuration uses Google’s public STUN server, so gathering candidates contacts that service. A deployment should choose appropriate ICE servers and explain the resulting network activity.

6. How to Interpret the Results

A detector should avoid treating every address difference as a confirmed security problem.

Potential mismatch

A public WebRTC address differs from the supplied HTTP exit IP. This is a reason to investigate whether the difference is expected for your network setup.

If no HTTP exit IP is supplied, this detector flags discovered public addresses as unverified and reports potential_leak. That result does not mean a mismatch was confirmed; there was no comparison IP to check against.

No public mismatch detected

The observed public candidates match the supplied HTTP exit IP. This is useful evidence, but it does not guarantee that all network information is hidden.

Private or mDNS addresses only

Private addresses and mDNS hostnames may appear during ICE gathering. Their presence alone does not prove that a public IP has leaked.

No candidates gathered

The browser may have blocked WebRTC, gathering may have timed out, or no candidates may have been produced for another reason. An empty result does not automatically mean the test passed, and the detector may not be able to determine why no candidates were returned.

7. Try the Open-Source WebRTC Leak Detector

I built an open-source, browser-based WebRTC leak detector to make the process easier to inspect. It gathers and classifies ICE candidates, distinguishes public addresses from private and mDNS addresses, and can compare public candidate addresses against an optional HTTP exit IP.

• Live demo: kindproxy.com/webrtc-leak-test
• Source code: github.com/andy-smith-999/webrtc-leak-detector

The detector uses plain JavaScript ES modules and is designed to be provider-independent. The demo uses a public STUN server for ICE gathering and can use an HTTP IP lookup for comparison. The source code and privacy documentation describe the detection process and its limitations.

Contributions, bug reports, and feedback are welcome.

8. Final Thoughts

WebRTC and ICE candidate gathering are normal parts of how browsers establish real-time connections. The privacy question is whether the addresses observed during that process match the network behavior you expect.

A difference between HTTP and WebRTC addresses is worth examining, but it is not enough by itself to prove that your real IP address has leaked. Understanding ICE candidates, STUN, address classification, and network routing can help you interpret test results more accurately.

If you work on browser privacy, networking, or VPN testing, try the detector, inspect the source, and share any issues or improvements you find.