Pihole + Cloudflared - incorrect setup?

Help
1

Expected Behaviour:

Tried to install pihole with cloudflare but I’ve run into various problems. Pihole by itself I could never get to work (I think my ISP is blocking the port; see previous post here UDP DNS reply: Timeout - no response from upstream DNS server ).

I got DoH through cloudflared working for awhile, then there was a system update that seemed to wreck everything and now it’s not working at all.

Actual Behaviour:

Currently, a dig command gets the following:

$ dig @127.0.0.1 -p 5053 google.com
;; communications error to 127.0.0.1#5053: connection refused
;; communications error to 127.0.0.1#5053: connection refused
;; communications error to 127.0.0.1#5053: connection refused

; <<>> DiG 9.18.39-0ubuntu0.24.04.1-Ubuntu <<>>  @127.0.0.1 -p 5053 google.com
; (1 server found)
;; global options: +cmd
;; no servers could be reached

My cloudflared status report looks like this:

cloudflared.service - cloudflared DNS over HTTPS proxy
Loaded: loaded (/etc/systemd/system/cloudflared.service; enabled; preset: enabled)
Active: active (running) since Sun 2025-09-21 00:55:05 MST; 15h ago
Main PID: 4700 (cloudflared)
Tasks: 9 (limit: 9259)
Memory: 11.5M (peak: 13.3M)
CPU: 11.672s
CGroup: /system.slice/cloudflared.service
└─4700 /usr/local/bin/cloudflared proxy-dns --port 5053 --upstream https://1.1.1.1/dns-query --upstream https://1.0.0.1/dns-query --address 192.168.1.85

Sep 21 00:55:05 goyo-p-ubuntu systemd[1]: Started cloudflared.service - cloudflared DNS over HTTPS proxy.
Sep 21 00:55:05 goyo-p-ubuntu cloudflared[4700]: 2025-09-21T07:55:05Z INF Adding DNS upstream url=https://1.1.1.1/dns-query
Sep 21 00:55:05 goyo-p-ubuntu cloudflared[4700]: 2025-09-21T07:55:05Z INF Adding DNS upstream url=https://1.0.0.1/dns-query
Sep 21 00:55:05 goyo-p-ubuntu cloudflared[4700]: 2025-09-21T07:55:05Z INF Starting DNS over HTTPS proxy server address=dns://192.168.1.85:5053
Sep 21 00:55:05 goyo-p-ubuntu cloudflared[4700]: 2025-09-21T07:55:05Z INF Starting metrics server on 127.0.0.1:42693/metrics

For awhile the pihole query log was returning nothing but SERVFAIL to everything. Now everything is:

Query received on: 2025-09-21 16:18:44.778

Client: 192.168.1.74

Query Status: Forwarded to 127.0.0.1#5053

Reply: No reply received

Database ID: 23050

Debug Token:

https://tricorder.pi-hole.net/P2dMCTxt/

Thanks in advance for all the help.

2

Your dig results demonstrates that your issue is with cloudflared, not with Pi-hole.

connection refused would suggest that either 127.0.0.1:5053 isn't receiving your DNS request to start with, or cloudflared isn't able to send any requests to its configured upstreams.

To verify the latter, please share the result of the following command as run from your cloudflared machine:

curl -vH "accept: application/dns-json" "https://1.1.1.1/dns-query?name=example.com&type=A"
3

Here you go:

