Provider-neutral self-test pilot
NordVPN handles IPv6 by shutting it down rather than carrying it: its own documentation describes blocking the IPv6 interface and rerouting IPv4 only. That single decision explains most of what an IPv6 leak test shows here. It also runs its own DNS servers, and it ships two different kill switches that behave differently. Treat the output as a description of your own session rather than an assessment of NordVPN.
Live test
NordVPN blocks the IPv6 interface rather than carrying it, and answers DNS from its own resolvers, so those are the two lines to read first.
Current-session checks
Take one reading on your normal connection and one connected. On NordVPN the IPv6 result should go quiet by design, so the lines worth studying are the resolver that answered and what WebRTC exposed.
Before you read the result
Each point below is taken from NordVPN's own blog and support articles. They set out what a normal reading is supposed to look like.
NordVPN describes IPv6 leak protection as blocking the IPv6 interface so that only IPv4 traffic is rerouted and encrypted. An IPv6 check that returns nothing while you are connected is therefore the documented outcome. An IPv6 address that still resolves to your own connection is the reading that needs investigating.
NordVPN separates an internet kill switch from an App Kill Switch, which closes named applications when the connection drops. NordVPN's support pages state that the App Kill Switch is off by default on desktop, while on mobile the kill switch is enabled by default and is not exposed as its own setting. Knowing which one you have on changes how you read a failed check.
NordVPN operates its own DNS servers, and Threat Protection filters domains at that layer against reputation databases and phishing detection. NordVPN also notes that Threat Protection overrides a custom DNS setting, so if you pointed the app at a resolver of your own and the DNS check does not show it, that feature is the first thing to look at.
NordVPN documents its own DNS server addresses, 103.86.96.100 and 103.86.99.100, in its support material. That gives the DNS check on this page something concrete to be measured against: a resolver answering from those addresses is NordVPN's, and one answering from your ISP's range is not, without any need to infer it from the result.
WebRTC candidates and fingerprint values are produced by the browser. With the whole system routed through the app they should carry the tunnel address, but an extension, a virtual adapter or split tunnelling can change that. Nothing on this page inspects NordVPN's servers - only what your browser reveals in this session.
Between the readings
NordVPN separates an internet kill switch from an App Kill Switch, and its support pages put the App Kill Switch off by default on desktop. Which of them was covering this browser shows up in the seconds after the tunnel address disappears.
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
NordVPN documents IPv6 leak protection as blocking the IPv6 interface and rerouting IPv4 only. An empty IPv6 result on this page is therefore the expected reading rather than a sign the test failed.
NordVPN's support pages state that the App Kill Switch is off by default on desktop, while on mobile the kill switch is enabled by default and is not shown as a separate option in settings.
NordVPN publishes 103.86.96.100 and 103.86.99.100 as its own DNS servers in its support material, which gives you a fixed reference to compare the resolver in your result against.
NordVPN notes that Threat Protection overrides a custom DNS setting because the filtering happens on NordVPN's own DNS servers. Turning that feature off is the usual reason a custom resolver reappears.
No. These checks read what your browser exposes in one session. Logging happens on the provider's side and cannot be observed from a browser test, whatever the result looks like.
Confirm the app is connected and the kill switch you rely on is the one that is enabled, restart the browser to drop cached connections, then rerun the focused DNS, WebRTC and IPv6 tools.