Provider-neutral self-test pilot
Three things PureVPN publishes change what these checks return. Its feature list says it automatically disables WebRTC no matter which browser you use, that all DNS requests are sent only through its private, encrypted DNS servers, and that IPv6 leak protection stops traffic leaving the tunnel when you reach an IPv6 website. The fourth is a caveat it published itself: a September 2025 security advisory for its Linux clients, GUI 2.10.0 and CLI 2.0.1, describing IPv6 traffic that could leak after suspend or Wi-Fi toggles while the app still showed as connected. What follows describes your own session, not PureVPN's servers.
Live test
PureVPN states that it disables WebRTC automatically whatever browser you use, so the WebRTC line below is the one its own feature list speaks to. Read the resolver next: PureVPN says DNS requests go only to its private, encrypted servers.
This browser session
This reports what your browser shows in this session. It does not certify PureVPN, does not test every server, app or device, and does not prove anonymity.
Current-session checks
Take every reading twice, once on your normal connection and once connected. On PureVPN the WebRTC and IPv6 lines carry the most information, because both follow from protections PureVPN describes in its own words.
Before you read the result
Each point below comes from PureVPN's feature pages and its own security advisory. Knowing the intended behaviour first is what lets you separate an ordinary reading from one worth chasing.
PureVPN's feature list says it automatically disables WebRTC no matter what browser you are using. That is a claim the WebRTC check on this page reads directly. With PureVPN connected, a public candidate that matches your own connection is the case the claim does not cover, and worth noting together with the browser and app version you used. A local or private candidate is a different signal and not, on its own, an exposure of your public address.
PureVPN describes IPv6 leak protection as stopping your traffic from leaving the VPN tunnel if you connect to an IPv6 website. Read the IPv6 line with that in mind: an IPv6 address that belongs to your own network while you are connected is exactly the reading the feature exists to prevent, and the first one to look at when something seems off.
PureVPN says that all your DNS requests are only sent through its private, encrypted DNS servers. A DNS check taken while connected should therefore name infrastructure other than your ISP. Your provider's resolver, or a public resolver you configured yourself, appearing in that line is the result the claim rules out, and the one worth a second run.
In September 2025 PureVPN published a security advisory for its Linux GUI 2.10.0 and CLI 2.0.1. It describes IPv6 traffic that may leak after suspend or Wi-Fi toggles while the app still shows as connected, and a client that replaces existing iptables rules, including those set by UFW or Docker, on connect without restoring them after disconnect. It states that Windows, macOS, Android and iOS are not affected, and it targeted fixed Linux clients for mid-October 2025. On Linux, run the IPv6 check after waking the machine as well as after connecting.
PureVPN describes split tunnelling as sending some traffic through the VPN and the rest through your regular internet connection, and offers port forwarding together with a static dedicated IP. Both change what a check can show. A browser left outside the tunnel reports your own address by design, and a dedicated address stays the same from one session to the next, so compare the address you see with the one your account lists before reading it as a fault.
Between the readings
PureVPN describes its kill switch as instantly disconnecting your internet if the VPN drops. On Linux its own advisory adds a narrower case, IPv6 traffic leaving after suspend or a Wi-Fi toggle while the app still showed connected. A single reading cannot tell you how long either gap lasted.
Safe Copy exports use safe summary categories and remove raw IP, exact city, full user-agent, raw fingerprint data, raw resolver IPs and WebRTC candidates. It is not a certificate, provider audit, or proof of anonymity.
FAQ
PureVPN says it automatically disables WebRTC no matter what browser you are using. The WebRTC check on this page shows whether a public candidate from your own connection is visible in your session, which is the case that claim is meant to exclude.
PureVPN states that all DNS requests are sent only through its private, encrypted DNS servers. The DNS check here reports which resolver actually answered for your browser, so your ISP's resolver appearing there is worth investigating.
PureVPN published an advisory in September 2025 for its Linux GUI 2.10.0 and CLI 2.0.1: IPv6 traffic may leak after suspend or Wi-Fi toggles while the app still shows as connected. Until a fixed client is installed, it advises disabling IPv6 on Linux, reapplying firewall rules after disconnecting and using IPv4-only connections where possible.
PureVPN's advisory states that Windows, macOS, Android and iOS are not affected and limits the issue to its Linux clients. The IPv6 check on this page is still the quickest way to confirm what your own device does.
The same advisory describes it: on connect, the Linux client replaces existing iptables rules, including those set by UFW, Docker or custom configurations, and does not restore them after disconnect. PureVPN's workaround is to reapply your firewall rules after disconnecting.
PureVPN describes it as instantly disconnecting your internet if the VPN drops. When a check reports an address you did not expect, confirm that setting first, then whether split tunnelling left this browser outside the tunnel.