A VPN can be working normally for web traffic while a browser still exposes more information about the host’s network interfaces than you expected. That does not mean WebRTC is “breaking encryption.” It means the browser is doing something different from an ordinary HTTPS request.
WebRTC has to establish real-time paths for voice, video, data, and peer-to-peer traffic. To do that, it uses ICE — Interactive Connectivity Establishment — to discover possible transport addresses that two endpoints could use to communicate. Those addresses are known as ICE candidates.
Depending on the browser, operating system, VPN configuration, and network topology, the candidate list may include a local interface address, a NAT-mapped public address, a VPN address, or a relay address from a TURN server. Interpreting a WebRTC leak test therefore requires careful analysis. Seeing an IP address is not enough.
The real question is: did WebRTC expose or select a public path outside the VPN when the browser was supposed to stay on the VPN route? This is one of the VPN & Privacy guides, sitting under the What Is a VPN Leak? pillar alongside the DNS leak guide. To check your own connection while reading, you can run a WebRTC leak test and compare each candidate against the baseline described below.
01 / Definition
What is a WebRTC leak?
A WebRTC leak occurs when WebRTC exposes or uses a network address or route that bypasses the privacy policy you expected from the VPN or proxy configuration.
The classic case looks like this. Normal browser traffic follows the tunnel:
while WebRTC discovers another path:
If a STUN request leaves through the physical connection, the STUN server returns the source transport address it observed (typically in XOR-MAPPED-ADDRESS). The ICE agent can then form a server-reflexive candidate from that address, allowing the page to learn a public path the VPN was intended to hide.
RFC 8828 calls out this exact multihoming / split-tunnel risk: WebRTC can discover both the VPN-side public address and the ISP-side public address when multiple routes are available. That constitutes a genuine WebRTC privacy failure.
But this is not the same as simply seeing 192.168.1.25, 10.0.0.7, or a TURN relay address. Those results need to be classified first.
02 / Quick answer
Quick answer
| Situation | Leak? | How to interpret it |
|---|---|---|
| Your normal ISP public IP appears while full-tunnel VPN protection is expected | Likely yes | WebRTC may be reaching STUN or a peer through the physical route. |
| VPN public IP appears as the public WebRTC candidate | Usually no | Candidate follows the expected VPN egress. |
| Private address such as 192.168.x.x | Not automatically | This is a local host address, not the ISP-facing public IP. |
| .local / mDNS-style candidate | Not automatically | Browser privacy handling may be obscuring a local address. |
| TURN relay address | Normally no | This is a TURN relay candidate. Its presence does not prove that the relay was selected, and it does not rule out other exposed candidates. |
| Several ICE candidates appear | Not automatically | ICE normally gathers multiple possible paths. |
| Public IPv6 from the normal interface appears | Potentially | IPv6 may be bypassing a VPN that only handled IPv4. |
| Candidate belongs to the VPN interface | Normally no | VPN interfaces are valid ICE interfaces. |
The candidate type matters. So does the interface that produced it.
03 / Model
Why WebRTC needs IP addresses in the first place
WebRTC was built for low-latency real-time communication. A browser attempting to establish a peer connection cannot assume that a single route will work. One endpoint may be behind a home NAT, on IPv6, connected through a VPN, behind a corporate firewall, on Wi-Fi and Ethernet at the same time, or unable to accept direct connections at all.
ICE solves that problem by gathering possible transport addresses and then testing candidate pairs to determine which path actually works. RFC 8445 describes ICE as a mechanism for gathering and testing candidate transport addresses. Those candidates can come from directly attached interfaces, NAT mappings discovered using STUN, or relay servers such as TURN.
From an engineering perspective, this is normal route discovery. From a privacy perspective, it means the browser may learn — and in some cases expose — more network information than an ordinary web request would.
04 / Classification
The four ICE candidate types
When reading a WebRTC leak result, the first thing to establish is the candidate type. ICE defines four.
Host candidate
A host candidate comes directly from an address on the host. That can be an address on Wi-Fi, Ethernet, IPv6, a virtual interface, or a VPN interface. RFC 8445 explicitly states that host candidates can be from logical interfaces, such as VPN interfaces.
A host candidate is not a leak. It may be exactly the address WebRTC should use. The question is which interface it belongs to.
Server-reflexive candidate
A server-reflexive candidate, usually shown as srflx, is a transport address learned through STUN. When NAT is present, it typically represents the public-side IP address and port mapped for that flow.
The browser sends a STUN Binding request from a local candidate. The STUN server returns the source transport address it observed in the XOR-MAPPED-ADDRESS attribute; if NAT translated the flow, that value is the mapped public-side address and port. STUN itself is defined by RFC 8489 and lets an endpoint learn the reflexive transport address seen by the STUN server.
This is often the candidate people associate with a WebRTC public-IP leak. If STUN is reached through your normal ISP interface, the srflx candidate may correspond to the public NAT address of that normal connection. If STUN is reached through the VPN interface, the resulting public candidate may instead correspond to the VPN egress. Same candidate type. Different route.
Peer-reflexive candidate
A peer-reflexive candidate, or prflx, is discovered during ICE connectivity checks rather than during the initial candidate-gathering phase. It can appear when the address observed during connectivity checks does not match any known candidate. This type is useful for ICE operations, but it is not the first signal to use in a basic VPN leak diagnosis. If you see one, classify it correctly before concluding.
Relayed candidate
A TURN server allocates a relayed candidate. TURN exists for cases where direct communication through NAT or firewall policy is not possible or not desirable. The path becomes roughly browser → TURN server → peer instead of browser → peer directly.
RFC 8656 defines TURN as a relay mechanism used when a direct peer path cannot be established or is not acceptable under network policy, including NAT or firewall constraints. A TURN relay address is therefore not the public/NAT egress address of your normal Internet connection. If a leak-test page displays a relay address and calls it your “real IP,” the interpretation is wrong.
05 / Roles
STUN, TURN and ICE are not the same thing
These terms are often mixed. They do different jobs.
- ICE decides which candidate paths to gather, check, and select.
- STUN helps an endpoint learn NAT mappings and perform connectivity checks.
- TURN provides an actual relay when direct paths are unsuitable.
The relationship, roughly:
- ICE
- Host interfaces
- STUN → discover NAT / public mapping
- TURN → allocate relay path
STUN is not, by definition, a VPN bypass mechanism. The host routing table and the interface/socket selected by the ICE agent determine how that STUN transaction leaves the host.
If the STUN transaction leaves through the VPN, the STUN server sees the source address and port presented by the VPN-side path. If it leaves directly over Wi-Fi or Ethernet, the STUN server may instead see the ISP-side public/NAT egress address. That routing decision is what matters during a leak investigation.
06 / Example
A real WebRTC leak scenario
Suppose the host has these routes: the VPN interface is the expected Internet route, while the Wi-Fi interface still has the native ISP path available.
Normal HTTPS traffic follows the tunnel:
But WebRTC candidate gathering reaches STUN through the physical interface:
The STUN server sees the public address allocated to the home connection. Assume, for documentation purposes:
ISP public IP: 203.0.113.25
VPN IP: 198.51.100.44
Those example address blocks are reserved by RFC 5737 for documentation.
If ordinary browsing shows 198.51.100.44 but WebRTC reveals 203.0.113.25, then the browser has exposed a non-VPN public path. In a full-tunnel privacy configuration, that is a WebRTC leak.
07 / Interpretation
What is not a WebRTC leak?
This section matters because WebRTC leak tests often generate false alarms.
A private IPv4 address
Seeing 192.168.1.25 or 10.0.0.14 does not mean your ISP-facing public IP has leaked. Those are local-network addresses. They can reveal something about local network structure, which may have fingerprinting implications, but they are not equivalent to exposing the public IP of your normal Internet connection.
The W3C WebRTC specification notes that ICE candidate addresses can reveal information about local network topology and contribute to fingerprinting. That is a privacy concern. It is not automatically a VPN route leak.
A host candidate from the VPN interface
A VPN adapter is a logical network interface. ICE can gather a host candidate from it. That is expected behavior. If you see a host candidate, identify the interface before calling it a leak.
A TURN address
A TURN relay candidate represents the relay server. It is not your normal public IP. Applications can deliberately force relay-only ICE behavior to reduce address exposure; the WebRTC specification supports iceTransportPolicy: "relay" for this purpose. That can reduce direct address exposure, although it may increase latency and TURN bandwidth usage.
Several ICE candidates
Multiple candidates are normal. A multihomed device can have Wi-Fi, Ethernet, VPN, IPv4, IPv6, and relay options. ICE is designed to evaluate more than one candidate pair. Do not treat candidate count as leak severity.
08 / Browser behaviour
WebRTC and modern browser privacy
Older WebRTC leak discussions often imply that every browser will expose every local IP address to JavaScript. That is too broad today. Browser implementations can apply policies that limit which addresses are exposed to applications.
RFC 8828 defines different IP-handling approaches, including modes that restrict candidate gathering to the default route or force proxy behavior. The W3C specification also recognizes that ICE addresses can expose location and local network information, and allows browsers to apply local policy to reduce address exposure.
You may therefore see an actual IP address, a reduced candidate set, an address represented differently, or no useful local candidate at all. That does not make the test broken. It may be the browser doing exactly what its privacy policy is designed to do.
Why a .local candidate may appear
Some browser configurations can represent local ICE candidates by name rather than exposing raw local IP addresses directly. A test may therefore show something resembling xxxxxxxx-xxxx-xxxx-xxxx.local instead of 192.168.1.25. That should not be interpreted as a public-IP leak.
The WebRTC specification explicitly accounts for candidates that require external resolution, including mDNS candidates. A leak test should classify this as an obfuscated / local candidate rather than labeling it “unknown IP” or “unsafe.”
Camera permission is not required for candidate gathering
WebRTC candidate gathering is not synonymous with camera access. WebRTC also supports data channels and receive-only scenarios. The W3C specification notes that candidate addresses can be exposed to the application without a separate media permission prompt in some WebRTC use cases. So “I never allowed camera access” is not proof that no ICE candidate gathering can occur. The browser’s WebRTC implementation and local privacy policy matter.
09 / Comparison
WebRTC leak vs. IP leak and DNS leak
WebRTC leak vs. IP leak
The two are related but not identical. An ordinary IP leak test asks: which source IP did this web request use? A WebRTC leak test asks: which network candidates can the browser expose or use for peer connectivity?
You can therefore see an HTTP request that shows the VPN IP while WebRTC shows a normal ISP public candidate. That is why a VPN can appear to work in a normal IP checker but fail a WebRTC-specific test. On the other hand, if both tests show the VPN egress, that is a good sign — but it still does not prove that DNS, IPv6, or every application on the host is routed correctly.
WebRTC leak vs. DNS leak
A DNS leak concerns name-resolution policy and the path used to reach DNS infrastructure. A WebRTC leak concerns ICE candidate discovery and connectivity paths. These are separate subsystems.
A system can have correct DNS through the VPN, correct browser IPv4 through the VPN, but an exposed non-VPN ICE candidate. Or the opposite. That is why IPRevealed treats these tests separately rather than reducing them to a single “VPN safe” status.
Related test: VPN Leak Test — compares HTTP, IPv4/IPv6, WebRTC and DNS paths for a conservative multi-signal result.
10 / Address family
WebRTC and IPv6
Do not test only IPv4. If the host has native IPv6 and the VPN does not handle it correctly, ICE may gather or use an IPv6 candidate from the physical interface.
You could therefore have IPv4 → VPN and IPv6 → native ISP, and WebRTC may expose the IPv6 path.
The same principle applies: the appearance of an IPv6 candidate alone is not the failure. The failure is a public non-VPN IPv6 path that violates the expected VPN policy. Link-local IPv6 and globally routable IPv6 should not be treated as the same thing — the IPv6 leak guide covers that classification and the dual-stack routing table in depth.
11 / Policy
WebRTC and split tunneling
Split tunneling makes WebRTC testing more interesting. If the browser itself is excluded from the VPN, WebRTC using the normal interface may be exactly what you configured. If only selected destinations are tunneled, ICE can encounter a routing policy different from the one you assumed.
RFC 8828 specifically recognizes the case in which a split-tunnel VPN and multiple interfaces can enable WebRTC to discover both VPN- and ISP-side public addresses.
So before calling the result a leak, confirm one thing: was the browser supposed to be inside the tunnel? If the answer is no, a native WebRTC path may be expected.
12 / Scope
WebRTC and browser proxies
A proxy and a system-level VPN are not the same networking model. A browser may send HTTP through an application proxy while WebRTC traffic can still use direct network connectivity if policy permits.
RFC 8828 explicitly discusses the risk that WebRTC STUN checks can bypass a traditional application proxy when direct Internet access remains available. This explains why some browser “VPN” extensions do not provide the same protection as a full operating-system VPN. If the product protects only HTTP/S traffic, WebRTC may be outside its scope. That is not necessarily a software defect. It may be a scope mismatch.
13 / Distinction
Candidate exposure vs. candidate selection
There is another distinction worth making. A browser can gather a candidate without ultimately selecting that path for media or data. ICE builds candidate pairs, checks reachability, and selects a working pair.
So two questions matter: what addresses can the page learn? and which candidate pair is actually used?
From a privacy perspective, candidate exposure itself may matter. From a routing perspective, the selected pair indicates which path carries the WebRTC session. These are related questions, but not identical. That distinction is especially useful during advanced troubleshooting.
14 / Method
How to test for a WebRTC leak properly
Do not begin with the VPN connected. Establish the network baseline first.
Record your normal public IPv4 and IPv6 behavior, then run the WebRTC test and note which candidates appear. Pay attention to:
- candidate type;
- public vs. private address;
- IPv4 vs. IPv6;
- and whether the address maps to the normal ISP network or another interface.
Then connect the VPN and repeat the same test. If the VPN is meant to be a full tunnel, the key question is whether a baseline public candidate from the physical connection still appears or becomes usable after the VPN is active.
A browser test that shows only VPN-side public candidates, local/private candidates, or TURN relay candidates does not provide evidence of the classic public-IP WebRTC leak.
Test WebRTC candidates
Run a WebRTC leak test to gather your ICE candidates, then repeat it after connecting the VPN and compare each candidate against the baseline.
Run WebRTC Leak Test15 / Interpretation
How to read a WebRTC leak test
Do not start with the badge color. Start with the candidate.
If the VPN public IP appears
That is normally expected. Check the ASN / provider if you are unsure which network the address belongs to.
If the original ISP public IP appears
In a full-tunnel VPN configuration, investigate. Confirm that the address actually belongs to your baseline connection rather than relying only on geolocation.
If a private IPv4 address appears
Do not label it a public-IP leak. It is local network information.
If a public IPv6 address appears
Compare it with your baseline IPv6. If it maps to the physical connection while the VPN is supposed to handle IPv6, that deserves investigation.
If a relay candidate appears
Identify it as TURN. Do not use the relay server’s IP as your real public IP.
If a .local address appears
Treat it as a browser privacy / host-candidate representation until proven otherwise.
16 / Causes
Common causes of WebRTC leaks
A genuine WebRTC bypass usually comes back to route or candidate policy rather than “WebRTC ignoring the VPN.” Typical causes include:
- a split-tunnel route;
- the browser being excluded from the VPN;
- native IPv6 remaining outside an IPv4-only VPN;
- multiple active interfaces;
- a browser proxy that does not cover UDP / WebRTC traffic;
- a VPN client that does not constrain candidate gathering as expected;
- or a temporary routing change during reconnect.
On multihomed machines, route metrics and prefix specificity matter. Candidate gathering can also bind sockets to specific interfaces, so route metrics alone are not enough; correlate the candidate with the interface and route that produced it. This is the same routing logic an engineer would investigate for any other unexpected traffic path.
17 / Failure modes
WebRTC leaks during VPN reconnects
A leak may exist only during a state transition. The steady state may be perfect, with ICE bound to the VPN interface. Then the VPN reconnects, and for a short period:
The tunnel comes back a second later. A one-time test after everything is stable may never detect it. This is why reconnect, sleep/wake, and network transitions are worth testing when privacy during failure states matters.
18 / Fixes
How to fix a real WebRTC leak
Do not disable WebRTC immediately. First prove what is leaking.
- If the normal ISP public candidate appears, confirm that the browser is supposed to be inside the VPN.
- Then check the VPN’s split-tunnel exclusions and IPv6 handling.
- Try another browser. If the result changes, you may be looking at a difference in browser candidate policy rather than a host routing failure.
- Check for browser extensions or privacy settings that modify WebRTC behavior.
- Make sure that both the browser and the VPN client are updated.
- If the problem occurs only when disconnecting, check the VPN’s kill-switch or fail-closed feature.
- If privacy requirements are strict and the application supports it, relay-only WebRTC through TURN can reduce direct address exposure. The WebRTC API provides
iceTransportPolicy: "relay"for applications that choose this model.
Disabling WebRTC entirely is a last-resort workaround because it can break browser calling, conferencing, and peer-to-peer functionality.
19 / Engineering
How an engineer verifies the WebRTC path
A browser result is useful, but it is not the whole investigation. Begin with the host routing table.
Windows
Get-NetIPConfiguration
Get-NetRoute
route print
Find-NetRoute -RemoteIPAddress <stun-server-ip>
Test-NetConnection -ComputerName <stun-server-ip> -DiagnoseRouting -InformationLevel DetailedThe question is simple: which interface and source address would Windows select for the STUN/TURN destination? If the selected interface is Wi-Fi while the browser is supposed to be fully tunneled through the VPN, you already have a strong clue. This is route-selection evidence, not a STUN protocol test; it does not by itself prove which UDP socket the browser used.
Linux
ip addr
ip route
ip -6 route
ip route get <stun-server-ip>
ip -6 route get <stun-server-ipv6>Then compare the selected source / interface with the VPN route. If needed, use an authorized packet capture to confirm the STUN flow. STUN can be identified at the protocol level; do not assume that every UDP packet from the browser is WebRTC.
macOS
ifconfig
netstat -rn
route -n get <stun-server-ip>
scutil --nwiAgain, you are looking for route selection and interface state. If the browser exposes a suspicious public candidate, the routing table should help explain how that candidate was obtained.
Advanced browser verification
For a real WebRTC session, browser statistics can provide information about ICE candidates and the selected candidate pair. The WebRTC API exposes candidate statistics via RTCPeerConnection.getStats(), and modern WebRTC APIs also expose local/remote candidate information for the selected pair. That allows deeper troubleshooting than simply scraping every candidate gathered during initialization. For production leak testing, be conservative with interpretation: browser support and privacy policy can change what information is exposed.
20 / What it reveals
Does WebRTC reveal your location or local network?
Does WebRTC reveal your exact location?
Not directly. A public IP can be used for IP geolocation, but that is not the same as GPS. A server-reflexive candidate can reveal meaningful network location information by exposing the public NAT mapping of the connection. RFC 8826 explicitly discusses the location-privacy implications of WebRTC candidate addresses. The result may reveal ISP, ASN, country, region, or approximate location. Typically, it does not provide an exact street address on its own.
Does WebRTC reveal your local network?
Potentially, to some degree. Host candidates can contain addresses associated with local interfaces. That can reveal network topology information and increase the browser fingerprinting surface. The W3C WebRTC specification explicitly calls out local-network topology and fingerprinting as privacy considerations associated with ICE candidate exposure. Exposure of local network information and VPN public IP leakage are related privacy issues, but they are not the same event.
Is a private IP address dangerous?
A private address alone does not allow someone on the public Internet to route directly to your machine. Private RFC 1918 addresses are in use across a very large number of networks, so seeing something like 192.168.1.12 does not uniquely identify your home. Local addresses can, however, still be used for fingerprinting and for revealing topology.
So the correct conclusion is not “harmless” and not “your real IP leaked.” It is: local network information was exposed. That is more precise.
21 / Interpretation
Does incognito mode or a kill switch prevent WebRTC leaks?
Does incognito mode prevent WebRTC leaks?
Do not rely on it. Private browsing modes primarily change the behavior of storage, history, and sessions. They do not replace routing policies or VPNs. Whether WebRTC can gather a particular candidate depends on browser policy, network interfaces, and the available routes. Incognito mode is not a WebRTC kill switch.
Does a VPN kill switch prevent WebRTC leaks?
It can help during tunnel failure. If the VPN route disappears, a good fail-closed policy should stop protected WebRTC traffic from falling back to the native interface. But a kill switch does not prove the candidate policy is correct while the VPN is connected. For example, a split-tunnel configuration could still expose a native candidate while the kill switch functions perfectly. Test the steady-state and failure states separately.
22 / Decision
Should you disable WebRTC?
Usually not as the first fix. WebRTC powers legitimate browser functionality including video conferencing, voice communication, and data channels.
Before turning it off, determine whether the browser is actually exposing a public non-VPN candidate. If the only results are private host candidates, VPN candidates, or TURN relay candidates, disabling WebRTC may solve a problem that does not exist.
Where stronger privacy is required, candidate restrictions, VPN routing policy, or TURN relay policy are cleaner solutions than breaking WebRTC entirely.
23 / Checklist
WebRTC leak testing checklist
Before concluding the browser is leaking
- Normal public IPv4 and IPv6 baseline established
- VPN policy identified (full tunnel, split tunnel, browser-only)
- Each ICE candidate classified (host / srflx / prflx / relay)
- Public candidates compared to the baseline network
- Candidate confirmed to belong to the VPN or the physical interface
- IPv6 tested separately
- Split tunneling checked
- Test repeated after reconnect if failure-state privacy matters
- Suspicious results verified against the host routing table
The candidate label alone is not the diagnosis. The route explains the diagnosis.
24 / FAQ
Frequently asked questions about WebRTC leaks
What is a WebRTC leak in simple terms?
A WebRTC leak happens when browser real-time networking exposes or uses a public path that should have remained behind your VPN. The classic example is ordinary web traffic using the VPN while WebRTC reveals the public/NAT egress address of the normal ISP connection.
Can WebRTC reveal my real IP address?
Yes, under some network and browser configurations. If ICE reaches STUN through a physical connection outside the VPN, a server-reflexive candidate can reveal the public NAT mapping of that connection.
Is every WebRTC IP address a leak?
No. A WebRTC candidate may be private, VPN-side, server-reflexive, peer-reflexive, or TURN-relayed. You need to classify the candidate and identify its network path.
Is a private IP in WebRTC a leak?
It is local-network information exposure, but it is not the same as exposing your ISP-facing public IP.
What is a server-reflexive candidate?
A server-reflexive candidate is a transport address learned through STUN; when NAT is present, it normally represents the mapped public-side IP address and port. In a VPN test, the important question is which interface and path were used to obtain it.
What is a TURN candidate?
A TURN candidate is an address allocated on a relay server. Traffic is relayed through TURN rather than via a direct peer path.
Does a TURN IP reveal my real IP?
The relay candidate itself is the TURN server’s relay address, not your normal public IP.
Can WebRTC leak IPv6?
Yes. If native public IPv6 remains outside a VPN, WebRTC may expose or use that IPv6 path even when IPv4 is tunneled.
Can a browser extension VPN stop WebRTC leaks?
It depends on the extension’s scope. A proxy-style browser extension may protect web requests without controlling direct WebRTC connectivity. Check what the product actually promises to tunnel.
Can WebRTC bypass a proxy?
It can when direct Internet connectivity is available and policy permits it. RFC 8828 explicitly considers application-proxy scenarios where WebRTC connectivity can expose the client’s public path.
Do I need camera permission for WebRTC IP exposure?
Not necessarily. WebRTC also supports data channels and receive-only communication, and candidate gathering can occur in scenarios that do not require a camera session.
Why does my WebRTC test show several IP addresses?
ICE is designed to gather several candidate paths. Multiple candidates can come from different interfaces, address families, NAT mappings, or TURN relays.
Why does my browser show .local instead of an IP address?
The browser may be limiting direct exposure of local addresses and representing a local candidate in a privacy-preserving form. That is not automatically a public-IP leak.
Does disabling WebRTC fix a leak?
It can prevent WebRTC from operating, but it is a blunt solution. First determine whether there is a real public non-VPN path and whether routing or VPN configuration can fix it without turning off browser functionality.
Is a WebRTC leak test enough to prove my VPN is secure?
No. WebRTC is one layer. DNS, IPv4, IPv6, application routing, split tunneling, and disconnect behavior need separate verification.
25 / Summary
The bottom line
A WebRTC leak is not simply “WebRTC displayed an IP address.” That definition is too weak. ICE is supposed to discover network candidates. The job of a useful leak test is to determine what those candidates mean.
A private host candidate is not the same as an ISP public address. A VPN-interface candidate is not a bypass. A TURN relay is not your real IP. A server-reflexive candidate can be perfectly normal if the STUN transaction used the VPN path and the observed address corresponds to the VPN egress.
The problem begins when WebRTC exposes or selects a public non-VPN path that violates the routing policy you expected.
So start with a baseline. Identify the candidate type. For public candidates, map the address to the interface and ASN/provider when possible. Then check the route. Diagnosis should focus on the network path rather than solely on the candidate label.
To check your own connection, run a WebRTC leak test while disconnected, record which candidates appear, reconnect the VPN, and compare before concluding. For the wider picture, the VPN leak guide covers IPv4, IPv6, DNS and fail-open behavior alongside WebRTC.
26 / References
Technical references
- RFC 8826
- Security Considerations for WebRTC