VPNs, proxies, extensions and WebRTC

Published 2026-10-24

People use VPNs and privacy extensions to hide their address, and then find that video calls get worse or that a test page still shows their real address. Both observations are correct, and both come from how WebRTC works. This article explains why calls behave differently behind a VPN or a proxy, what WebRTC can reveal, what the standards say about the trade-off, and how to check your own configuration.

Why WebRTC sees more than a website does

When your browser loads an ordinary web page, the server sees one thing about your network: the public address the request came from. A WebRTC call needs more. To find a path to the other person, the browser collects every address it could be reached on and hands the list to the call page. RFC 8828, the document that sets out how WebRTC must treat IP addresses, explains the effect: gathering connectivity information can pass several addresses, both private and public, to a web application, which can reveal more about the user's network than a normal request does.

That is useful to the call, because a direct path needs real addresses, and it is a privacy concern when you expect a VPN to hide everything. The standard names three situations. With a VPN that does not route all traffic, the browser can find the address your internet provider assigned in addition to the address of the VPN, which defeats the purpose of using the VPN. Behind a NAT, private addresses can be learned, which can be used as a fingerprint. And with a proxy, STUN requests can sometimes bypass the proxy and show the client's public address. The document calls the VPN case the most significant.

What the standard lets browsers do

RFC 8828 defines four modes for how much a browser reveals, and the trade-off is explicit.

Mode 1 uses every network interface. It gives the best media path but reveals the most, and the standard says it must not be used without the user's consent.
Mode 2 uses the default route plus the private addresses on that interface. Media generally follows the same path as web traffic, and direct connections stay possible. This is the default when no consent exists.
Mode 3 uses the default route only and shares no private addresses. It discloses less, but it can force traffic through relays, make calls hairpin through the NAT, or fail.
Mode 4 forces media through the proxy used for web traffic. It hides your addresses, but proxies usually lack UDP support, so media falls back to TCP with lower quality.

The pattern is clear: more privacy costs call quality or call reliability, and which point on the scale is right depends on your needs. A person who must hide their location from the other party needs a different setting than a person who simply wants a smooth meeting.

What a VPN does to a call

The VPN may route everything through a server in another city or country. That adds distance and delay to media that would otherwise take the shortest path.
Some VPNs block UDP, or send only web traffic through the tunnel. The browser then finds no good path, or finds the real network as well as the VPN, depending on the configuration.
Your public address as the other person's browser sees it can be the VPN's address, your own, or both.
Free VPNs are often overloaded, which shows up as freezing pictures and robotic sound.
Some corporate VPNs deliberately let media bypass the tunnel (split tunnelling) so calls run well. RFC 8828 notes that some corporate users want exactly that.

If a call that works on your home network gets worse with a VPN switched on, turn the VPN off for that call, or choose a nearer server. If you need the VPN on for privacy, use audio only or lower the picture quality to reduce load.

What a proxy does

A proxy forwards web traffic on your behalf. It usually carries browser requests but not UDP media. A call from behind a proxy therefore tends to use TCP, with more delay and less resilience, or fails to connect if no TCP route to a relay exists. As the standard points out, STUN traffic may also skip the proxy, so a proxy does not by itself guarantee that the other party never sees your address.

What browser extensions can do

Privacy and blocking extensions can restrict which candidates WebRTC may gather. This hides addresses, and it can also stop calls from connecting.
Some extensions interfere with the camera or microphone, for example by blocking device access for a site you did not expect.
Ad blockers can block a call service's scripts or domains, which looks like a call page that loads and then does nothing.
Extensions that rewrite headers or traffic may break the signalling that sets up a call.

The quick check is a private window with extensions off, or a second browser profile without extensions. If a call works there, switch your extensions back on one at a time until it breaks.

How to test your own setup

Run the WebRTC connectivity test on this site with the VPN off. Note the verdict and the type of candidates.
Turn the VPN on and run it again. If the public addresses in the table change to the VPN's, WebRTC is using the tunnel. If you still see your provider's address, some traffic is leaving outside the tunnel.
Use the option to hide most of each address if you want to take a screenshot, and remember that you are the only person who sees the table; the page does not send addresses anywhere.
Compare with a website that shows your public address, and with your VPN provider's own leak test, if it has one.
Run a real call to a friend with and without the VPN, and compare the quality.

If you want to restrict what WebRTC reveals, look for the setting in your browser, in your VPN application or in a reputable extension, and read the provider's documentation, because the names and the effects differ. After any change, repeat the test and make a real call. A setting that hides everything but breaks calls is usually not what you wanted.

A short checklist

Decide what you need: a smooth call, or maximum privacy, or a balance.
For smooth calls, leave the VPN off or choose a nearby server with UDP allowed.
For privacy, accept that quality may drop, and test before relying on it.
Never assume that a VPN hides everything from WebRTC; verify.
Keep your browser updated, since privacy behaviour in WebRTC has changed over the years.

About ChatLite

The connectivity test on this site shows only on your own screen which addresses your browser offers, so you can compare your setup with and without a VPN before an important ChatLite call.

References

Official documentation used to check this article. Pages are maintained by their owners and may change.

Reviewed against ChatLite's current behavior on 2026-10-24.