Pi-hole v6 mit Unbound: „Connection error (127.0.0.1#5335)“ prüfen

Pi-hole kann diese Warnung protokollieren:

Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)

Kurzantwort
#

Eine TCP-Anfrage an den eingestellten Upstream ist beim Empfang der Antwortlänge fehlgeschlagen. Das beweist weder einen allgemeinen DNS-Ausfall noch, dass alle betroffenen Anfragen erfolgreich waren. Prüfe insbesondere die tatsächlich auffälligen Domains und Zeitpunkte, bevor du eine Warnung ausblendest oder Einstellungen änderst.2 , 3

Was bedeuten Adresse und Meldung?
#

127.0.0.1#5335 ist eine lokale IPv4-Adresse mit Port 5335, wie sie Pi-holes Anleitung für einen Unbound-Upstream verwendet. Die Adresse allein beweist aber nicht, welches Programm dort lauscht: Im Pi-hole-Issue wird auch Cloudflared als Upstream genannt. Bei getrennten Containern bezeichnet 127.0.0.1 den jeweiligen Container selbst, sofern der Netzwerk-Namespace nicht geteilt wird; die Anleitung mit lokalem Unbound lässt sich deshalb nicht unverändert auf jedes Container-Setup übertragen.1 , 2 , 12

Pi-hole beantwortet blockierte, lokale oder zwischengespeicherte Anfragen selbst; andere leitet es an konfigurierte Upstreams weiter. Ein eigener rekursiver Unbound kann statt eines öffentlichen rekursiven Anbieters autoritative DNS-Server befragen. Das verhindert nicht, dass externe Server oder Netzbetreiber Anfragen beziehungsweise Verkehr sehen können.1

TCP ist ein regulärer DNS-Transport, unter anderem bei abgeschnittenen UDP-Antworten und bei direkt über TCP gestellten Anfragen. Der Record-Typ HTTPS oder SVCB allein beweist nicht, dass eine Anfrage TCP verwendet hat.1 , 10

Welche Ursachen kommen infrage?
#

In einem untersuchten Unbound-Fall beschrieb der Entwickler einen möglichen Ablauf: Eine Auflösung dauert lange, während auf der TCP-Verbindung keine Daten fließen; Unbound schließt die Verbindung wegen des Timeouts. Das ist eine Erklärung für die dort untersuchten Fälle, keine Diagnose für jede gleichlautende Meldung. Ein später diskutierter discard-timeout-Pfad kann laut Entwickler ebenfalls beitragen; andere Ursachen und andere Upstreams sind möglich.2 , 3

Die Formulierung „Connection prematurely closed by remote server“ und „Resource temporarily unavailable“ unterscheidet den gemeldeten Fehlerzustand, bestimmt aber allein weder eine konkrete Ursache noch CPU-, RAM- oder Dateideskriptormangel. Wiederkehrende Zeitabstände können mit wiederholten Abfragen zusammenhängen; sie beweisen das nicht. Auch die frühere Sichtbarkeit unter Pi-hole v5 lässt sich nicht für jede Installation rückwirkend bestimmen.2 , 3

Schritt 1: DNS und Upstream getrennt testen
#

Auf dem Rechner im selben Netzwerk-Namespace wie Pi-hole, sofern Unbound dort auf 127.0.0.1:5335 lauscht und dig installiert ist:1

dig @127.0.0.1 -p 53 example.com A
dig @127.0.0.1 -p 53 example.com A +tcp
dig @127.0.0.1 -p 5335 example.com A
dig @127.0.0.1 -p 5335 example.com A +tcp

Kontrolliere Antwortstatus, Antwortinhalt und Antwortzeit; wiederhole die Tests zum Fehlerzeitpunkt und mit einer tatsächlich betroffenen Domain und ihrem Record-Typ. NOERROR ohne Antwortdaten kann für einen existierenden Namen ohne den angefragten Typ ein gültiges NODATA-Ergebnis sein. NXDOMAIN kann für einen nicht existierenden Namen korrekt sein.13 SERVFAIL oder Timeout bei einer erwartbar funktionierenden Anfrage sind Hinweise zur weiteren Untersuchung, aber auch sie bestimmen die Ursache nicht allein.

