The DoH Bypass why your pi-hole can't block what your browser hides

Your Pi-Hole blocks trackers by sinkholing their DNS. The entire architecture assumes your browser asks your Pi-Hole for DNS. That assumption is no longer true for most browsers out of the box. Chrome does it. Firefox does it. Android's built-in OS-level Private DNS does it. Cloudflare WARP does it. Apple’s Private Relay does it. Every one of them is capable of silently routing DNS queries around your Pi-Hole — and most of them do it by default or with a single user-unaware toggle.

This article is the complete map of how DoH (DNS over HTTPS) neutralizes Pi-Hole, who bypasses by default, who bypasses on one checkbox, and what it takes to actually close the hole at the network layer.

what_is_doh

DoH stands for DNS over HTTPS. Traditional DNS queries travel as plain UDP packets on port 53, which means every server, router, and Pi-Hole between your browser and the internet can read and redirect them. That's a feature, not a bug — it's exactly why Pi-Hole works. Your browser asks “where is doubleclick.net?” in the clear, Pi-Hole intercepts the question, and answers 0.0.0.0 instead of the real IP.

DoH changes the architecture. Instead of a plain DNS query on port 53, DoH wraps the same query inside an encrypted HTTPS connection to a DNS provider — typically 1.1.1.1, 8.8.8.8, dns.nextdns.io, or a similar third-party resolver. From the outside, a DoH request looks identical to any other HTTPS traffic. Your Pi-Hole cannot see the domain being requested, cannot redirect it, and in most default configurations has no idea a DNS query is happening at all.

DoH isn't a privacy feature for the user. It's a privacy feature from the user — from the user's own network admin, their Pi-Hole, their parental-control stack, and anything else on the LAN that was trying to filter their DNS.

Now, the browser vendors who ship DoH will explain it as a privacy upgrade: DNS used to be unencrypted, and ISPs were logging and selling the data. That's true. But the way DoH was rolled out also quietly neutralized every consumer-grade DNS filtering setup on the planet. The loss of user-side control wasn't a side effect. It was the point. Control over the DNS layer is the most valuable strategic asset in the consumer internet, and for a decade it belonged to whoever controlled the router. DoH moved that control to whoever controls the browser.

Why this matters for Pi-Hole users

If any application on your network — Chrome, Firefox, your phone, a smart TV, a game console, a refrigerator — uses DoH, its tracker queries don’t go through Pi-Hole. Those trackers resolve normally, load normally, execute normally, and your Pi-Hole’s dashboard shows a suspicious absence of activity rather than obvious leakage. You can run an ad-blocker test and get a high score (because the test site itself is using system DNS, which goes through Pi-Hole) while simultaneously being tracked by dozens of endpoints that used DoH to skip Pi-Hole entirely.

This is the single most common reason Pi-Hole looks like it’s working but isn’t. We see it on the piholekiller leaderboard constantly — setups that pass 90% of request tests but fail the DoH gauntlet because Firefox quietly switched on DoH three updates ago and the user never noticed.

who_bypasses_by_default

A browser ships one of three DoH behaviors: off, opt-in, or automatic. Each of these has dramatic implications for Pi-Hole users. Here’s the current state of play across every major browser and OS.

The "just upgrade your OS" problem

Even if you had a pristine DoH-free browser in 2020, an OS update since has likely introduced a new bypass without asking you. Android 9+, Windows 11’s encrypted DNS feature, macOS Sonoma+’s iCloud Private Relay prompt — all of these shipped DoH (or the closely-related DoT and Oblivious DNS) enabled or one-checkbox-away. Your Pi-Hole worked perfectly the day you set it up. A year later, without you touching it, it silently became a decorative device in a rack.

how_the_bypass_actually_works

Here’s what happens, mechanically, when Chrome loads a page with DoH active. Let’s say the page contains a <script src="https://www.google-analytics.com/analytics.js"> tag — a tracker Pi-Hole would normally sinkhole.

Traditional DNS (Pi-Hole intercepts):

