Wi-Fi & Network

Pi-hole isn't blocking ads

Find the path your devices use to bypass Pi-hole — wrong DHCP DNS, an IPv6 leak, browser DoH, hardcoded resolvers — and seal each one.

Problem summary

When Pi-hole runs but ads still show, the usual cause is not a broken blocklist — it's that some or all clients are reaching a different resolver. The job is to prove which bypass path is open, then close it.

Operator snapshotEvidence first

First proof

On the Pi-hole dashboard, watch the query log while browsing on the affected device.

Screen to open

ipconfig /all (Windows) • Settings > Wi-Fi > (network) > details (macOS/iOS/Android)

Expected signal

The device's lookups appear in the log in real time, attributed to its IP.

Stop boundary

If the device breaks when its hardcoded DNS is blocked, allow it as a documented exception rather than fighting it.

Layer path

1Pi-hole only filters queries that actually reach it. 'Ads still showing' is almost always a routing problem (a client using a different resolver), not a blocklist problem.

2There are a handful of distinct bypass paths, and they fail independently: DHCP handing out the wrong DNS, an IPv6 resolver leaking past it, browser DNS-over-HTTPS, a device with hardcoded DNS, a VPN/Private Relay, and content that can't be blocked at the domain level at all.

3The fastest diagnosis is to ask Pi-hole itself: if a client's lookups appear in the query log, Pi-hole is in the path and the issue is the blocklist or unblockable content; if they don't, the client is bypassing it and you fix routing.

4Domain-level filtering can never strip first-party ads served from content domains (YouTube, many in-app ads) — that's a structural limit, not a misconfiguration.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Confirm Pi-hole is healthy first

Check: Open the dashboard; confirm FTL is running, blocklists are populated (gravity has domains), and lookups from a known-good wired client appear in the log.

Expected result: Pi-hole itself resolves and blocks for at least one client.

If not: If even a wired client isn't filtered, fix the Pi-hole install/upstream before chasing per-client bypasses.

Pin the bypass to one client and watch the log

Check: On the device that shows ads, browse while filtering the query log to its IP.

Expected result: Either its queries appear (blocklist/content problem) or they don't (routing/bypass problem) — this splits the whole diagnosis in two.

If not: If unsure which IP it is, check the device's network details first.

Verify the handed-out DNS for IPv4 and IPv6

Check: Read the client's active DNS via ipconfig /all or the OS network details; check the router's DHCP DNS option and whether it advertises an IPv6 DNS.

Expected result: The client shows the Pi-hole IP for both protocols.

If not: If a public resolver or rogue IPv6 DNS appears, correct DHCP/RA so Pi-hole is the only handed-out resolver.

Close the encrypted-DNS paths

Check: Disable browser Secure DNS/DoH, OS Private DNS, and (for home Wi-Fi) iCloud Private Relay on the affected device; note any always-on VPN.

Expected result: With encrypted-DNS off, the client's lookups now land in the Pi-hole log.

If not: If you can't change every device by hand, block DoH and redirect outbound port 53 at the firewall — see the force-through guide.

Handle hardcoded-DNS devices at the firewall

Check: For any device that still queries a public resolver directly, add a firewall rule to redirect or block its outbound DNS.

Expected result: The stubborn device now resolves through Pi-hole, or is a documented allow-listed exception.

If not: If blocking its DNS breaks the device, allow it explicitly rather than leaving the rule half-applied.

Separate 'unblockable' from 'unblocked'

Check: For remaining ads, compare the ad's source domain in the query log against your lists.

Expected result: Tracker/ad-network domains get added to a blocklist or regex; first-party/CDN ad domains are accepted as DNS-unblockable.

If not: Do not over-block content domains to chase first-party ads — you'll break the site instead.

Decision tree

If: The affected device's queries DO appear in the Pi-hole log.

Then: Pi-hole is in the path; this is blocklist coverage or unblockable content.

Action: Check the specific domain in the query log: if allowed, add a list/regex; if it's a content domain, accept it can't be DNS-blocked.

If: Queries do NOT appear, and the client's DNS is a public/ISP server.

Then: DHCP or IPv6 is handing out the wrong resolver.

Action: Set DHCP DNS (IPv4 and IPv6) to the Pi-hole address; disable any router-advertised non-Pi-hole IPv6 DNS.

