Provider-neutral self-test pilot
hide.me is one of the few providers here that carries IPv6 rather than switching it off, and that changes how you read an IPv6 leak test: an IPv6 address in the result is not automatically a problem. Its own Linux client documents IPv6 tunnelling, a default set of hide.me resolvers, and leak protection built on the routing subsystem rather than a simple on-off toggle. Anything you see here describes your own session rather than hide.me's infrastructure.
Live test
hide.me tunnels IPv6 rather than switching it off, so an IPv6 address below is not automatically a fault. Compare it against the visible IPv4 line.
Current-session checks
Read the signals once before connecting and once after. On hide.me the IPv6 line needs the most care, because an address there may mean the tunnel is carrying IPv6 exactly as documented.
Before you read the result
The points below come from hide.me's own published client documentation, which is unusually specific about how leak protection is implemented.
hide.me's published Linux client lists IPv6 support among its features and exposes an option to use IPv6 tunnelling only, and it documents the server as providing both IPv4 and IPv6 addressing on connect. So an IPv6 address in your result may be the tunnel working. The question to ask is whose network that address belongs to, not whether it exists.
Because both address families can be live at once, the useful comparison on hide.me is between them. If the IPv4 exit and the IPv6 address point at the same provider network, that is consistent with a dual-stack tunnel. If the IPv6 address belongs to your own ISP while IPv4 does not, that is the mismatch worth acting on.
hide.me's client ships with its own DNS servers configured as the default for client requests rather than deferring to whatever the network hands out. A DNS check while connected should therefore stop naming your ISP's resolver. Which resolver actually answered is exactly what the DNS tool on this page reports.
hide.me describes its leak protection, the equivalent of a kill switch, as based on the routing subsystem: it installs a dedicated routing table and policy rules so that traffic is selectively routed rather than merely blocked after a drop. A check that shows your own address is a prompt to look at that configuration rather than at the browser.
hide.me publishes its Linux client as source code, which is how the details above can be read rather than taken on trust: the resolver defaults, the IPv6-only tunnelling option and the routing-table approach to leak protection are all visible in the repository. What happens on the server side stays outside both the source and this page.
Between the readings
The checks above read one instant of a hide.me session. A reconnect is a stretch of seconds, and whether your own address surfaced somewhere inside it is a different question from what any single reading returns.
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
hide.me's published client documentation lists IPv6 support and an IPv6-only tunnelling option, and describes the server as providing both IPv4 and IPv6 addressing. IPv6 is carried rather than switched off.
Not on its own. Because hide.me tunnels IPv6, the meaningful test is whether the IPv6 address belongs to the provider network or to your own connection. A match with the IPv4 exit is the reassuring case.
hide.me's client sets its own DNS servers as the default for client requests rather than using whatever the local network supplies. The DNS check on this page reports which resolver actually answered for your browser.
hide.me documents leak protection built on the routing subsystem, using a dedicated routing table and policy rules to control which traffic can leave, rather than a simple block-after-drop switch.
Some of it. hide.me publishes its Linux client as source, so the resolver defaults, the IPv6 tunnelling option and the routing rules are readable. Server behaviour is not, which is the gap a browser check like this one partly fills.
A VPN changes the network path, not the browser. Screen metrics, fonts, language and similar values are reported by the browser itself, so they normally read the same before and after connecting.