Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)

Have the same problem also on Ubuntu 24 LTS. Will check for the "incoming-num-tcp: 25".

I stopped getting this error after changing incoming-num-tcp to 1024 on both my unbound instances. The rest of my config:

num-threads: 4
incoming-num-tcp: 1024
outgoing-range: 8192
num-queries-per-thread: 4096
rrset-cache-size: 512m
msg-cache-size: 256m
so-rcvbuf: 8m
so-sndbuf: 8m
module-config: "validator cachedb iterator"

Since the pihole v5->v6 upgrade, I'm seeing the same errors a couple of times a day from cloudflared:

Connection error (127.0.0.1#5053): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)

Can't recall ever seeing this error on pihole v5.

2 Likes

I got same errors.
I have installed dnscrypt proxy.

What can i do ?

It looks like the newest update for FTL reduces the logging level. I would assume this fixes it, but time will tell. Guessing this is something that was happening on V5, but the logging level just didn't show it.

Edit Well this didn't age well. I have the issue worse than ever AFTER the newest FTL update I thought would fix it.

Keeping thread alive....latest pihole updates,,,just recv error, last recv was approx 24hrs ago. added just now, incoming-num-tcp: 40. will monitor

Same problem for me. I've never seen the error prior to V6, though I'm not saying that's the issue

I have the setting at 1024 but still get sporadic errors regardless

1 Like

I currently have a pair of (brand new) v6 Pi-hole instances installed on Pi Zero 2 WH.
One is consistently showing the error (on the VLAN with more queries) while the other (with fewer queries) has never had the error.

Same thing happening to me, fresh v6 Pihole with cloudflared on the same Pi 5, pointing to OpenDNS. Happening about once a day ATM.

1 Like

Yeah...my primary gets at least one a day. As soon as I delete the warning/error the clock is ticking for another to show up. The backup which is keepalived triggered only does not (only a few lookups a day).

Get the error on my main pi-hole consistently at least every day and on my second pi-hole periodically

I do not have any occurences since last update to Core v6.0.5. I have set incoming-num-tcp: 1024

1 Like

How did you do that?

Check post by @bennor3814 on this thread dated 21/Feb on how to update the conf file.

Dont have a file like this.
Im using dnscrpyt proxy

I got a single occurence today in the /var/log/pihole/FTL.log, after 6 days of zero incidents.

2025-03-11 11:25:28.417 GMT [199785/F127218] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Res ource temporarily unavailable)

If your Unbound container shows the error:
error: Could not open logfile /unbound.log: Permission denied

Step 1: Create the Log File
mkdir -p /srv/docker/pihole-unbound/unbound/etc-unbound/
touch /srv/docker/pihole-unbound/unbound/etc-unbound/unbound.log

sudo chown -R 1000:1000 /srv/docker/pihole-unbound/unbound/etc-unbound/
sudo chmod -R 755 /srv/docker/pihole-unbound/unbound/etc-unbound/

If Unbound still can't write, try:
sudo chmod 777 /srv/docker/pihole-unbound/unbound/etc-unbound/unbound.log

Step 3: Restart the Unbound Container
docker restart unbound

This issue happens because the Unbound container lacks permission to write logs to the mapped volume. Creating the file and setting proper permissions resolves the problem for me.

Let me know if you need more help! :rocket:

Am i getting this right? Edit: /etc/unbound/unbound.conf.d/pi-hole.conf
And place incoming-num-tcp: 40 under server: like so;

GNU nano 7.2 /etc/unbound/unbound.conf.d/pi-hole.conf
server:
incoming-num-tcp: 1024

$ sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf

server:
# This setting should increase the number of TCP connections that stop the pihole/Unbound WARNINGS
incoming-num-tcp: 1024
...

Initially I had set the value to 25, then 40 but I was getting frequent occurences of the error. However since then we have had a couple of Core and FTL updates, so I reckon none can be 100% sure what minimized the errors, but the latest from my side is 1 error after 6 full days without a single occurence.

I am using a Pi4B/4GB and PiHole with Unbound is serving a SOHO.

1 Like