If: Queries don't appear only in one browser.

Then: Browser DNS-over-HTTPS is bypassing the system resolver.

Action: Disable Secure DNS/DoH in that browser, or block DoH network-wide so it falls back to Pi-hole.

If: Queries don't appear only on mobile / only off-Wi-Fi.

Then: OS Private DNS, a VPN, or iCloud Private Relay is carrying DNS elsewhere.

Action: Turn the relevant bypass off for the home network, or accept that this traffic is intentionally outside Pi-hole.

If: One specific device ignores everything you set.

Then: It likely hardcodes a public resolver.

Action: Use the router/firewall to redirect or block its outbound port 53 (and DoH) — see the force-through-Pi-hole guide.

Safe stop: If the device breaks when its hardcoded DNS is blocked, allow it as a documented exception rather than fighting it.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
Ads on one phone, fine on a laptop.	Phone Wi-Fi DNS setting + Private DNS/VPN/Private Relay state; query log filtered to the phone IP.	Client resolver / encrypted DNS	Point the phone at Pi-hole (disable Private DNS/Relay for home Wi-Fi) and confirm it now appears in the log.
Ads everywhere, nothing in the query log.	ipconfig /all or router DHCP settings showing the handed-out DNS; IPv6 RA DNS.	DHCP / IPv6 routing	Set DHCP DNS for IPv4 and IPv6 to Pi-hole; remove the rogue IPv6 resolver.
Tracker test domain is blocked, but page ads remain.	Query-log result for the tracker vs the ad's actual source domain.	Unblockable content domain	Accept the DNS-layer limit; use a browser content blocker for first-party ads.
Only Chrome/Edge/Firefox still shows ads.	Browser Secure DNS / DoH setting.	Browser DoH	Disable browser DoH or block it at the network so it falls back to the LAN resolver.
A TV stick or IoT device is never filtered.	Router/firewall logs of outbound port 53 to a public IP from that device.	Hardcoded public resolver	Redirect or block its outbound DNS at the firewall; allow as exception only if it breaks.

Reference

Commands and settings paths

What DNS did this client get?

ipconfig /all (Windows) • Settings > Wi-Fi > (network) > details (macOS/iOS/Android)

Where: On the device that still sees ads, connected to home Wi-Fi.

Expected: DNS server(s) listed equal the Pi-hole IP, for both IPv4 and IPv6.

Failure means: A public/ISP resolver or an unexpected IPv6 DNS means DHCP or Router Advertisements are overriding Pi-hole.

Safe next step: Fix DHCP to hand out Pi-hole for both protocols, then re-run.

Is Pi-hole answering this client?

nslookup pi.hole (then nslookup a known-blocked tracker domain)

Where: On the affected client.

Expected: pi.hole resolves to the Pi-hole IP, and the blocked domain returns 0.0.0.0 / NXDOMAIN.

Failure means: If pi.hole fails to resolve, the client is not using Pi-hole as its resolver at all.

Safe next step: Return to the DHCP/IPv6 path before changing blocklists.

Are queries actually reaching Pi-hole?

Pi-hole dashboard > Query Log, filtered to the client IP

Where: In the Pi-hole admin UI while browsing on the client.

Expected: The client's lookups stream into the log attributed to its IP.

Failure means: An empty log for that client confirms a bypass (DoH, Private DNS, VPN, or hardcoded resolver).

Safe next step: Identify which bypass via the triage checks and close it.

Is a browser leaking via DoH?

Browser settings: Chrome/Edge 'Use secure DNS'; Firefox 'DNS over HTTPS'

Where: In each browser on the affected device.

Expected: Secure DNS/DoH is disabled or set to use the system resolver.

Failure means: An enabled DoH provider sends lookups to a public resolver, bypassing Pi-hole for that browser only.

Safe next step: Disable it (or block DoH network-wide) and re-test that browser.

Hardware boundary

Hardware and platform boundary

Change only when

Consider AdGuard Home or NextDNS when you want native encrypted-DNS handling or cloud filtering on devices that leave the house — see the decision guide.

Evidence that matters

Whether the platform can be the DHCP server (to force its own DNS), how it handles IPv6, and whether it filters encrypted DNS for you.

