Pi-hole is one of the most popular privacy-focused local solutions for a cleaner browsing experience. When I set up my homelab server, I implemented Pi-hole to get a complete privacy solution. My main focus was on fewer ads, trackers, and better control over my network. A clean Pi-hole setup solved the ad and tracker problem, but once I started digging into how DNS actually worked, I noticed the setup was missing something.

Pi-hole was blocking and filtering everything locally, but as soon as it left my network, the view of what was happening on it was open. From my router to my ISP, or any intermediary in between, I could see every DNS request my devices made, including the websites and services they accessed. Instead of replacing Pi-hole, I started searching for the fix. That was when I came across DNS over HTTPS (DoH), and the obvious solution was Cloudflare DNS over HTTPS proxy, but Cloudflare deprecated its proxy-DNS method in late 2025, so it was no longer an option.

Rather than settling for another Cloudflare alternative, I fixed the missing layer by encrypting DNS upstream using a self-hosted solution.

What Pi-hole gets right (and where it falls short)

Blocking ads isn’t the same as hiding traffic

Pi-hole is easy to set up and works well for most users who just need ad and tracker blocking. You just need to set it up once, add it as your DNS, and you can forget about it. Pi-hole intercepts each domain request your device makes, cross-checks it against the blocklist, and then lets it pass. This works for most users because it provides a cleaner, faster browsing experience, and the story ends here.

But this is where the misunderstanding begins.

Pi-hole doesn’t change how DNS works. It’s just a watchman. When your device requests a domain, it passes through the Pi-hole, and the Pi-hole decides whether to block the request or forward it. Once Pi-hole clears the domain, it forwards the request upstream to a DNS resolver. And for most users, that upstream communication is handled via standard DNS (usually on port 53). That’s where the issue begins: that traffic is not encrypted.

Pi-hole does an excellent job of filtering the requests it resolves, but it doesn’t hide what's leaving your network. Once the request is forwarded, your router, your ISP, and any intermediary can see what your device has requested. Some might confuse Pi-hole’s filtering with what DNSSEC does. DNSSEC only ensures that responses are delivered to the requester without tampering. With DNSSEC, the request and response are safe but not private.

The privacy gap most setups ignore

Your ISP can still see everything

Pi-hole blocks bad requests, but it doesn’t encrypt traffic. Once requests leave your network, they are still sent in plain text. Your ISP can see those plaintext messages and what your device has requested, such as the websites you visited and the services you used. They can't see the content of those requests, like the specific pages or full URLs, but they can see what services you use, when you’re online, and how frequently you access certain platforms.

Most people will argue that public resolvers, such as Cloudflare and Google DNS, will solve this problem. But they don’t. You are just changing the resolver to a public DNS provider, but not how it travels, or whether it's encrypted. You are moving from the standard DNS resolver to a public provider; the process remains the same, and the path remains unsecured.

Pi-hole can clean up what you connect to, but it still falls short of hiding it from your ISP or any intermediary. That distinction matters more than most people realize.

Fixing it with DNS-over-HTTPS (the right way)

A small upgrade that actually closes the loop

I was in a similar situation. I installed Pi-hole on my homelab server and configured it as the DNS resolver for my entire network. All the devices were using the self-hosted solution to block ads and filter out bad requests. Overall, it looked fine, but Pi-hole was still leaking DNS to all the intermediaries and both my ISPs. The obvious solution was to look for a Pi-hole replacement or VPN, but neither solved the actual problem. Pi-hole alternatives were working on the same path, i.e., the same upstream problem, and using a VPN all the time wasn’t reliable.

That’s when I decided to stay with Pi-hole but to upgrade to the upstream layer. The problem was with the upstream DNS, so I tried fixing how Pi-hole resolved DNS in the first place. The simple solution was to implement Cloudflare DNS over HTTPS proxy, and it could have worked in my case, but it was deprecated a few months ago (late 2025). This led me to a self-hosted solution, dnscrypt-proxy, instead of hunting for another cloud-based alternative.

The setup was easy enough. I deployed it alongside Pi-hole via Portainer on Docker, and it worked as a local encryption layer. Running it was easy, but not as straightforward as many tutorials suggested. Initially, I tried configuring it using a .toml file, but that failed due to resolver source issues. But later, I switched to environment-based configuration via Docker Compose environment variables, and it was far more reliable than TOML configuration.

Now, Pi-hole was doing what it was supposed to, blocking ads and trackers, while dnscrypt-proxy handled how queries were sent upstream. Instead of plain DNS over port 53, everything was wrapped inside HTTPS. Meaning, everything leaving my network looked like regular traffic, but it was now encrypted.

Once it was up and running, I simply replaced Pi-hole’s upstream DNS servers with dnscrypt-proxy#5053 (or 127.0.0.1#5053), and that was it. No more per-device config was needed since I had already updated DNS in my dual-WAN gateway (I run a dual-WAN router, so Pi-hole was already set network-wide). Nothing was changed from the outside, and all the devices worked as expected. Under the hood, all the DNS traffic was now encrypted, and no one, not even my ISP, could see what domains my device was querying.

There was one trade-off I noticed just after setting it up. Since dnscrypt-proxy was hosted on my server, if the server went down, DNS would go down with it. I had two solutions: either add another Pi-hole with dnscrypt-proxy on another server, or add a publicly available DNS provider as a fallback. Both solutions were a little difficult in my case, but the goal was to keep the network usable most of the time, even if that meant sacrificing strict privacy for those moments.

Your DNS was never really private

Pi-hole worked exactly as it was advertised. It blocked ads and filtered out all requests, but it was never a complete privacy solution. It worked locally and blocked the connection I was trying to make, but it didn’t control who could see those connections. Meaning, once the requests were outside my network, everything was visible to the ISP or any intermediary.

Adding DNS-over-HTTPS filled that gap and encrypted all my connections. With a reliable solution like Cloudflare DNS over HTTPS proxy no longer available, it wasn’t as plug-and-play as I'd hoped, but I achieved similar results by self-hosting dnscrypt-proxy on my local server.

It’s a small upgrade, but it changes what your network actually exposes.