Provider-neutral self-test pilot
Private Internet Access describes its network as IPv4 only and blocks IPv6 rather than carrying it, which is why an IPv6 leak test on PIA should normally come back empty. Two other things set it apart on these checks: its apps are published as open source, and its advanced kill switch keeps blocking traffic even when the app is not running. What you get back describes your session; it is not an audit of PIA.
Live test
Private Internet Access runs an IPv4-only network and blocks IPv6, so the IPv6 line below should normally come back empty.
Current-session checks
Read each signal once on your ordinary connection and once connected. On PIA the two lines that repay attention are IPv6, which should go quiet, and the resolver, because MACE changes what DNS answers look like.
Before you read the result
The points below are taken from PIA's own feature pages and help desk. They describe the behaviour a normal reading reflects.
PIA describes its service as operating exclusively on IPv4 and lists aggressive IPv6 blocking as a feature, on the grounds that traffic it cannot carry should not be allowed out. An empty IPv6 result while connected is therefore the intended behaviour here, and an IPv6 address belonging to your own connection is the reading worth chasing.
PIA's MACE is a DNS-level blocker: when a domain is on its list, the resolver answers with 127.0.0.2, which points back at your own machine so the request never leaves. That is useful to know when reading a DNS check, because a loopback answer is MACE doing its job rather than a broken resolver.
PIA documents a kill switch that blocks traffic when the connection drops, and an advanced kill switch that blocks all traffic outside the VPN even when the VPN is turned off. Which of the two you have on decides whether anything could have escaped in the gap that a failed check is reporting.
PIA's desktop Split Tunnel lets you mark individual applications Bypass VPN so they connect directly, and exclude individual addresses or whole subnets. On Windows and Linux there is a further setting for whether DNS requests follow those rules or always use PIA's own DNS. A browser marked Bypass VPN will report your own address, correctly.
PIA publishes its applications as open source alongside the WireGuard and OpenVPN protocols they use, so the client behaviour behind these readings can be inspected rather than taken on trust. That does not extend to WebRTC or fingerprint values, which your browser generates locally and no VPN client rewrites.
Between the readings
Private Internet Access documents a kill switch that blocks traffic when the connection drops, and an advanced one that keeps blocking even when the app is not running. The gap between those two behaviours is measured in seconds.
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
PIA describes its network as IPv4 only and lists aggressive IPv6 blocking as a feature. An IPv6 check that returns nothing while connected is the expected outcome of that design.
That is PIA's MACE feature. It filters at the DNS layer and answers blocked domains with 127.0.0.2, an address that points back at your own machine, so the request is never made.
PIA describes the advanced kill switch as blocking all traffic outside the VPN even when the VPN is turned off, where the standard kill switch acts when a live connection drops.
Check Split Tunnel first. PIA lets you mark an application Bypass VPN so it connects directly, and on Windows and Linux there is a separate setting for whether DNS follows those rules. A browser on the bypass list is behaving as configured.
PIA publishes its applications as open source, along with the WireGuard and OpenVPN protocols they build on. That makes the client side of these checks inspectable; it says nothing about what happens on the servers.
Confirm which kill switch is enabled, restart the browser so it drops cached connections, and rerun the focused DNS, WebRTC and IPv6 tools before drawing a conclusion from one reading.