WebRTC ICE Candidates and IP Leaks Explained

Short answer

A candidate is not automatically a leak. A private IPv4 address or an mDNS .local name is local-network information. A public candidate can matter when it reveals a route you did not intend to expose, especially when it differs from the VPN or proxy route websites normally see.

Check candidates exposed by this browser (local-only) → · Try the synthetic candidate parser in your browser →

For WebRTC developers: gather and read ICE candidates

The icecandidate event reports each candidate as gathering finds it. A candidate line contains a foundation, component, transport, priority, address, port, and typ value; optional extensions can add related-address fields such as raddr and rport, or the TCP-specific tcptype. The type describes how the route was learned: host uses a local interface, srflx is learned through STUN, prflx during connectivity checks, and relay through TURN.

An event with candidate === null means gathering is complete. A non-null candidate whose candidate string is empty marks the end of candidates for that ICE generation. This original example gathers with no configured ICE servers:

(async () => {
  const pc = new RTCPeerConnection({ iceServers: [] });
  pc.createDataChannel("candidate-demo");
  pc.addEventListener("icecandidate", ({ candidate }) => {
    if (candidate === null) {
      console.log("ICE gathering ended");
      pc.close();
      return;
    }
    if (candidate.candidate === "") {
      console.log("End-of-candidates marker");
      return;
    }
    console.log(candidate.candidate);
  });
  try {
    await pc.setLocalDescription(await pc.createOffer());
  } catch (error) {
    pc.close();
    console.error(error);
  }
})();

With iceServers: [], this sample does not contact a third-party STUN or TURN server. Adding STUN sends requests to that configured service, changes the network disclosure, and may produce a server-reflexive candidate. The no-STUN result cannot describe what a different site's ICE configuration would expose.

Parse a copied candidate line with the browser-only inspector → · Gather this browser's local-only candidates →

How to read an ICE candidate

This synthetic documentation address shows the standard candidate shape:

candidate:842163049 1 UDP 1677734911 203.0.113.7 61764 typ srflx raddr 192.168.1.14 rport 61764

Candidate types: host, srflx, prflx, and relay

Host describes a route from a local interface. Modern browsers may replace a local IP with an mDNS name. Server-reflexive (srflx) describes a NAT mapping learned through STUN. Peer-reflexive (prflx) is learned during connectivity checks. Relay is an address allocated by a TURN server.

Candidate priority helps ICE choose a route; a larger number is not evidence that an address is safer or more private.

When a candidate deserves review

First record the public route visible to an ordinary HTTPS request. Then inspect WebRTC candidates. If a public-looking candidate shows a different address from the route you meant to expose, investigate the browser, VPN split-tunneling policy, and the exact STUN/TURN configuration used by the test.

A private address, carrier-grade NAT address, loopback address, link-local address, or mDNS name is not by itself evidence that a public IP escaped a VPN. Conversely, an empty candidate list can mean the browser withheld details; it does not prove that every WebRTC configuration is safe.

What the MyIPCheckup test covers

The current test uses RTCPeerConnection({iceServers: []}). It requests no media permission and sends no candidate inventory to MyIPCheckup. It also contacts no third-party STUN or TURN server. That makes the data path narrow and explicit, but it means the test cannot rule out a public srflx candidate that a STUN-enabled site could gather.

Primary references

MDN: RTCIceCandidate type defines the browser-facing candidate types. RFC 8445: Interactive Connectivity Establishment specifies ICE terminology and processing. The example above uses an address reserved for documentation by RFC 5737.

Four candidate lines, four different meanings

These are synthetic strings using private, local or reserved documentation addresses. Try them in the browser-only ICE inspector; parsing does not contact STUN or TURN.

candidate:a 1 UDP 1 10.0.0.5 5000 typ host
candidate:b 1 UDP 1 device.local 5001 typ host
candidate:c 1 UDP 1 203.0.113.7 5002 typ srflx raddr 10.0.0.5 rport 5000
candidate:d 1 UDP 1 2001:db8::1 5003 typ relay raddr 10.0.0.5 rport 5000

The first is a private host address; the second masks a host with mDNS. A real srflx candidate would describe a server-reflexive mapping; a real relay candidate would describe a relayed route. The pasted examples do not prove any connection or reachability. The live test configures iceServers: [] and therefore does not test exposure under another site's STUN/TURN configuration.

ICE specification · IPv4 examples · IPv6 examples.