Compare public IP, IPv6, DNS, and WebRTC before and after connecting Falemon, then fix browser, proxy, and network-interface conflicts.
A test page showing an IP address does not automatically prove a leak. Start with a disconnected baseline, connect Falemon, and compare public IP, DNS resolver, IPv6, and WebRTC candidate information separately. A diagnostic site necessarily sees connection data, so use reputable tools and never post an unredacted result publicly.
Information reviewed: 2026-09-01
Record a disconnected baseline
Disconnect Falemon and every other proxy. With a trusted test, record the public IPv4 address, whether IPv6 is present, the network operating the DNS resolver, and the time. Do not rely on city labels alone; geolocation databases can be stale.
Quit and reopen the browser, disable proxy extensions that could alter the result, and keep only one active network path. Simultaneous Wi-Fi, Ethernet, and hotspot interfaces make the comparison harder to interpret.
Record IP, IPv6, DNS operator, and time Close other VPNs, proxy extensions, and capture tools Keep only the network interface under test active
Check four data types after connecting
Connect Falemon, wait for the route to settle, and repeat the test in a fresh private window. The public IP should differ from the baseline, and DNS should not continue to be resolved by the original ISP. If the system uses IPv6, confirm that it follows the expected path.
WebRTC creates candidate addresses for real-time browser communication. A page may show private LAN addresses, mDNS names, or public candidates. The key question is whether the same baseline public address appears—not whether any local address is visible.
Compare connected public IP with the baseline Check whether DNS still belongs to the original ISP Compare WebRTC public candidates with the baseline address
Repeat tests to eliminate cache and false positives
Run the check in two browsers and two reputable services, then change to another Falemon node and repeat. DNS cache, privacy extensions, encrypted DNS on the router, and corporate policy can produce apparently conflicting single-test results.
A mismatch between a node label and the city shown by an IP database is not sufficient evidence. Stronger evidence is an unchanged public IP or DNS queries that consistently remain with the original ISP after connection.
Use at least two browsers and two test sources Repeat the same checks on another node Compare addresses and network ownership, not only city labels
Fix the smallest scope first
Restart the browser and Falemon, disable proxy or privacy extensions, and return system proxy and DNS settings to automatic. Next, disconnect unused interfaces and restart the device. Avoid changing firewall, route, registry, and DNS settings all at once.
If only one browser fails, reset that browser’s network and WebRTC-related extensions first. If every browser produces the same result, investigate the operating system, router, or managed-network policy. Send support the OS and client versions, node, network type, and redacted before/after results.
Start with browser extensions and competing proxies Then reset system proxy, DNS, and unused interfaces Redact test records and never send passwords or full account data
Frequently asked questions
Is seeing a private 192.168.x.x address automatically a leak?
Usually not. A private LAN address alone does not prove that public traffic bypassed the expected route. Focus on whether the disconnected public IP reappears.
Why does the IP database show a different city from the node label?
IP geolocation is not real-time and may show an operator registration location. Compare network ownership, multiple sources, and the actual connection state.
Will changing to a public DNS fix every leak?
No. Extensions, system proxies, IPv6, multiple interfaces, and router policy can also be responsible. Identify the affected layer before changing it.
Next steps
References
View the complete troubleshooting library, or organize the information to contact the support team