If your Pi-hole sends upstream queries through cloudflared, that setup is now living on borrowed time. Pi-hole’s official cloudflared guide carries a deprecation notice: the proxy-dns feature it relies on was deprecated by Cloudflare in November 2025, and — quoting the docs directly — “if cloudflared is updated after the 2nd of February 2026 it will no longer function as per this guide.” New installations via this method are no longer recommended, and the Pi-hole docs offer no replacement.
So the question is: how do you keep Pi-hole-style blocking and DNS-over-HTTPS without cloudflared? You have three realistic paths:
- Keep Pi-hole and swap cloudflared for another DoH proxy (dnscrypt-proxy).
- Keep Pi-hole and switch the upstream to DNS-over-TLS (stubby or unbound).
- Move to a sinkhole with encrypted DNS built into the core (AdGuard Home or EliHole).
All three are legitimate. Which one fits depends on how attached you are to Pi-hole and how many moving parts you want to maintain. Let’s go through them.
What actually broke
Pi-hole itself only speaks plain DNS to its upstreams. The cloudflared trick worked around that: cloudflared ran as a local proxy on 127.0.0.1:5053, accepted plain DNS from Pi-hole, and re-sent each query to Cloudflare over HTTPS. Pi-hole pointed at the proxy as a “custom upstream” and got encrypted transport for free.
Cloudflare has now deprecated that proxy-dns mode. Existing binaries keep working and are supported for 12 months after their release date, but any cloudflared build updated after February 2, 2026 drops the feature. Sticking with an old binary means running an unpatched, internet-facing network daemon indefinitely — not a trade worth making to avoid an afternoon of migration.
Why encrypted upstream DNS is worth keeping
Before picking a replacement, it’s fair to ask whether you need one at all. Plain DNS on port 53 travels unencrypted, which means your ISP — or anyone on the path between your network and the upstream resolver — can log every domain your household looks up. That’s not a hypothetical attack; it’s passive observation of cleartext traffic, and in some markets ISPs have monetized exactly this data.
Encrypted transports close that window. DNS-over-HTTPS (RFC 8484) wraps queries in ordinary HTTPS traffic on port 443; DNS-over-TLS (RFC 7858) does the same over a dedicated TLS connection on port 853. Either one hides query contents from on-path observers.
One honest caveat: encryption protects confidentiality in transit, not authenticity of answers. Your chosen upstream still sees your queries, and a tampered or misconfigured zone still resolves wrong — that’s what DNSSEC validation is for, a separate mechanism with its own failure modes worth understanding before you enable it.
Option 1: keep Pi-hole, replace cloudflared with dnscrypt-proxy
The closest drop-in replacement is dnscrypt-proxy: a local proxy that accepts plain DNS and forwards over DoH, DNSCrypt, or ODoH. It plays the same role cloudflared did, but DNS proxying is its entire reason to exist rather than a side feature of a tunneling daemon — so it’s unlikely to meet the same fate.
Install it from your distribution’s packages or the official GitHub releases, then edit dnscrypt-proxy.toml:
listen_addresses = ['127.0.0.1:5053']
server_names = ['cloudflare', 'quad9-dnscrypt-ip4-filter-pri']doh_servers = true is the default, so DoH resolvers from the public server list are already eligible. Restart the service, then point Pi-hole at it: Settings → DNS, untick the preset upstreams, and set a custom upstream of 127.0.0.1#5053. Verify with dig @127.0.0.1 -p 5053 example.com before flipping Pi-hole over.
One packaging gotcha: on some distributions the package ships a dnscrypt-proxy.socket systemd unit, and while that socket is active its address overrides listen_addresses in the config file. If your proxy isn’t listening where you told it to, check systemctl status dnscrypt-proxy.socket.
Why not unbound for DoH?
Unbound comes up constantly in Pi-hole threads, but it solves a different problem. Unbound is a recursive resolver: it walks the DNS tree and queries authoritative servers directly, over plain DNS, instead of handing your queries to Cloudflare or Google at all. That’s a great privacy model in its own right — no single upstream sees your full query history — but it is not DoH, and unbound cannot act as a DoH upstream proxy the way cloudflared did. If your goal is “Pi-hole DNS-over-HTTPS without cloudflared,” unbound recursion isn’t the answer; dnscrypt-proxy is.
Option 2: keep Pi-hole, switch to DNS-over-TLS
If you care about encrypted transport more than about HTTPS specifically, DoT gets you there with software that isn’t going anywhere.
stubby is a dedicated DoT stub resolver. A minimal /etc/stubby/stubby.yml:
listen_addresses:
- 127.0.0.1@5453
upstream_recursive_servers:
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
- address_data: 9.9.9.9
tls_auth_name: "dns.quad9.net"Then set Pi-hole’s custom upstream to 127.0.0.1#5453.
unbound as a TLS forwarder is the other route — not recursion this time, but forwarding everything upstream over TLS:
server:
interface: 127.0.0.1
port: 5335
tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 1.1.1.1@853#cloudflare-dns.com
forward-addr: 9.9.9.9@853#dns.quad9.netPi-hole’s custom upstream becomes 127.0.0.1#5335. The practical difference from DoH: DoT uses a dedicated port (853), so a network that wants to block it can do so trivially, while DoH blends into regular HTTPS. On your own home network that rarely matters.
Both options still mean running and updating a sidecar process next to Pi-hole — which is exactly the architecture that just failed you with cloudflared.
Option 3: switch to a sinkhole with encrypted DNS built in
The cloudflared deprecation exposes the structural weakness of the sidecar approach: Pi-hole’s encrypted-DNS story has always depended on a third-party process it doesn’t control. The alternative is a sinkhole that speaks encrypted DNS natively.
AdGuard Home deserves a fair mention here: it’s the more mature option with built-in encrypted DNS, supporting DoH, DoT, and DoQ for both upstreams and clients out of the box, with years of production use behind it. If “everything in one binary, no sidecars” is your only requirement, AdGuard Home solves it well.
EliHole takes the same no-sidecar approach with a different emphasis. It’s an open-source DNS sinkhole built on Elixir, and encrypted DNS lives in the core: it serves DoH (RFC 8484) at /dns-query out of the box, speaks DoT (RFC 7858) once you configure a certificate, and uses encrypted upstreams natively — no proxy process to install, monitor, or replace when a vendor changes direction. Where it differentiates from AdGuard Home is enforced DNSSEC validation, native multi-instance clustering (master/slave roles for redundant resolvers), and first-class Prometheus metrics. If you’re weighing it against staying on Pi-hole, the EliHole vs Pi-hole comparison goes feature by feature.
Switching doesn’t mean rebuilding your blocklists by hand either: EliHole imports Pi-hole Teleporter backups — blocklists, whitelist, and settings — so the migration is an export, an import, and a DHCP change.
Which option should you pick?
| Your situation | Best fit |
|---|---|
| Happy with Pi-hole, want DoH specifically | dnscrypt-proxy as the new local proxy |
| Happy with Pi-hole, encrypted transport is what matters | stubby or unbound forwarding over TLS |
| Tired of sidecars, want maximum maturity | AdGuard Home |
| Tired of sidecars, want enforced DNSSEC, clustering, Prometheus | EliHole |
Whichever path you take, do it before your next reflexive apt upgrade or container pull bumps cloudflared past the cutoff and your upstream resolution silently dies. A deliberate migration this month beats debugging mysterious SERVFAILs at 11 p.m. later.