The Setting You Changed That Didn't Actually Change Anything

You tap through three menus, type in 1.1.1.1 or 9.9.9.9, and feel the small satisfaction of having done something. Privacy nudged upward. Tracking nudged down. Then you run a DNS leak test and watch your queries sailing out through your carrier's servers anyway, calm as you like.

So what happened?

Your router, your carrier, or your operating system quietly overruled you. There are a few specific mechanisms involved, each working differently, and knowing which one is winning the argument changes what you can actually do about it.

How DNS Is Supposed to Work (and Where the Chain Breaks)

Every time you tap a link, your phone translates a domain name into a numbered IP address before it connects. That translation request goes to a DNS resolver: normally whoever your network assigns by default, your home router forwarding to your ISP, your mobile carrier, or a corporate network's internal server.

Configuring a DNS server manually tells your device to skip the default and send those translation requests to a specific address instead. Simple enough in theory.

Three things can intercept that request before it ever leaves your network.

Transparent DNS proxies. Many home routers and virtually all mobile carriers run a proxy that listens on port 53, the standard DNS port. Any outbound packet aimed at port 53 gets grabbed and redirected to the carrier's own resolver, regardless of the destination IP you specified. Your phone thinks it's talking to 1.1.1.1. It's actually talking to a server two hops away that belongs to your carrier. The response comes back correctly formatted, so nothing looks broken. You'd never know without running a test.

DHCP-pushed DNS settings. When your phone joins a Wi-Fi network, the router hands it an IP address via DHCP, and bundled into that handshake is a list of suggested DNS servers. On many Android builds and some network configurations, those DHCP-pushed servers quietly take priority over what you typed manually, depending on which settings screen you used. There are two different places to configure DNS on Android: per-network in Wi-Fi settings, and system-wide under Private DNS. They don't always talk to each other the way you'd expect.

Captive portal detection. iOS and Android both periodically send probe requests to check whether they're behind a captive portal (a hotel login page, an airport Wi-Fi gate). These probes sometimes bypass your configured resolver entirely to reach Apple's or Google's own detection endpoints. A narrow use case, but it adds DNS traffic that ignores your rules.

The Scenario Worth Walking Through

Picture two people, Priya and Marcus, who both set 9.9.9.9 as their DNS server on the same Android phone model, running the same OS version.

Priya went through Settings > Wi-Fi > (long press her network) > Modify Network > Advanced > DNS. Marcus went through Settings > Network > Private DNS and typed in dns.quad9.net.

Priya's traffic still leaks to her ISP's resolver at home. She configured per-network DNS over plain UDP, and her router's transparent proxy intercepts port 53 traffic. On mobile data, same story.

Marcus's traffic doesn't leak. Private DNS on Android uses DNS-over-TLS (DoT), which runs on port 853 rather than 53. Transparent proxies aimed at port 53 can't touch it. The traffic is also encrypted, so even if something on the network tried to read it, the contents are opaque.

Same phone. Same intention. Completely different outcomes, because of which settings menu Marcus used.

Does your own setup look closer to Priya's? Most guides that say "just change your DNS" don't specify which of the three or four places to change it, and only one of them actually routes around the interception.

What People Consistently Misread About This

The most common misconception is that configuring a DNS IP address equals actually using that server. It doesn't. An IP address is a destination. Whether your packets reach it depends entirely on whether anything in the middle decides to redirect them first. The IP you typed is less a route and more a suggestion left on a fridge that nobody reads.

People also assume this is always malicious. It mostly isn't, and the reality is more depressing than a conspiracy: carriers intercept DNS partly to enforce parental controls sold as a service, partly to serve their own analytics, and partly because their network architecture was built before privacy-focused DNS protocols existed. The effect on your privacy is real. The motivation is usually just banal infrastructure inertia.

A third misread: VPNs always fix this. Some do. A VPN that tunnels all traffic including DNS, with leak protection on, will typically bypass transparent proxies because the DNS query is wrapped inside the encrypted tunnel and exits from the VPN provider's network. But VPNs with split tunneling enabled, or apps that implement their own DNS outside the tunnel, can still leak. "I have a VPN" is not the same as "my DNS is protected."

The Settings That Actually Hold

Three approaches reliably survive transparent proxy interception.

First: Android's Private DNS, the hostname-based DoT option, not just typing an IP. Use the hostname format your resolver publishes. Cloudflare is one.one.one.one, Quad9 is dns.quad9.net, NextDNS gives you a unique hostname when you create an account. This works on mobile data and Wi-Fi both.

Second: DNS-over-HTTPS configured at the browser level. Firefox has offered this for years under Settings > Privacy & Security > DNS over HTTPS. It only covers browser traffic, but if browser-based tracking is your main concern, it handles the job without touching system settings.

Third: a properly configured VPN where DNS is tunneled through the encrypted connection and the provider explicitly doesn't leak. This covers all apps, not just the browser, which matters if you care about what your other apps are quietly resolving in the background.

The setting you changed in Wi-Fi's IP configuration screen, the one that just takes a raw IP address, is decorative. On most modern networks with transparent proxying enabled, it changes nothing.

The infrastructure was built by people who assumed they'd always be the ones answering your questions. They weren't wrong to assume it. They just didn't expect anyone to check.