$ curl -vH "accept: application/dns-json" "https://1.1.1.1/dns-query?name=example.com&type=A"
* Trying 1.1.1.1:443...
* Connected to 1.1.1.1 (1.1.1.1) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=Cloudflare, Inc.; CN=cloudflare-dns.com
* start date: Jan  2 00:00:00 2025 GMT
* expire date: Jan 21 23:59:59 2026 GMT
* subjectAltName: host "1.1.1.1" matched cert's IP address!
* issuer: C=US; O=DigiCert Inc; CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
* SSL certificate verify ok.
* Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/2
* \[HTTP/2\] \[1\] OPENED stream for https://1.1.1.1/dns-query?name=example.com&type=A
* \[HTTP/2\] \[1\] \[:method: GET\]
* \[HTTP/2\] \[1\] \[:scheme: https\]
* \[HTTP/2\] \[1\] \[:authority: 1.1.1.1\]
* \[HTTP/2\] \[1\] \[:path: /dns-query?name=example.com&type=A\]
* \[HTTP/2\] \[1\] \[user-agent: curl/8.5.0\]
* \[HTTP/2\] \[1\] \[accept: application/dns-json\]
> GET /dns-query?name=example.com&type=A HTTP/2
> Host: 1.1.1.1
> User-Agent: curl/8.5.0
> accept: application/dns-json
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 200
< server: cloudflare
< date: Tue, 23 Sep 2025 04:12:01 GMT
< content-type: application/dns-json
< access-control-allow-origin: \*
< x-content-type-options: nosniff
< content-length: 509
< cf-ray: 9837338b49ab5711-PHX
< alt-svc: h3=":443"; ma=86400
<
* Connection #0 to host 1.1.1.1 left intact
 {"Status":0,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,
 "Question":\[{"name":"example.com","type":1}\],
 "Answer":\[{"name":"example.com","type":1,"TTL":171,"data":"23.220.75.232"},
 {"name":"example.com","type":1,"TTL":171,"data":"23.215.0.138"},
 {"name":"example.com","type":1,"TTL":171,"data":"23.192.228.84"},
 {"name":"example.com","type":1,"TTL":171,"data":"23.215.0.136"},
 {"name":"example.com","type":1,"TTL":171,"data":"23.192.228.80"},
 {"name":"example.com","type":1,"TTL":171,"data":"23.220.75.245"}\]}
4

That looks ok, demonstrating that 1.1.1.1 was accessible and responsive, successfully resolving example.com, at least at the time you ran that curl.

What's the output of:

dig @127.0.0.1 -p 5053 example.com

dig @192.168.1.85 -p 5053 example.com
5

The dig through 127 is the same as above.

The other dig is here:

$ dig @192.168.1.85 -p 5053 example.com

; <<>> DiG 9.18.39-0ubuntu0.24.04.1-Ubuntu <<>> @192.168.1.85 -p 5053 example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2590
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: f302ee23eeecb6a5 (echoed)
;; QUESTION SECTION:
;example.com.			IN	A

;; ANSWER SECTION:
example.com.		149	IN	A	23.192.228.80
example.com.		149	IN	A	23.220.75.232
example.com.		149	IN	A	23.192.228.84
example.com.		149	IN	A	23.220.75.245
example.com.		149	IN	A	23.215.0.136
example.com.		149	IN	A	23.215.0.138

;; Query time: 70 msec
;; SERVER: 192.168.1.85#5053(192.168.1.85) (UDP)
;; WHEN: Tue Sep 23 07:09:36 MST 2025
;; MSG SIZE  rcvd: 214
6

That would indicate your cloudflared isn't accepting traffic from the loopback address (127.0.0.1).

Your output suggests that you have explicitly bound your cloudflared to 192.168.1.85 instead of 127.0.0.1:

You should change your cloudflared configuration to bind to 127.0.0.1.

7

Thank you, this did it!

Interestingly, it seems like the default cloudflared install didn’t work, with these command lines:

Commandline args for cloudflared, using Cloudflare DNS

CLOUDFLARED_OPTS=--port 5053 --upstream https://cloudflare-dns.com/dns-query

But when I switch to the alternate setup for when cloudflared runs on a different host than pihole (even though they aren’t), and make the change as you suggested, it works.

Part of me wonders if I switch back to the default settings would it still work? But I’m not up for potentially losing everything again.

Thanks for all the help!

8

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.