Pi-hole Not Blocking Ads: How to Diagnose It

“Pi-hole is not blocking ads” describes at least six unrelated faults, and the reason people go round in circles on it is that they start by adding blocklists. Adding lists is the last step, not the first, and it is the step most likely to create a new problem.

The useful move is to work the ladder in order. Each rung is a question with a definite answer, and each one eliminates a whole class of cause. Stop at the first rung that fails.

Step 0: define what “not blocking” means here

Three symptoms that get reported identically and share almost nothing:

• Nothing is blocked, on every device. Something structural is wrong: blocking is off, the service is down, or nobody is querying it.
• Nothing is blocked on one device. That device is not using Pi-hole, or a group rule exempts it.
• Most things are blocked but ads still appear on specific sites or apps. Usually not a fault at all. See the last section.

Answering this before touching anything eliminates most of the wasted effort.

Step 1: is blocking actually on?

pihole status

This reports the running state of DNS and blocking. The specific trap: pihole disable accepts a duration, so pihole disable 5m re-enables itself and pihole disable without one stays off indefinitely. A disable issued from the web interface days ago, or a scripted disable that never got its matching pihole enable, presents exactly as “Pi-hole stopped working.”

If the service itself is not running, nothing further on this list matters. Fix that first.

Step 2: are queries arriving at all?

This is the highest-value single check, and it settles the difference between a filtering problem and a routing problem.

pihole tail

Watch the live log while loading a page on the device in question. Two outcomes:

• Queries from that device appear. Pi-hole is being used. Skip to step 6.
• Nothing appears from that device. Pi-hole is not being used. Steps 3 to 5 are your problem, and no amount of blocklist work will change anything.

The device-level query log in the web interface answers the same question if you prefer clicking. Either way, the point is to confirm the traffic path before debugging the filter.

Step 3: what DNS server are clients actually being handed?

The post-install documentation is direct about the three options: configure the router so DHCP clients get Pi-hole as their DNS server; or, if the router will not allow that, disable DHCP on the router and use Pi-hole’s own DHCP server; or, as a last resort, set each device manually.

The failure that hides longest is listing Pi-hole alongside a public resolver as a secondary. Clients are free to use either at any time, so blocking works intermittently and appears to depend on the site, the time of day or the phase of the moon. It is not a fallback arrangement; it is a coin flip. List one resolver, or list two instances that both filter.

Plenty of ISP-supplied routers silently ignore a custom DNS entry, or advertise themselves as the resolver no matter what you type. Check what a client actually received rather than what the router’s page claims it sent. If the router cannot be made to comply, moving DHCP to Pi-hole is the documented answer.

Step 4: check IPv6 separately

A network can be fully filtered over IPv4 and completely unfiltered over IPv6 at the same time, which produces convincingly random results.

If the router advertises itself or an ISP resolver as an IPv6 DNS server via router advertisements or DHCPv6, dual-stack clients will happily use it and never consult Pi-hole. Either give Pi-hole an IPv6 address and advertise that, or stop advertising IPv6 DNS servers entirely. Half-configured dual-stack is the single most common cause of “it blocks on my laptop but not my phone.”

Step 5: devices that ignore the network

Some clients never ask. Smart TVs, streaming sticks, and consoles have shipped with resolver addresses compiled in, and they use them regardless of what DHCP offers. The only reliable network-level answer is a firewall rule that redirects outbound port 53 to Pi-hole, or rejects it from everything except Pi-hole itself.

Encrypted DNS is the harder version of the same problem. A client speaking DNS-over-HTTPS (RFC 8484) or DNS-over-TLS (RFC 7858) is not sending anything that looks like DNS on port 53, so a redirect rule never sees it. Browsers and operating systems have also adopted automatic upgrade mechanisms, including Discovery of Designated Resolvers, which can move a client to an encrypted resolver without the user choosing to.

The practical options are narrow: disable the feature on the client where you control it, block the known endpoints where you do not, or accept that this device is outside the filter. Pretending otherwise wastes time.

If encrypted DNS keeps defeating you at the client, the architectural alternatives worth reading about are in Pi-hole vs AdGuard Home — running the filter as a DoH or DoT server changes what the client can bypass.