Ein erfolgreiches example.com ist nur eine Stichprobe: Caches, Blocklisten, andere Upstreams, Clients und Record-Typen können das Ergebnis beeinflussen. Selbst vier erfolgreiche Tests beweisen daher nicht, dass frühere oder andere Anfragen funktionierten. Teste bei Bedarf zusätzlich vom betroffenen Client über dessen tatsächlich genutzten DNS-Server.

Schritt 2: Zeitpunkt, Dienst und Ressourcen prüfen
#

Vergleiche den Zeitstempel der Warnung mit dem Pi-hole-Query-Log und gegebenenfalls dem Unbound-Journal. Wiederholte langsame oder fehlgeschlagene Abfragen sind Ansatzpunkte, aber eine zeitliche Korrelation ist kein Ursachenbeweis. Pi-holes Anleitung warnt, dass ausführliche Unbound-Protokollierung viele Daten erzeugt; nur kurzzeitig und datenschutzbewusst einsetzen.1

Auf einem systemd-basierten Host helfen die folgenden lesenden Prüfungen. In Containern und bei abweichenden Dienstnamen sind die Befehle entsprechend anzupassen:

sudo ss -lntup | grep -E ':(53|5335)[[:space:]]'
systemctl status unbound --no-pager
journalctl -u unbound --since '1 hour ago' --no-pager
free -h
uptime

ss zeigt lauschende Sockets, soweit Rechte und Netzwerk-Namespace es erlauben. Dienststatus und Journal können auf Neustarts oder Fehler hinweisen; Speichersituation und Last liefern Kontext, aber keinen Beweis für die Ursache der TCP-Warnung. Ein geringer freier Speicherwert oder vorhandene Swap-Nutzung allein beweist keinen Speichermangel. Bei Verdacht auf Deskriptor- oder Speichergrenzen sind passende Prozess- und Kernelmeldungen gesondert zu prüfen.

TCP-Auslastung messen statt Einstellungen raten
#

Sofern unbound-control eingerichtet und zugänglich ist, lässt sich eine Momentaufnahme lesen:9

sudo unbound-control stats_noreset | grep 'tcpusage'

Je nach Installation ist eine andere Berechtigung, etwa der Unbound-Dienstnutzer, nötig. stats_noreset vermeidet das Zurücksetzen der Statistikzähler; thread*.tcpusage zählt aktuell belegte TCP-Puffer je Thread, total.tcpusage summiert sie. Die Werte sind Momentaufnahmen und können kurze Spitzen verfehlen. Ein niedriger Wert beweist weder eine defekte Domain noch schließt er Lastspitzen aus.3 , 9

incoming-num-tcp: 20 und tcp-idle-timeout: 200000 sind kein allgemeiner Fix und keine Behandlung nachgewiesener RAM- oder CPU-Knappheit. Die Diskussion enthält zeitweilige Testvorschläge, aber keine für alle Installationen wirksame Konfiguration; größere Verbindungslimits können zusätzlichen Speicher beanspruchen. Ändere Werte nur bei einer konkret belegten Ursache, nach Prüfung der Dokumentation für die installierte Unbound-Version und mit Sicherung, Konfigurationsprüfung und Rückfallplan.3

TCP pauschal mit do-tcp: no abzuschalten ist keine geeignete Lösung: DNS benötigt auch TCP, insbesondere für Antworten, die nicht über UDP passen.1 , 10

Warnung ausblenden – mit Bedacht
#

Erst wenn die Auswirkungen ausreichend eingegrenzt sind, kannst du die Anzeige von Verbindungswarnungen über Settings → All Settings → Miscellaneous → misc.hide_connection_error ausblenden. Die Option blendet nicht nur diese eine Domain oder diesen einen Upstream aus; sie kann deshalb auch spätere relevante Warnungen verbergen. Sie behebt keine DNS-Ursache.2 , 6

