Turning on a VPN should mean that websites see the VPN server's address instead of yours. Most of the time that is exactly what happens. But it is worth checking, because browsers have one feature in particular, WebRTC, that can reveal network addresses in ways people don't expect.

This guide explains what an IP address is, what it says about you, how a WebRTC leak happens, and how to test your own setup step by step.

What your IP address reveals

An IP address is the number that identifies your connection on the internet. There are two kinds you will come across:

  • Public IP address. The address the rest of the internet sees. At home it usually belongs to your router and is assigned by your internet provider. On mobile data it belongs to your carrier's network.
  • Local (private) IP address. The address your device has inside your home or office network, such as one starting with 192.168 or 10. It is not reachable from the internet, but it can still help to fingerprint a device.

Your public IP doesn't give a website your name or street address, but it usually points to your provider and an approximate location, often a city or region. Websites can use it to estimate where you are, and combined with cookies and other signals it becomes part of a profile.

Step 1: Check your public IP

Open our What is my IP tool. It shows the public IP address your browser connects from, plus the approximate location and network owner associated with it. It also shows a simple status:

  • Safe means your traffic is arriving from a VPNRice server.
  • Exposed means the site is seeing an address that isn't a VPNRice server, which is usually your real connection.

Do this twice: once with your VPN off and once with it on. Write down or remember the first address. With the VPN on, the address and location should change to those of the VPN server.

If you want details about any other address, such as one you found in a log file, use the IP lookup tool. It shows the country, region and network registered for that address. Location data comes from DB-IP and is approximate by nature.

Step 2: Understand WebRTC

WebRTC is the browser technology behind video calls, voice chat and some file sharing done directly in a web page. To connect two people efficiently, WebRTC tries to find the shortest network path between them. The process it uses is called ICE, defined in RFC 8445.

ICE collects "candidates", which are possible addresses where your device can be reached. MDN's documentation of the RTCIceCandidate interface lists the main types:

  • Host candidates are your device's own addresses on its network interfaces.
  • Server reflexive candidates are your public address as seen by a STUN server. STUN, described in RFC 8489, is a simple protocol that tells a device what address it appears to have from the outside.
  • Relay candidates are addresses on a relay server that forwards traffic when a direct path isn't possible.

A web page can ask the browser to gather these candidates, and JavaScript on that page can read them. That is the root of the issue: if the browser includes an address that doesn't go through your VPN, the page can learn it.

What a WebRTC leak looks like

A leak happens when a WebRTC candidate shows an address you expected to be hidden. Common cases:

  • Your real public IP appears as a candidate while your VPN is on. This can happen if the browser sends the STUN request over a network path outside the tunnel, or if IPv6 traffic isn't covered while IPv4 is.
  • Your local IP address is exposed. This is less serious but still adds information for fingerprinting.

The IETF has written down how browsers should behave. RFC 8828 defines four modes for handling IP addresses in WebRTC, from enumerating all addresses (Mode 1) to forcing all traffic through a proxy (Mode 4). It says Mode 1 must not be used without user consent and that, without consent, browsers should use Mode 2, which only exposes default-route addresses. Many modern browsers also replace local addresses with random names ending in ".local", so pages see a placeholder instead of the private address.

In practice this means a properly working system-wide VPN usually prevents leaks, because the default route goes through the tunnel. Problems tend to come from split setups, browser-only proxies, or IPv6 not being handled.

Step 3: Run the WebRTC leak test

Open our WebRTC leak test. The test runs in your browser, asks it to gather ICE candidates for a few seconds and shows you every address it found. Then it compares them with the public address your connection is using. It doesn't contact any third-party STUN server, so it only shows host candidates (often hidden as .local names). That means it can reveal local-address exposure, but it cannot detect a public IP leaked through a STUN request.

Run it with your VPN on and read the results like this:

  1. Only the VPN server's address appears, or no public address appears at all. No leak.
  2. A ".local" name appears. That is the browser hiding your local address. Not a leak.
  3. A public address that isn't the VPN server appears. Treat this as exposure.
  4. A private address like 192.168.x.x appears. Minor exposure. Consider the browser settings below.

How to fix a leak

Try these in order, testing again after each one:

  • Use a system-wide VPN app instead of a browser-only proxy. Browser extensions that act as proxies send web requests through another server, but WebRTC traffic doesn't always follow proxy settings. A full VPN app routes the default route through the tunnel. VPNRice's apps on Android, iPhone and iPad, and Windows work this way; the Chrome and Firefox extensions are browser proxies that route your browser's traffic through VPNRice servers (they don't add encryption themselves; sites you open over HTTPS stay encrypted end to end).
  • Reconnect the VPN and reload the page. Candidates are gathered when the page asks for them, so a page loaded before the VPN connected may show stale results.
  • Check IPv6. If your network has IPv6 and the leak shows an IPv6 address, make sure your VPN covers it, or test on a network without IPv6 to confirm the cause.
  • Turn on a kill switch. A kill switch stops traffic leaving your device without the tunnel. On Android, VPNRice's kill switch relies on Android's Always-on VPN setting together with blocking connections without VPN.
  • Restrict WebRTC in the browser. Some browsers have settings or policies that limit which network interfaces WebRTC may use. Firefox users can change WebRTC options in about:config. Disabling WebRTC entirely will break video calls in the browser, so treat that as a last resort.

A quick checklist

  • Check your IP with the VPN off, then on. The address should change.
  • Look for the Safe status on the What is my IP page.
  • Run the WebRTC leak test with the VPN on.
  • Repeat after browser updates or when you change networks.
  • Use the IP lookup tool when you want to understand an unfamiliar address.

These tests take less than a minute and show you the main things your connection reveals. VPNRice's tools run in your browser or on VPNRice's own service, with no third-party trackers or cookies.

If you'd like a VPN that protects your whole device, not just the browser, download VPNRice and run the tests again with it switched on.