1. Chrome:  UDP query to 192.168.1.87:53 → "where is google-analytics.com?"
2. Pi-Hole: Matches block list → returns "0.0.0.0"
3. Chrome:  TCP connect to 0.0.0.0:443 → fails immediately
4. Chrome:  Fires script tag's onerror → request is blocked

DoH (Pi-Hole bypassed):

1. Chrome:  HTTPS request to https://1.1.1.1/dns-query?name=google-analytics.com
            (Pi-Hole sees only encrypted HTTPS traffic to 1.1.1.1)
2. Cloudflare: Returns the real IP (say, 142.250.65.66)
3. Chrome:  TCP connect to 142.250.65.66:443 → succeeds
4. Chrome:  Downloads analytics.js → tracker fires
5. Pi-Hole dashboard: Shows "nothing blocked" for this request
            (because it never saw the DNS query)

Your Pi-Hole isn’t broken. It simply wasn’t consulted. The browser bypassed it.

The truly subtle failure mode: Pi-Hole’s admin dashboard shows a healthy query volume and plenty of blocks, because the operating system and non-DoH applications still route through Pi-Hole. So the dashboard looks fine. Meanwhile, every single browser-initiated tracker request has quietly been happening in a parallel universe Pi-Hole can’t see. You don't notice until you run a real test like piholekiller’s Level 2 DoH gauntlet and watch all ten of our DoH-provider probe scripts load successfully.

what_to_do_about_it

Once you accept that browsers are going to bypass Pi-Hole whenever they can, the fix becomes clear: stop treating DNS as the only layer of defense. Pi-Hole still works when the browser is using system DNS. It just also needs backup — something that prevents the browser from successfully running DoH in the first place.

There are four real strategies, from easiest to hardest.

Strategy 1 · Per-browser: disable DoH manually

In every browser with a DoH setting, turn it off. Or, where off isn’t available, set it to “use system DNS.” This works but requires per-device and per-browser configuration, and it breaks the moment an OS update flips the default back on. You will be fighting this forever.

• Firefox: about:preferences#general → Network Settings → “Enable DNS over HTTPS” → Off.
• Chrome: chrome://settings/security → “Use secure DNS” → Off.
• Edge: Same as Chrome. edge://settings/privacy → “Use secure DNS” → Off.
• Android: Settings → Network & Internet → Private DNS → Off.
• iOS: iCloud Private Relay must be toggled off in Apple ID settings (if subscribed).

You’ll fix Pi-Hole for a month, until a browser update reverts one of these settings. Not a durable solution.

Strategy 2 · Firewall: block the DoH providers at the network edge

The more robust approach. If DoH depends on your device reaching a specific list of known DoH endpoints (1.1.1.1, 8.8.8.8, dns.quad9.net, dns.nextdns.io, dns.adguard-dns.com, and so on), then block those endpoints on port 443 and port 853 at your firewall. When the browser fails to reach its DoH server, it falls back to system DNS — which goes through Pi-Hole.

This is exactly what the piholekiller test network implements. The full list of DoH IPs currently enforced at the firewall layer:

1.1.1.1, 1.0.0.1         (Cloudflare)
8.8.8.8, 8.8.4.4         (Google)
9.9.9.9, 149.112.112.112 (Quad9)
208.67.222.222, 208.67.220.220 (OpenDNS)
94.140.14.14, 94.140.15.15     (AdGuard)
185.228.168.9, 185.228.169.9   (CleanBrowsing)
194.242.2.2-9                  (Mullvad)
76.76.2.0/24, 76.76.10.0/24    (ControlD)
45.90.28.0/23, 45.90.30.0/23   (NextDNS)
88.198.92.222, 116.202.176.26  (LibreDNS / Hetzner)

Plus all traffic on port 853 (DoT) blocked outbound from LAN interfaces. Combined, this catches the overwhelming majority of DoH providers and forces fallback to system DNS.

Implementation on a Linux router is a handful of nftables rules. If you run OPNsense, pfSense, or a similar firewall UI, you can add these as a firewall alias and block outbound. Full nftables syntax for the curious:

