If your Pi-hole stopped resolving after an update, or an older guide told you to "install cloudflared for DNS-over-HTTPS" and it no longer works, this is almost certainly why. Cloudflare removed the feature those guides depended on.

This guide explains what changed, how to get your network working again in a few minutes, and what to use instead, including the part most replacement guides skip: encrypting the connection from your own phone and laptop to your Pi-hole.

What changed

For years, the standard way to give Pi-hole encrypted upstream DNS was cloudflared proxy-dns. It is a small local program that listens for ordinary DNS from Pi-hole (usually on 127.0.0.1 port 5053) and forwards it to a resolver over DNS-over-HTTPS (DoH). Pi-hole's own documentation included a guide for it.

Cloudflare announced in November 2025 that, starting February 2, 2026, the proxy-dns command would be removed from all new cloudflared releases. According to Cloudflare, the change addresses a potential vulnerability in an underlying DNS library, and the command was an officially undocumented feature of the product. Releases made before that date keep working, but Cloudflare's support policy for any cloudflared release is one year from its release date. Cloudflare points affected users to its WARP client or WARP Connector instead, which are designed for Cloudflare's Zero Trust service and are not drop-in replacements for a private DNS setup.

What this looks like in practice:

• You update cloudflared (or reinstall it on a new machine) and the cloudflared service fails to start.
• Pi-hole is still pointed at 127.0.0.1#5053, which now answers nothing, so DNS fails for every device on your network.

Pi-hole itself did not break. Its upstream disappeared. And because, as of Pi-hole v6, Pi-hole forwards to its upstream servers over plain DNS and has no built-in DoH or DoT support, it needs something else to do the encrypting.

Two different problems

"Encrypted DNS" covers two separate paths, and cloudflared only ever solved one of them.

Most people only noticed the outbound problem because it broke. The inbound one matters if you want your Pi-hole to protect devices away from home with something like Android's Private DNS setting. Both are covered below.

Step 1: Get DNS working again

If the household has no internet, fix that first, then do the proper replacement.

1. Check that cloudflared is the culprit:

systemctl status cloudflared
dig @127.0.0.1 -p 5053 example.com

If the service is failed and the dig times out, that confirms it.

1. In Pi-hole, go to Settings → DNS, untick the custom 127.0.0.1#5053 upstream, and tick a normal public upstream temporarily. This restores service, but your outbound DNS is now unencrypted until you finish the next step.

2. Stop the old service so it doesn't keep failing at boot:

sudo systemctl disable --now cloudflared

Removing the package afterwards is fine. The exact files to clean up depend on how you installed it.

I'd avoid pinning an old cloudflared version as a fix. It will keep running for now, but it is the exact component Cloudflare removed over a security concern, and it only gets older.

Step 2: Choose a replacement for outbound encryption

There is no single right answer, because the options protect against different things.

In short: forwarding over DoT hides your lookups from your ISP but concentrates them with one provider, while recursive resolution spreads them across many servers but doesn't hide them from your ISP. Decide which of those you care about more.

Option A: Unbound, recursive

This is the option Pi-hole's documentation recommends for privacy. Unbound resolves names itself, starting at the root servers, and validates DNSSEC. Install it, then create /etc/unbound/unbound.conf.d/pi-hole.conf. A minimal version looks like this:

server:
    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    edns-buffer-size: 1232
    prefetch: yes

The Pi-hole documentation keeps a longer, maintained Unbound guide with extra hardening options, so compare against it before using this in production. Then restart Unbound and test it:

sudo systemctl restart unbound
dig @127.0.0.1 -p 5335 example.com
dig @127.0.0.1 -p 5335 sigfail.verteiltesysteme.net
dig @127.0.0.1 -p 5335 sigok.verteiltesysteme.net

The first should answer, the sigfail test should return SERVFAIL, and sigok should succeed. That confirms DNSSEC validation is working. Finally, in Pi-hole's Settings → DNS, remove the old upstream and add 127.0.0.1#5335 as the custom upstream.

Option B: Unbound, forwarding over DoT

If you want upstream traffic encrypted and are comfortable choosing a resolver to trust, Unbound can forward over DNS-over-TLS. Add this to the same configuration file:

server:
    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt

forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 9.9.9.9@853#dns.quad9.net
    forward-addr: 149.112.112.112@853#dns.quad9.net
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 1.0.0.1@853#cloudflare-dns.com

The part after # is the name Unbound checks in the server's certificate, which is what stops someone impersonating the resolver. Point Pi-hole at 127.0.0.1#5335 exactly as in Option A. Use either A or B for the same forward-zone ("."), not both at once, since the forwarding block turns off recursion.

Option C: a DoH or DoT proxy

If you specifically want DoH upstream, as cloudflared provided, other small proxies do the same job:

• dnscrypt-proxy has a guide in Pi-hole's documentation. Check that your OS release packages it, because some users report it missing from the Raspberry Pi OS Bookworm repositories.
• AdGuard's dnsproxy runs as a single binary that listens locally and forwards to DoH, DoT, or DoQ upstreams.
• Stubby is a DoT-only stub resolver aimed at exactly this use.