In Docker lautet die dokumentierte Umgebungsvariable FTLCONF_misc_hide_connection_error mit dem Wert true; Umgebungsvariablen machen die entsprechende Einstellung in Weboberfläche und CLI schreibgeschützt. Änderungen an Compose erfordern die passende Neuerstellung des Containers nach dem eigenen Betriebsverfahren.4 , 7

Versionshinweis: Für FTL v6.7 wurde gemeldet, dass die Option die API-/Dashboard-Anzeige filtert, Warnungen aber weiterhin in FTL.log erscheinen. Ein zugehöriger Fix wurde am 4. November 2026 zusammengeführt; ob er in der jeweils installierten Version bereits enthalten ist, ist anhand der betreffenden Release Notes zu prüfen. Aus dem Merge allein folgt keine veröffentlichte oder installierte Fehlerbehebung.4 , 11

Entscheidungshilfe: Was als Nächstes?
#

Abfragen schlagen wiederholt fehl: betroffene Domains, Upstream und Logs untersuchen, bevor du Einstellungen änderst.
Tests liefern Antworten: Das ist eine Momentaufnahme, kein Beweis für fehlerfreies DNS. Bei Bedarf auch direkt vom betroffenen Client testen.
Warnungen ausblenden: Erst nach der Eingrenzung erwägen; die Einstellung behebt die Ursache nicht und kann weitere Warnungen verbergen.

Fazit
#

Eine einzelne Warnung ist weder ein Nachweis für einen Totalausfall noch ein Freibrief, betroffene Abfragen zu ignorieren. Vergleiche UDP und TCP direkt gegen Pi-hole und den tatsächlichen Upstream, untersuche betroffene Domains und prüfe Logs sowie Ressourcen. Erst konkrete Befunde rechtfertigen eine Änderung; das Ausblenden einer Warnung ist lediglich eine Anzeigeentscheidung.

Weiterführende Artikel
#

Passende Produktrecherchen
#

Wenn du die praktische Seite vertiefen möchtest: Diese konkreten Produkte passen zum Thema dieses Artikels. Es ist keine Rangliste und keine Kaufpflicht, sondern eine kurze Auswahl mit Begründung, für wen sie interessant sein kann:

Raspberry Pi 5 4GB – Für Betreiber, die ohnehin ein neues System aufbauen – Für ein separates Pi-hole-System oder Ersatzhardware; ein Hardwarekauf behebt die Meldung nicht automatisch.
Raspberry Pi 4 Modell B (8 GB) – Für Betreiber, die ein Pi-hole-System neu aufbauen – Alternative Plattform für ein separates Pi-hole-System; nur nach Prüfung des tatsächlichen Hardwarebedarfs.
Offizielles Raspberry Pi 5 USB-C Netzteil 27W (weiß) – Für Betreiber eines Raspberry Pi 5, die ein geeignetes Netzteil benötigen – Passendes Netzteil für den Raspberry Pi 5; das richtige Netzteil hängt vom eingesetzten Modell ab.
Starlink-Verfügbarkeit und Konditionen prüfen

Hinweis: Als Amazon-Partner verdient kalika.de an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.

Hinweis: Dieser Link ist ein Starlink-Empfehlungslink. Wenn du darüber bestellst, können für dich und kalika.de Vorteile nach den jeweils geltenden Starlink-Bedingungen entstehen.

Grenzen der Einordnung
#

Die Quellen beschreiben den Stand zum Zeitpunkt der Recherche. Sie ersetzen keine Prüfung im konkreten Einsatz; Konfiguration, Voraussetzungen und lokale Rahmenbedingungen können Ergebnisse verändern. Vor wichtigen Entscheidungen sollten Leserinnen und Leser die genannten Primärquellen erneut prüfen.