table inet filter {
  set doh_v4 {
    type ipv4_addr; flags interval;
    elements = { 1.1.1.1, 1.0.0.1, 8.8.8.8, 8.8.4.4, ... }
  }
  chain forward {
    iifname "lan1" ip daddr @doh_v4 tcp dport 443 reject
    iifname "lan1" tcp dport 853 reject
    iifname "lan1" udp dport 853 reject
  }
}

Apply that and your browsers’ DoH lookups silently fail. They fall back to DHCP-assigned DNS (which is your Pi-Hole). You didn’t have to touch a single browser setting.

Strategy 3 · Router / DHCP: refuse to hand out upstream DNS

The most elegant defense is to make sure every device on your network is DHCP'd with Pi-Hole as its DNS and has no fallback. Most consumer routers do this by default if you tell them to. The important part: don't hand out any secondary DNS. If a device is told primary DNS = 192.168.1.87 (Pi-Hole) and secondary DNS = 8.8.8.8 (Google), it’ll silently fall back to Google the first time Pi-Hole is slow.

Combined with Strategy 2, this covers virtually all DNS-level bypasses that a standard consumer device is capable of. The remaining leakage comes from applications that hardcode their own DoH endpoints (which some malware and some ad SDKs actively do), and Cloudflare WARP / Apple Private Relay (which operate as full VPNs above this layer).

Strategy 4 · The full stack: firewall + Pi-Hole + Unbound + DoH block + DoT block

The IMPENETRABLE tier. Everything from Strategies 2 and 3, plus:

• Unbound as Pi-Hole’s upstream recursive resolver, so no ISP or third-party provider ever sees your DNS queries at all.
• Transparent DNS NAT: port 53 DNAT rules that redirect any outbound DNS traffic (including to 8.8.8.8 or any other hard-coded resolver) back to Pi-Hole. This catches malware and trackers that try to hardcode their own DNS.
• WireGuard / AmneziaWG tunnel with Pi-Hole as its DNS. Devices connecting via VPN get the same protection as devices on the LAN.
• Tailscale allowlist so that Tailscale’s coordination endpoints don’t get sinkholed by aggressive block lists.
• A regularly-updated blocklist subscription to catch newly-discovered DoH provider IPs as they appear.

This is essentially what the piholekiller test network runs. Passing the full 103-test gauntlet with a perfect score requires exactly this kind of layered stack — anything less will leak somewhere. Our Level 2 DoH gauntlet alone catches 10 of the most common DoH provider endpoints; the full fingerprint + malware + popunder tests reveal gaps most setups didn’t know they had.

testing_your_setup

There are exactly two ways to know whether your Pi-Hole is currently being bypassed. One: open chrome://settings/security / about:preferences#general and check the DoH toggle. If it’s on, you’re being bypassed. Two — the real answer — run a proper test.

Piholekiller’s Level 2 DoH Gauntlet fires JavaScript probes at 10 known DoH providers and records which ones respond. If you score 10/10 blocked on this subset, your firewall is catching DoH and your Pi-Hole is the real DNS source. If you score 0/10 blocked, every browser on your network is one toggle away from silently routing around your Pi-Hole the next time an update ships. Most users fall in between, and the in-between is the scariest state, because it implies partial protection while providing psychological cover for a surveillance attack surface.

related_reading

Passed the DoH gauntlet? You’re stopping the bypasses. Now measure the ad-tech bandwidth that still reaches your browser from the requests that do go through your Pi-Hole — because even a perfect DNS blocker lets through the 2-3% of tracker payload that comes from first-party-served or CDN-shared endpoints.

Our sibling site adbloat.com measures exactly that: composite score across bytes blocked, handshakes prevented, and tracker payload stopped, against a naked-Chrome baseline. Pass both piholekiller and adbloat and you’re in the top 1% of privacy setups on the internet.

Also worth reading: Why Pi-Hole Fails Most Ad Blocker Tests (And Why It's Not Your Pi-Hole's Fault) — a companion piece on why popular ad-blocker tests give false negatives to correctly-configured Pi-Hole setups.