Guides
What IP, DNS and IPv6 checks can—and cannot—show
One successful browser check is not a test of every application. A useful diagnosis starts by stating which request was observed and which paths remain unknown.
When this applies
Use this when one IP result is being treated as proof that all traffic, DNS or IPv6 follows the same route.
Checks, in order
Name the tested path
Our tool observes a single HTTPS request to the FreeGuard endpoint. Record its address family and time. Other tabs, applications and routing rules may use a different path.
Separate IPv4 and IPv6 evidence
An IPv4 observation says nothing about an untested IPv6 path, and the reverse is also true. Do not call IPv6 protected or leaking when you have no IPv6 observation.
Separate DNS experiments from the system resolver
A browser request to a chosen DNS-over-HTTPS server tests that HTTPS path. It does not reveal which recursive resolver the operating system or another application actually uses.
Repeat only the relevant scenario
Compare the affected application’s documented network behavior and client routing mode. Change one setting you understand, record it and restore it if the result worsens.
How to interpret the result
The absence of a result is unknown, not proof of a leak. A changed address confirms only that the observed request took a different route; it is not a security audit.
When to stop and ask for help
Stop before disabling a firewall or changing managed DNS. For sensitive work, ask the network administrator for a test plan covering the actual applications and both address families.
Related tool
Explain my IP and networkOfficial references
Based on the linked official documentation, checked 8 September 2026. No client version or device import has been tested for these articles.