A website that refuses to load and a VPN that quietly betrays your destinations look like the same failure from the outside, but they are not related. One is DNS poisoning, where the system that translates domain names into addresses has been fed a false answer. The other is a DNS leak, where the translation itself is accurate but the question was asked through the wrong channel, exposing your browsing habits to your local provider even while a VPN appears to be running. Knowing which one is happening determines whether the fix takes thirty seconds or requires rethinking how your device handles traffic altogether.
The distinction matters more than it might seem, because the two problems sit at opposite ends of the connection process. Poisoning happens before you ever leave your network: something intercepts the request and answers it with a fabricated address before the legitimate server gets the chance. A leak happens regardless of whether the VPN tunnel is active, because the lookup itself travels outside the encrypted path. Users abroad often discover this the hard way, which is part of the reason regulatory shifts matter so much - for anyone tracking regional restrictions, the discussion of what changed for VPN users in Egypt is a useful reminder that local network policy can shape which of these two problems you are more likely to encounter in the first place.
How to Tell Poisoning From a Leak
Poisoning announces itself through inconsistency. Certain sites hang, reset, or throw certificate warnings, while everything else on the same connection behaves normally. Switching to a different public DNS server rarely helps, because the interference happens somewhere along the path, not at the server itself. A clean diagnostic test involves looking up a domain with the VPN off, noting the returned address, then repeating the lookup with the VPN on in full-tunnel mode. If the first address belongs to an unrelated organization or cannot be reached at all, the original answer was almost certainly falsified.
A leak looks entirely different. The VPN connects, the exit IP address checks out on a lookup site, and yet the domains being visited are still visible to the home internet provider. This happens when encrypted DNS settings on the device bypass the tunnel, when a second networking tool runs alongside the VPN, or when IPv6 traffic slips through unprotected. Running a dedicated DNS leak test alongside an IP lookup tool is the only reliable way to separate the two: the exit address test answers "where do I appear to be," while the leak test answers "who actually knows what I'm asking for."
Fixes Range From Partial to Complete
- Changing the DNS server only helps if the provider's own resolver is broken - it does nothing against answers inserted mid-route.
- Encrypted DNS protocols such as DNS-over-HTTPS prevent tampering in transit but cannot guarantee the resolved address is reachable.
- Routing both the lookup and the traffic through the same tunnel resolves both problems simultaneously, since the answer and the visit originate from the same trusted point.
- Editing a hosts file to hardcode an address works only as a short-term patch and breaks the moment the real address changes.
Full-tunnel routing remains the most dependable approach precisely because it collapses two separate attack surfaces into one. When resolution happens at the far end of an encrypted connection, there is no local network segment left for an attacker to intercept or a provider to observe.
Reputation Scores and Split Routing Confuse the Picture
Two further sources of confusion deserve mention. An IP "cleanliness" score, sometimes called a fraud score, rates how ordinary an address looks to a given website - shared VPN exits score lower simply because many people use them, not because encryption is weaker. Separately, split-routing setups can make two lookup tools disagree entirely by design: a domestic site sees your home connection while an international one sees the VPN exit, and both readings are correct for what they measure. Geolocation databases themselves also vary between providers, so a single address showing different cities on different tools is normal, not evidence of a malfunction.