What Is a WebRTC Leak? How to Test and Block It

A WebRTC leak is unwanted address exposure through a browser's real-time communication features, such as an original public IP appearing when you intended to use a VPN exit. A private address or an mDNS name is not the same finding: classify the candidate first, then decide whether the behavior conflicts with your policy.

Key Takeaways:

• Compare public candidates with both your original connection and the VPN exit.
• Private addresses, mDNS names, and relay addresses have different meanings.
• Browser controls involve privacy and call-quality tradeoffs; settings are not identical across browsers.
• Retest an actual call after a restriction, and restore it if necessary communication fails.

What does a WebRTC leak expose?

WebRTC supports real-time audio, video, and data exchange. To find a working path, ICE collects candidates representing possible endpoints. The addresses made available to a site can reveal information beyond the address used for an ordinary page request; the actual set depends on browser behavior, permissions, network configuration, and policy.［1］

A candidate is an available path, not proof that a call selected it. A diagnostic may list several candidates even when a relay carries the media. Separate “this address was exposed to the page” from “this interface carried the call”: both can matter, but they require different evidence.

The diagram groups candidates by what they describe. It is a conceptual guide, not a screenshot or a result measured against a VPN. Use it to label your observations before calling an address a leak.

Candidate observation	What it describes	Interpretation
Private local address	A local endpoint behind a router or private network	Local information; not automatically your original public IP
mDNS hostname	A name used to mask a local host candidate	Not itself a revealed numerical public address
Public address matching the baseline	A possible endpoint on the original connection	Investigate unwanted public exposure while connected
Public address matching the VPN exit	A possible endpoint using the observed VPN exit	Compatible with that observation; not complete device proof
Relay address	A relay endpoint used as a candidate	Not automatically the address of your access provider

What should you record before a WebRTC leak test?

Use a trusted network and a device you are permitted to configure. Record browser name and version, operating system, VPN configuration, proxy settings, active interfaces, and whether the page has microphone or camera permission. Permissions can affect candidate exposure, so a comparison that changes them halfway is not controlled.

Choose a diagnostic that reports candidate types and does not demand unrelated account credentials or uploads. You do not need to grant camera access merely because a site calls itself a privacy test. If the diagnostic needs a permission to reproduce your normal call conditions, make that choice deliberately and document it.

A page that reports no candidates may be blocked, broken, or restricted. That is not equivalent to proving that all applications are protected. For overall connection health, start with the broader VPN test sequence, then use this article for candidate interpretation.

How can you test and classify the addresses?

1. Record the original public exit. With the VPN disconnected, check the public IP and record available address families. Run the WebRTC diagnostic in the same browser and save candidate types privately. Do not post full addresses or device identifiers.
2. Build a VPN-connected reference. For an AethoVPN comparison, choose a currently available location, connect, and verify the web exit before collecting candidates again. That gives you two public references to distinguish in the browser result; it is not a claim that the service filters WebRTC. Mac, iPhone, and iPad configuration requires Pro or Premium.［6］ If you need that comparison, start the 3-day Pro trial, available once per user.［6］
3. Repeat with unchanged conditions. Keep the browser, network, permissions, and diagnostic constant. Classify each result as private local, mDNS, public, or relay. Compare any public address to the original exit and the VPN exit, using address-family-specific records where available.
4. Investigate the relevant mismatch. An original public address appearing while connected merits route and browser-policy review. A private local address or mDNS name alone does not establish the same exposure. If you cannot determine the category, mark it uncertain and seek documentation instead of changing every privacy setting.
5. Apply a supported browser restriction. Record its previous value and scope, change one supported control, and restart the browser if required by its documentation. Use the browser-specific differences below; do not assume a switch exists because a tutorial for another browser lists it.
6. Retest privacy and communication. Repeat candidate collection and make a non-sensitive test call with the service you actually need. Check audio, video, connection establishment, and stability. If the restriction breaks necessary communication, restore the recorded setting and consider a supported relay or network policy with the administrator.

Repeat the relevant comparison after a browser update or network change. A result from one browser profile or Wi-Fi network is not a certificate for the entire device. The point is to reproduce a defined unwanted exposure, then demonstrate how a specific supported change affects it.

How do Chrome, Firefox, Edge, and Safari differ?

Chrome controls are policy and extension interfaces

Chrome documents webRTCIPHandlingPolicy through its privacy API, including disable_non_proxied_udp. This is an extension-facing control, not a promise that every Chrome build has a matching Settings checkbox. A policy or another extension can control a setting, so the displayed request and effective value may differ.［2］

