Quick answer
A VPN is doing its basic job when websites see the VPN server's public IP instead of the public IP you had before connecting. That is only the first check. A useful verification also looks for a second public address exposed through WebRTC or IPv6. DNS requires a separate controlled test and should not be marked “safe” unless the test actually observes DNS queries.
Our repeatable VPN check
Use the same browser and network for the before-and-after comparison. Avoid changing Wi-Fi networks halfway through the test because that can change your public IP independently of the VPN.
- Record the baseline. Disconnect the VPN and open CheckWhatIsMyIP. Note the public IP, ISP or network name, and approximate location.
- Connect the VPN. Choose a server, wait until the app reports a connection, then reload the IP page.
- Compare the result. A conventional consumer VPN should normally replace the public IP visible to the website with the VPN exit IP.
- Run the leak check. Open our VPN Leak Test to compare the normal web-visible IP with WebRTC candidates and check for separate IPv6 exposure.
- Interpret, do not overclaim. A changed IP proves that traffic reaching this page is using a different public address. It does not prove that every protocol, application, DNS query, or device on your network is protected.
What each result actually proves
Public IP changed
This is the strongest basic signal that web traffic is exiting through a different network. If the IP does not change, confirm that the VPN is connected, reload the page, and check whether the VPN app is configured for split tunneling.
WebRTC check
WebRTC uses ICE candidates to establish real-time peer connections. Candidate information can contain network addresses, although modern browsers also apply privacy protections such as local-address obfuscation. The important comparison is whether the browser exposes a different public address from the one the page sees normally. MDN documents that ICE candidate addresses can reveal network information and may be relevant to fingerprinting. Read the WebRTC candidate documentation at MDN.
IPv6 check
Some networks provide both IPv4 and IPv6. If your VPN changes IPv4 but leaves a separate public IPv6 route outside the tunnel, a site that supports IPv6 may still see that address. A dual-stack connection is not a leak by itself; the issue is whether the IPv6 path bypasses the privacy setup you intended to use.
DNS check
A trustworthy DNS leak test must cause DNS queries to unique domains controlled by the tester and observe which resolvers receive them. A normal browser page cannot infer a conclusive DNS pass just from your public IP. Our current leak page therefore labels DNS as not directly tested rather than claiming “No Leak.”
How to read the result
- Different public IP + no separate public WebRTC/IPv6 address: the checks available on this page did not find an IP exposure.
- Same IP before and after: verify the VPN connection or split-tunneling rules.
- Different public address through WebRTC or IPv6: review your VPN/browser configuration before relying on it for IP privacy.
- No WebRTC candidates: this can be a browser privacy behavior or disabled WebRTC; it is not proof that the VPN itself is working.
Why we separate “VPN active” from “no leaks detected”
VPN detection databases can classify IP ranges as VPN, proxy, residential, mobile, or hosting networks, but those classifications are imperfect and change over time. For that reason, we treat the before-and-after IP comparison as direct evidence and database labels as supporting context rather than absolute proof.
Run the check
Run the VPN & WebRTC Leak Test
Methodology note: the current tool checks the normal public IP, WebRTC candidates and separate IPv6 exposure. It does not operate authoritative DNS test domains, so it does not claim a conclusive DNS result.