Step 6: is gravity populated?

Queries are arriving, so the filter is the suspect. Check the list actually loaded.

pihole -g

Gravity is the process that downloads subscribed lists, parses them into a domains-only format, merges and de-duplicates them, and writes the result into the gravity table of /etc/pihole/gravity.db. It runs weekly on its own, but it is worth running by hand here because the output tells you whether each list downloaded or failed.

A list URL that has moved, gone behind Cloudflare, or been retired fails quietly week after week. A fresh install whose first gravity run failed has an empty domain table and blocks nothing at all, while every other indicator looks healthy.

Step 7: is the specific domain even on a list?

pihole -q ads.example.com

This queries your allowlists, denylists, wildcards and subscribed lists for a domain and reports which lists contain it. Two results, both informative:

• Not found anywhere. Nothing is broken. The domain is not on the lists you subscribe to. Add it explicitly with pihole deny, or subscribe to a list that covers it.
• Found, but the query log shows it resolving. Something is overriding the block: an allowlist entry, a per-group rule, or an allow-regex broader than intended. Allow rules win.

Group management is the quiet one. A client assigned to a group with fewer adlists attached behaves completely differently from the rest of the network, and the dashboard’s aggregate numbers still look fine.

Step 8: caches, upstream and TTLs

DNS answers are cached at several layers, and a change to Pi-hole does not retroactively affect an answer a client already holds.

The client OS caches. Browsers keep their own cache. Long TTLs mean a previously-resolved hostname can keep working for hours after you block it. Before concluding a rule failed, flush the client’s DNS cache, restart the browser, and retry. Testing from a device that has never resolved the domain before removes the variable entirely.

Note also that upstream resolvers that rewrite or filter on their own behalf can make the picture confusing. What Pi-hole forwards and what comes back are visible in the query log; use it rather than inferring.

Step 9: produce the diagnostic bundle

pihole debug

The debugger walks the installation, reports problems it recognises, and links to guidance. It offers to upload the resulting log for community support. This belongs at step 9 and not step 1: by the time you run it you already know whether queries arrive, whether gravity loaded, and whether the domain is listed, which makes the output far easier to interpret and far easier for anyone helping you.

When nothing is wrong

A large share of “not blocking” reports are DNS working exactly as specified.

• Advertising served from the same hostname as the content cannot be separated by a resolver. Blocking the name breaks the service. This is the single most common cause of “Pi-hole doesn’t block ads on that one site.”
• CNAME cloaking routes a tracker through a subdomain of the site you are visiting so the lookup looks first-party. It appears in the query log as a redirect through an unrelated domain, and it is the one worth watching for.
• In-app advertising frequently uses the app’s own API hostname.
• Anything requested by literal IP address never generates a lookup, so there is nothing to block.

The full explanation of which of these are fixable and which are structural is in what a Pi-hole DNS sinkhole can and cannot block.

The fix that creates the next problem

The instinct at this point is to add more blocklists. Resist it.

Large aggregated lists overlap heavily, so the marginal domain coverage of the fifth list is small while the marginal breakage risk is not. Breakage from DNS blocking is uniquely hard to diagnose because the application reports a generic connection error rather than a DNS failure, so the symptom never points at the cause. The query log at the moment of failure is the tool; allow the specific hostname with pihole allow rather than removing an entire list.

There is a resource ceiling too. Every subscribed domain occupies memory in the FTL engine alongside retained query history, and a host chosen for a default install can be undersized for a several-million-domain configuration. The memory and blocklist sizer gives a rough estimate of where a given domain count and query volume lands, and Pi-hole hardware requirements covers what to do if the answer exceeds what the box has.

The ladder, condensed

1. pihole status — is blocking enabled?
2. pihole tail — do this device’s queries arrive?
3. What resolver is DHCP actually handing out? Only one, and it filters?
4. Is IPv6 advertising a different resolver?
5. Does this device hardcode or encrypt its DNS?
6. pihole -g — did every list download?
7. pihole -q <domain> — is it listed, or is something allowing it?
8. Flush client caches; check TTLs and the upstream.
9. pihole debug.

Work it in order and almost every case resolves in the first four steps.