Do not install an unknown “leak blocker” just to obtain that control. Inspect the publisher, permissions, maintenance, and current documentation. Restricting non-proxied UDP can affect the available media paths, so validate a real call rather than relying on a green diagnostic badge.

Firefox exposes its own network privacy API

Mozilla documents WebRTC network properties, including IP handling policy and peer-connection control, for extensions. These are browser-specific interfaces, and their supported behavior must be checked against the installed version. They do not justify copying undocumented about:config recipes or treating every preference as a stable user-facing setting.［3］

Disabling peer connections is broader than hiding an address: it can disable functionality needed by a call or browser data channel. Choose a restriction consistent with your requirements, preserve the original value, and test the communication service after applying it.

Edge managed policy has a defined platform scope

Microsoft documents WebRtcIPHandlingUrl for administrators to apply IP-handling policy to matching URLs. The policy is supported on desktop Edge from version 135 and is not listed as supported on Android or iOS. It is a managed deployment control, not a universal mobile instruction.［4］

On an organization-managed browser, ask the administrator about effective policy and URL matching. Do not try to bypass that management or assume that a Chromium-family browser inherits every Chrome interface unchanged.

Safari requires evidence for the installed release

WebKit's 2017 engineering explanation describes its approach to candidate exposure and permission-related differences. It is useful historical context, not proof of every current Safari default. No current universal user switch is established by that source, so this workflow does not invent one.［5］

Test the installed Safari release and document its permission state. If an unwanted public address appears, seek current platform or administrator guidance. Do not equate denied camera permission with a guaranteed block of all candidate gathering or with device-wide VPN coverage.

When should you block WebRTC rather than preserve calls?

Choose based on the task. If you never need browser calls or data channels in a particular profile, a supported restrictive policy may be an acceptable tradeoff. If you rely on meetings, a blanket disable can be more disruptive than a narrowly managed route or relay policy.

A VPN and a browser restriction act at different layers. Changing a browser policy is not evidence that a provider has a WebRTC feature, and a successful page IP test is not evidence of browser policy. Use the DNS route guide for resolver observations and the IPv6 checks when the mismatch involves a second address family.

Keep a small record: baseline public addresses, connected public addresses, candidate categories, browser version, permissions, old and new setting, and call outcome. If a page produces no usable candidates, label the diagnostic inconclusive rather than congratulating yourself on a hidden address. If an authorized correction cannot be identified, stop and escalate.

Use the trial decision worksheet to record whether the remaining exposure fits your needs. For the relationship between a tunnel, browser, and application security, return to the VPN fundamentals.

Summary

• Classify candidates before deciding whether the original public address was exposed.
• Keep the browser, permissions, and network constant during comparisons.
• Use supported controls for the actual browser and platform.
• Verify both candidate behavior and a real call, with a documented rollback.

FAQ

Is a private address a WebRTC leak of my public IP?

No. It can disclose local network information, but that differs from exposing the public address of your original internet connection.

Does an mDNS name reveal the original public address?

Not by itself. It represents a local host candidate differently; compare public candidates separately before claiming the original internet address was exposed.

Does a relay candidate mean the VPN failed?

No. A relay address identifies a relay endpoint. Determine its type and compare the appropriate public references instead of treating every unfamiliar address as a failure.

Can blocking camera permission solve every WebRTC leak?

No. Permission state can influence behavior, but it does not prove that candidate gathering or every network path is blocked across all browsers.

Should I disable WebRTC completely?

Only if the supported control and its functional cost fit your needs. Full restrictions can prevent meetings and browser data channels, so keep a rollback.

Are browser privacy settings identical on desktop and mobile?

No. APIs and managed policies have platform and version limits. Follow documentation for the installed browser rather than copying a desktop recipe to a phone.

Why should I test a call after an address check?

A privacy restriction may change media paths or prevent connection. A successful diagnostic result alone does not show that necessary audio and video still work.

Disclaimer: Test only authorized devices and networks. A browser result describes its recorded version, permissions, and configuration, not every application on the device.

Sources

1. RFC 8828 — WebRTC IP Address Handling Requirements
2. Chrome — browser.privacy API
3. Mozilla — privacy.network
4. Microsoft Edge — WebRtcIPHandlingUrl policy
5. WebKit — A Closer Look Into WebRTC
6. AethoVPN — Official website

Sources checked 5 October 2026.

Related Articles

• Record the trial decision
• Distinguish DNS routing symptoms
• Compare both address families
• Check the complete connection