MIYAIP TOOLS
Use this IP and Browser Environment Check to compare the public IPv4 and IPv6 paths visible to your browser with DNS, WebRTC, network ownership, reverse DNS, and local browser facts.
Local browser checks
Checks run in this browserBrowser facts and the local digest are neither uploaded nor stored.
The public IPv4 or IPv6 address seen by a website identifies a network exit, not a precise device location. Country, region, city, ISP, organization, ASN, reverse DNS, and approximate coordinates describe that exit using current network data.
VPNs, proxies, carrier gateways, mobile networks, and cloud relays can place the public exit in a different region from the browser. Treat location as an estimate and network ownership as a separate fact.
The page compares IPv4, IPv6, DNS resolver, WebRTC, reverse DNS, proxy-related headers, and browser facts as separate evidence. A path difference is a reason to review the setup, not automatic proof of a leak, and an unavailable check is not proof that the setup is safe.
VPN split tunnelling, enterprise DNS, Anycast, privacy relays, browser policies, and extensions can all create legitimate differences. Repeat the check after changing one setting so the effect is easier to isolate.
DNS resolver addresses indicate which public resolver path answered the browser-side check. WebRTC candidates show only the addresses the browser exposes under its current privacy and network policy; modern browsers may hide local candidates or replace them with hostnames.
Documented DNS resolver and WebRTC public IP fields can be submitted for server-side comparison. Local browser facts and the browser summary remain on this device, and the page still shows a partial local result if server analysis fails.
Read every result with its source and limitation. The browser initiates IPv4, IPv6, DNS, and WebRTC observations because a backend can see only its own network paths, not the device and connection currently in use.
MiyaIP presents evidence separately instead of producing an anonymity score. Use the dual-stack test for protocol reachability and the proxy anonymity checker for server-observed proxy-header evidence.
A web request necessarily exposes enough network information for a server to return a response. Separate browser probes can also reveal whether IPv4 and IPv6 work, which public DNS resolvers answer a test, whether WebRTC produces public candidates, and whether local browser settings align with the observed network.
MiyaIP combines server-observed and browser-observed signals for comparison. A mismatch is a prompt to investigate, not proof of a leak or malicious software. Corporate networks, split-tunnel VPNs, privacy relays, mobile gateways, browser hardening, extensions, and blocked probe hosts can all produce legitimate differences.
Judge the result against the connection you intended to use. The same observation can be normal on a direct ISP connection and unexpected while a full-tunnel VPN is active.
| Result pattern | Possible meaning | Next action |
|---|---|---|
| Normal for the setup | IPv4 or IPv6 exits match the expected provider; DNS and WebRTC do not expose an unexpected public network. | Record the result if needed and repeat after any network change. |
| Possible leak or split route | The main request uses a VPN, but DNS resolvers or a WebRTC public candidate belong to the direct ISP. | Confirm the VPN mode and repeat with extensions disabled before changing settings. |
| Needs review | IPv4 and IPv6 use unrelated networks, proxy headers appear, or the location and ASN are unexpected. | Check each protocol separately and verify whether a proxy, relay, enterprise gateway, or mobile handoff is intentional. |
| Information incomplete | A probe times out, is blocked, or produces no result. | Treat the signal as unavailable; retry on another network or browser rather than interpreting absence as safety. |
A controlled comparison is more useful than a single screenshot. Keep the browser, device, and test conditions constant so the VPN state is the main variable.
A DNS leak usually means domain queries leave through a resolver outside the privacy route you expected. Resolver geography alone is insufficient: large encrypted DNS services use distributed addresses, and enterprise policies may intentionally route DNS differently. Compare ownership and VPN documentation, then confirm with more than one lookup if the decision matters.
A WebRTC leak concern arises when a public candidate identifies a network path that should have been hidden by the VPN or proxy. Local candidates are not the same as public exposure, and some browsers replace local addresses with mDNS names. Because a failed STUN request also produces no public candidate, “none detected” means only that this probe observed none.
First confirm the intended VPN or proxy is connected, then test IPv4 and IPv6 separately. Next review split-tunnel and kill-switch settings, reconnect to another server, and inspect the configured DNS mode. Update the browser and VPN client, temporarily disable conflicting extensions, and repeat the check. If the unexpected ASN or resolver persists, save the timestamps and result details before asking the provider or network administrator to investigate.
FAQ
It shows public IPv4 and IPv6 addresses, network owner, approximate location, DNS resolver path, WebRTC candidates, reverse DNS, proxy-related headers, and local browser facts. MiyaIP presents these signals separately instead of turning them into one anonymity score.
Backend requests see only the application server's DNS, WebRTC, and network paths. Checks initiated in the current browser are needed to describe the device and network you are using.
No. Public DNS, Anycast, enterprise gateways, and proxies may use resolvers in other regions, so the page reports a different path without directly concluding that it is a leak.
Each signal has different limits and reliability. Combining them into one score can create false certainty, so MiyaIP shows observed evidence, trigger conditions, and unavailable checks separately.
No. Browser facts and the locally generated browser summary are not sent to the aggregation interface or saved as history. Only the documented network observation fields are used for server-side comparison.
The network may not provide IPv6, a browser policy or extension may block the probe, or the probe may be temporarily unreachable. Use the IPv4/IPv6 dual-stack test to check again independently.
Ordinary requests expose the public route, not a private RFC 1918 address. Browser real-time communication may gather candidates, but modern browsers often restrict or mask local addresses. Treat any displayed candidate according to whether it is private, mDNS, or public.
The address families can use different provider blocks, gateways, databases, or VPN routes. Query both addresses individually and compare their ASN and organization before assuming the device is in either displayed city.
No. Anycast and distributed resolver services can make geography misleading. Compare the resolver owner and intended VPN or encrypted DNS configuration, then repeat the test.
MIYAIP
Create an account to manage proxy products, or review rotating residential proxy pricing first.