Evidence that does not matter

Raw blocklist size — both Pi-hole and AdGuard Home block identically from the same lists; a bigger list is not better filtering.

Avoid

Chasing YouTube/first-party ad blocking at the DNS layer, or stacking dozens of overlapping blocklists hoping to fix a bypass that's really a routing problem.

Related tool/checklist

Use the linked tool when you need a guided plan from your exact symptoms instead of a static checklist.

Device setup troubleshooter

Last reviewed

2026-06-02 · Reviewed by HomeTechOps. Built from June-2026 web research verified against the Pi-hole v6 documentation, Mozilla's canary-domain guidance for Firefox DoH, and NextDNS/AdGuard Home references; intentionally honest that DNS filtering cannot remove first-party/CDN ads (YouTube) or traffic carried by VPN/iCloud Private Relay.

Sources/assumptions

Assumes a working Pi-hole install (Core v6.x / FTL v6.x) reachable on a fixed LAN IP, and a home router you can administer.
Pi-hole and any DNS filter block at the domain level only — they cannot remove first-party ads served from content domains (YouTube, most app ads) or anything that bypasses your DNS entirely.
Verify current Pi-hole version and config-path behavior against the official docs before editing files — v6 moved settings to pihole.toml.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Apple Support: Wi-Fi and internet troubleshooting on MacUsed for safe first checks around Wi-Fi status, diagnostics, VPN/security software, and external network devices.Microsoft Support: Fix network connection issues in WindowsUsed for Windows network baseline checks before changing router-wide settings.Pi-hole documentationUsed as the first-party reference for Pi-hole install, configuration, and the v6 documentation set.Pi-hole: Introducing Pi-hole v6Used for the v6 architecture change — the embedded FTL web server replacing lighttpd/PHP, the REST API, and Lua admin pages.Mozilla Support: Canary domain — use-application-dns.netUsed for disabling Firefox default DNS-over-HTTPS network-wide by returning NXDOMAIN for the canary domain.AdGuard Home wiki: Comparison with Pi-holeUsed for the AdGuard Home feature delta — built-in DHCP and native encrypted-DNS (DoH/DoT/DoQ) upstream and server — versus Pi-hole.FCC: Home network tipsUsed for router placement, congestion, and baseline home-network troubleshooting guidance.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Avoid unsafe electrical or data-loss steps.
4. Stop when the evidence says the risk moved.

FAQ

Why does pi.hole load but ads still appear on my phone?

The phone is almost certainly resolving through a different DNS server. The two most common reasons in 2026 are the browser's own DNS-over-HTTPS (Chrome/Edge "Secure DNS", Firefox default DoH) and a mobile OS "Private DNS"/"encrypted DNS" setting that points at a public resolver. A device that hands itself a public DNS (or uses DoH to one) never asks Pi-hole, so its blocklists are irrelevant. See force every device through Pi-hole for how to close those paths.

Can Pi-hole block YouTube ads?

No — not reliably, and you should not expect it to. YouTube serves its video ads from the same domains as the video itself, so a domain-level blocker can't separate them without breaking playback. The same is true of most in-app ads and many CDN-hosted first-party ads. DNS filtering removes third-party tracker and ad-network domains network-wide; it is not a replacement for an in-browser content blocker. Claiming otherwise is the most common false promise in this space.

I set Pi-hole as the DNS in my router — why are clients still bypassing it?

Setting the router's upstream DNS only changes what the router itself queries; clients usually get their DNS from DHCP. If the router hands out its own address as DNS and then forwards to Pi-hole, that can work — but many setups leak via IPv6 (clients prefer an IPv6 resolver advertised over Router Advertisements), via clients with hardcoded DNS (some streaming sticks query 8.8.8.8 directly), or via browser DoH. Point DHCP DNS (both IPv4 and IPv6) directly at Pi-hole and verify with a query-log check.

Does iCloud Private Relay bypass Pi-hole?

Yes. iCloud Private Relay tunnels Safari and some traffic through Apple's relays using its own encrypted DNS, so those lookups never reach Pi-hole. It's enabled per-network and can be turned off for your home Wi-Fi in iOS/macOS settings if you want that traffic filtered. This is expected behavior, not a Pi-hole fault.