A website that refuses to load and a website that quietly reports your location to someone it shouldn't are not the same failure, even though both can feel identical from behind the keyboard. One stops you from arriving anywhere at all. The other lets you arrive while telling a third party exactly where you went. Understanding which problem you actually have determines whether changing a setting fixes anything or wastes an afternoon.
Every visit to a website starts with a question nobody notices: which numerical address belongs to this name. That question, a DNS lookup, is normally sent in plain text to whatever server your internet provider or router has assigned. Because the exchange is unencrypted, anything sitting on the path between your device and that server can read the question and race to answer it before the legitimate server does. When that race is lost on purpose, by a filtering system or a compromised link, the result is DNS poisoning: the name resolves to an address that has nothing to do with the real site. A properly configured VPN changes this picture by handling resolution and traffic together, with modern tools designed for consistent behavior across platforms, covering every device from the router down to a single phone, so the question never has a chance to be intercepted on the home network.
DNS leaks sit on the opposite side of the same coin. Here the lookup gets a genuine answer, but the question was asked through the wrong channel. The VPN connection shows as active, the exit address looks correct, yet the local provider is still the one resolving domain names, which means it can still see, and log, every site a user intends to visit. A streaming service abroad can sometimes work out a user's real country from this alone, even while the displayed IP address suggests otherwise. The two faults require opposite diagnostic instincts: poisoning is confirmed by checking who owns the IP address a name resolves to, while a leak is confirmed by checking who is doing the resolving in the first place.
Why the Fixes Are Not Interchangeable
Switching to a public DNS server is the most common reflex and the most commonly disappointing one. It only helps when the fault lies with the provider's own server, such as a stale cache. It does nothing when the false answer is being inserted mid-journey, because the interception happens regardless of which server is asked. Encrypted DNS protocols, DNS over HTTPS and DNS over TLS, close that gap by wrapping the question in a secure channel so it cannot be altered in transit. That solves the asking half of the problem but not necessarily the reaching half: an address can be correct and still be unreachable. The structurally complete fix is to route both the lookup and the subsequent connection through the same encrypted tunnel, so the name is resolved at the far end by a server with no incentive to lie, and the visit itself departs from that same far end.
Hosts file edits, pinning a domain to a known-good address by hand, belong in the stopgap category. They break the moment a service changes its infrastructure and cannot realistically cover more than a handful of sites. They are worth knowing about for emergencies, not as a standing practice.
Reading the Results Without Jumping to Conclusions
Verification is procedural rather than mysterious. An IP-lookup site reveals the exit address a connection presents to the outside world; a DNS leak test reveals which servers are actually answering name queries; an IPv6 test catches a channel that split-tunnel configurations frequently forget to cover. None of these tools agree with each other by default, and that is often by design rather than error. Split-routing setups deliberately send domestic traffic out directly and foreign traffic through a tunnel, so a domestic lookup tool and an international one will legitimately report different locations for the same device at the same moment. Geolocation databases themselves disagree, too, since each lookup service maintains its own mapping of addresses to places and updates it on its own schedule, so two sites showing two different cities for one address is routine rather than alarming.
An IP "cleanliness" or reputation score belongs to a separate conversation entirely. It measures how a destination website perceives the address, based on whether it sits in a data-center range, whether it has been flagged in a proxy database, and how many other users share it. It has no bearing on encryption, logging, or privacy protection. A low score produces more CAPTCHAs and occasional refusals, not exposure. The practical response is switching regions rather than treating the number as a verdict on the connection's safety.
When a Phone's Own Settings Undermine a Router
One recurring and easily missed cause of both false leak readings and broken routing is a device quietly managing its own encrypted DNS, through a browser setting or an operating system feature such as Android's Private DNS. A router depends on seeing which domain a device is requesting in order to decide whether that request should travel abroad or stay local. A device that encrypts its own queries independently removes that visibility, and split routing starts misbehaving in ways that look like a leak but are actually a configuration conflict. Disabling secure DNS at the device level while connected to a home network that already encrypts traffic at the router resolves this without sacrificing protection, since the router is doing that job already.