Each follows the same pattern as cloudflared: listen on a local port, point Pi-hole's custom upstream at it. The difference is that they are still maintained for this purpose.

Step 3: Encrypt the connection from your devices

Everything above protects what Pi-hole sends out. To protect what your devices send to Pi-hole, especially away from home, Pi-hole needs a front door that speaks DoT or DoH, because Pi-hole itself only answers plain DNS.

You need:

• A hostname you control, such as dns.example.com, pointing at your home IP address (a dynamic DNS service works if your address changes).
• A TLS certificate for that hostname, for example from Let's Encrypt with certbot.
• A proxy that terminates TLS and forwards to Pi-hole on the same machine.
• Port 853/TCP reachable from the internet. That needs a port-forward on your router and a public IP address, which excludes connections behind carrier-grade NAT.

For DoT, nginx's stream module is enough. On Debian-based systems you may need to install libnginx-mod-stream:

stream {
    server {
        listen 853 ssl;
        ssl_certificate     /etc/letsencrypt/live/dns.example.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/dns.example.com/privkey.pem;
        proxy_pass 127.0.0.1:53;
    }
}

Because nginx connects from the same machine, Pi-hole treats it as a local client, so you don't have to loosen Pi-hole's listening settings.

For DoH, nginx alone isn't enough, since Pi-hole can't speak DoH to it. PowerDNS dnsdist and AdGuard's dnsproxy can both terminate DoT and DoH and pass queries to Pi-hole, and either is a better front door than nginx if you want both protocols.

Then connect your devices:

• Android: Settings → Network → Private DNS → enter dns.example.com.
• iOS and macOS: install a DNS configuration profile that points at your DoT or DoH address. The DNS Setup tool can generate one.
• Browsers: add your DoH URL under the secure DNS (custom provider) setting.

Step 4: Test it

From another machine or network:

dig @dns.example.com +tls example.com

This needs a recent BIND dig (9.18 or newer). On older systems, kdig +tls @dns.example.com example.com from knot-dnsutils does the same. Check that the query appears in Pi-hole's query log. You can also run the DNS Tester against your endpoint to check DoH and DoT support.

Things that catch people out

• Everything looks like it comes from 127.0.0.1. With a simple TCP proxy in front, Pi-hole sees the proxy as the client. Per-device statistics and group rules won't work for remote devices. Sorting this out needs a more capable proxy, or a different engine (see below).
• An open DoT port is an open resolver. Anyone who finds your hostname and port can use your Pi-hole. DoT has no built-in login. You can limit by source IP, rate-limit with dnsdist, or skip exposing it at all and reach Pi-hole over a WireGuard VPN instead. Never expose port 53 itself.
• Certificates expire. Let's Encrypt certificates last 90 days. Make sure renewal works and that nginx reloads after it, or your phone will quietly lose its encrypted DNS.
• Strict Private DNS fails closed. On Android, if your DoT endpoint goes down, the phone stops resolving rather than falling back. Keep your server healthy, or accept that outages mean no internet on that device.
• Encryption hides lookups, not destinations. Your ISP can still see which IP addresses you connect to.
• Check after upgrades. Pi-hole, Unbound, and nginx updates occasionally change defaults. Run your test again after each.

Or change the engine

Much of the work above exists because Pi-hole doesn't do encrypted DNS itself. AdGuard Home does: it supports DoH, DoT, and DoQ natively, for both incoming and outgoing queries, and handles per-device identification through client settings. If encrypted DNS is a core requirement, switching engines can remove several of these moving parts. Pi-hole's strengths are its mature dashboard, groups, and large community, so it isn't automatically the better trade.

Skip the plumbing

Running this yourself means a hostname, certificates and renewals, a proxy, a firewall, a port-forward, and the upkeep that comes with all of them. If you'd like the result without building it, NxValue Stack provisions a private node with either Pi-hole or AdGuard Home, an Unbound resolver, and DoH and DoT endpoints already generated. You paste one hostname into your device's Private DNS setting. The demo node shows how it works.

Summary

• Cloudflare removed cloudflared proxy-dns from new releases starting February 2, 2026, which is why guides built on it stopped working.
• Pi-hole has no built-in encrypted DNS, so it needs a helper for outbound (Pi-hole to upstream) and another for inbound (your devices to Pi-hole).
• For outbound, Unbound recursive and Unbound over DoT protect against different things. Pick the one that matches your concern.
• For inbound, put a TLS proxy in front of Pi-hole, keep port 53 closed, and think about who else can reach your DoT port.
• AdGuard Home handles encrypted DNS natively if you'd rather simplify.

Pi-hole is a registered trademark of Pi-hole LLC. AdGuard Home is a trademark of AdGuard Software Limited. Cloudflare and cloudflared are trademarks of Cloudflare, Inc. NxValue Stack is an independent service provider and is not affiliated with Pi-hole LLC, AdGuard Software Limited, or Cloudflare, Inc.