Self-Hosting / Networking

Pi-hole — Reviewed Mid-Deployment on a Real Home Network

Pi-hole's pitch is simple: a small self-hosted DNS server that blocks ads and trackers for every device on your network, no per-device app or browser extension required. I deployed it on a dedicated container to replace/supplement my router's own DNS filtering — this is what that process actually looked like, including a router-level gotcha and a finding about container health checks that's changed how I evaluate "is this actually working."

What this is, and isn't: this deployment is currently paused before going fully live — deliberately, for reasons explained below, not because anything failed outright. There's no "months of daily use" verdict here yet. What follows is real hands-on deployment experience, a genuine architectural gotcha worth knowing about if you're on a UniFi network (or any router with its own DNS filtering), and an honest account of a problem this evaluation itself uncovered. I'll follow up once it's actually carrying production DNS traffic.

What Pi-hole actually is (and isn't)

Pi-hole is a DNS server that answers most queries normally and returns a blocked/null response for domains on its blocklists — mostly ad networks and trackers, sourced from large, actively-maintained community lists (the same style of list browser extensions like uBlock Origin use, just applied at the network's DNS layer instead of per-browser). Point your router's DHCP-assigned DNS server at it, and every device on the network gets ad/tracker blocking without installing anything — including phones, smart TVs, and IoT devices that could never run a browser extension in the first place.

Why not just use my router's built-in filtering?

Most consumer/prosumer routers with any content-filtering feature (UniFi included) do something different: category-based filtering — block "Adult Content," "Malware," a fixed list of buckets — not general ad/tracker blocking. Three real differences matter here:

Coverage. A router's content-filter categories don't touch ad networks or trackers at all — that's simply not what the feature is for. Pi-hole's blocklists are specifically curated for exactly that traffic.
Visibility. Pi-hole gives you a real dashboard: every query, every client, what got blocked and why, over time. A router's content filter is typically a blunt on/off toggle per category with no query-level log at all.
Control. Custom block/allow lists, per-client rules, and the ability to see exactly why something got blocked when a site breaks — none of which a fixed category system gives you.

They're not really competing products — a router's content filter is aimed at parental-control-style category blocking, Pi-hole is aimed at ad/tracker suppression with real visibility. If you want both, you need to think about how they coexist, which turned out to be the first real decision point in this deployment.

The deployment itself: straightforward

Pi-hole's Docker image is genuinely easy to stand up — a single container, host networking so it can bind DNS's standard ports directly, a web admin panel on the usual HTTP(S) ports. No complex config needed to get it answering DNS queries correctly from its own local network segment. If the story ended there, this would be a short, boring, entirely positive review.

The real gotcha: your router might already own port 53, silently

If your router has its own DNS-based content filtering enabled, simply pointing a client's DNS at Pi-hole may not work — and the failure mode is confusing. On a UniFi network specifically, enabling DNS filtering on a given network transparently intercepts all outbound port-53 traffic on that network and redirects it to the gateway itself, regardless of what DNS server a client thinks it's using. I confirmed this with a real packet-level test: ICMP and plain HTTP requests to the Pi-hole box worked fine (so it wasn't a routing or firewall problem in general), while DNS queries — both UDP and TCP on port 53 — timed out completely, even though Pi-hole's own resolver was correctly bound and listening on every interface. The router was quietly eating the DNS traffic before it ever reached the box.

This is worth knowing before you spend an hour debugging Pi-hole itself, because nothing about Pi-hole is broken in this scenario — it never even sees the query. If clients on a UniFi (or similar) network aren't resolving through Pi-hole despite correct DHCP/DNS settings, check whether the router's own DNS filtering is enabled on that network segment first, before assuming a Pi-hole-side misconfiguration.

The coexistence question, if you also use built-in content filtering for something real

If your router's content filtering is doing real work already — parental controls on a specific network, for instance — don't just disable it as a side effect of adding Pi-hole. That's a decision worth making deliberately, not something to stumble into. The real options are: run Pi-hole only on the network segments that don't already depend on the router's filtering, replace the router's filtering with something Pi-hole-based everywhere (more consistent, more work), or hold off until you've decided which. There's no universally correct answer here — it depends entirely on what the existing filtering is actually protecting.

Why this deployment is currently paused

Beyond the coexistence question above, I'm holding off on actually redirecting network DNS to Pi-hole until some unrelated network topology changes land first (new switching hardware, some interfaces getting re-cabled). Pi-hole becomes a single point of failure for DNS on whatever network segment it serves — that's a reasonable thing to want sitting on settled infrastructure, not infrastructure that's about to change out from under it. Nothing about that pause reflects on Pi-hole itself.

A finding this review itself surfaced: don't trust "the container is running"

A container reporting healthy uptime is not the same claim as "this service actually works." While auditing this deployment, I checked Docker's own health-check status on the Pi-hole container — something I hadn't specifically looked at before, since the box had been sitting quietly with no complaints — and found it had been reporting unhealthy for essentially its entire uptime, failing its own internal DNS self-check the whole time. The container process itself was alive and had never crashed or restarted; it just wasn't reliably able to resolve anything through its own upstream, which a plain "is it running" check would never catch.

The lesson generalizes past Pi-hole specifically: a container that's up, hasn't crashed, and isn't throwing errors in its logs can still be functionally broken in a way only its own health check (if it has one, and if you actually look at it) will tell you. docker ps showing a container as running is a much weaker claim than it feels like — check docker inspect for the actual health status, not just whether the process is alive.

Verdict (so far)

Everything about Pi-hole's actual value proposition holds up on paper and in the parts I've tested directly: it does something a router's content filter genuinely doesn't (real ad/tracker blocking with real visibility), it's simple to deploy, and it's lightweight enough to justify a small dedicated container just for this. But this evaluation also turned up two real, non-obvious problems before it ever went fully live — a router that silently eats the exact traffic Pi-hole needs to see, and a container that looked fine by every surface-level signal while its own health check said otherwise the entire time. Both are fixable and neither is a knock against Pi-hole's core design, but they're exactly the kind of thing "just deploy it and it'll work" advice tends to skip. Full verdict once it's actually carrying real traffic — follow-up to come once the network topology work it's waiting on is done.