Die App erreicht die Datenbank nicht — Connection refused? Meist lauscht PostgreSQL nur auf localhost oder die Client-Freigabe in pg_hba.conf fehlt.
Aufwand:
ca. 25 Min.
Voraussetzung:
sudo-Rechte, Terminal
Das Symptom
Eine Anwendung oder ein Datenbank-Werkzeug kann sich nicht mit PostgreSQL verbinden
und meldet could not connect to server: Connection refused auf Port 5432. Lokal
auf dem Server funktioniert der Zugriff oft, nur von einem anderen Rechner oder aus
einem Container heraus scheitert er.
Die „Layer 8“-Wahrheit
„Connection refused“ ist eine sehr konkrete Aussage: Der Rechner hat die Anfrage
erhalten, aber an diesem Port nimmt niemand ab. Für PostgreSQL bedeutet das fast
immer eine von zwei Sachen — der Dienst läuft nicht, oder er läuft, hört aber nur
auf sich selbst. Ab Werk lauscht PostgreSQL häufig ausschließlich auf localhost,
was für eine App auf demselben Server reicht, für jeden Zugriff von außen aber ins
Leere führt.
Und selbst wenn der Server auf dem Netzwerk lauscht, wartet die zweite Hürde: die
Datei pg_hba.conf, PostgreSQLs Türsteher. Sie entscheidet, welche Herkunft sich mit
welchem Verfahren überhaupt anmelden darf. Fehlt dort der Eintrag für das Netz des
Clients, bleibt die Tür zu — trotz laufendem Dienst. Wer diese zwei Schrauben kennt
— Lausch-Adresse und Client-Freigabe — und danach nicht vergisst, die Firewall zu
prüfen und die Konfiguration neu zu laden, löst praktisch jeden dieser Fälle.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Zwischen läuft-nicht und nicht-erreichbar trennen
„Connection refused“ bedeutet: An der Adresse und dem Port nimmt niemand ab. Entweder läuft PostgreSQL gar nicht, oder es läuft, lauscht aber nicht auf der Adresse, über die der Client kommt. Zuerst prüfen, ob der Dienst überhaupt aktiv ist:
sudo systemctl status postgresql
2.
Die Lausch-Adresse kontrollieren
Standardmäßig lauscht PostgreSQL oft nur auf localhost. Eine App von einem anderen Rechner läuft dann ins Leere. In der postgresql.conf den Parameter listen_addresses auf die gewünschte Adresse oder auf alle Schnittstellen setzen und den Dienst neu starten:
listen_addresses = '*'
3.
Die Client-Freigabe in pg_hba.conf ergänzen
Selbst wenn PostgreSQL lauscht, weist es unbekannte Herkünfte ab. In der Datei pg_hba.conf muss das Netz des Clients samt Anmeldeverfahren freigegeben sein — sonst kommt trotz laufendem Dienst keine Verbindung zustande:
host meinedb app 192.168.1.0/24 scram-sha-256
4.
Die Firewall und den Port prüfen
Blockiert eine Firewall den Port 5432, wirkt das nach außen wie „refused“ oder als Zeitüberschreitung. Den Port gezielt für das Client-Netz freigeben — nicht pauschal für das ganze Internet.
5.
Nach Änderungen neu laden
Änderungen an der pg_hba.conf greifen erst nach einem Neuladen der Konfiguration. Danach die Verbindung erneut testen.
sudo systemctl reload postgresql
Häufige Fragen (FAQ)
?Connection refused – heißt das, die Datenbank läuft nicht?
Nicht unbedingt. Die Meldung heißt nur: Auf diesem Port nimmt niemand an. Entweder läuft PostgreSQL wirklich nicht, oder es lauscht ausschließlich auf localhost und ignoriert Anfragen aus dem Netz. Beides sieht für den Client identisch aus, verlangt aber völlig verschiedene Lösungen.
?Ich habe listen_addresses gesetzt und es geht immer noch nicht. Was fehlt?
Sehr wahrscheinlich der Eintrag in der pg_hba.conf. Diese Datei entscheidet getrennt davon, welche Clients sich von wo aus anmelden dürfen. Beide Stellen müssen stimmen – und nach jeder Änderung braucht PostgreSQL ein Neuladen der Konfiguration, sonst gilt weiterhin der alte Stand.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Die Sortierbibliothek des Betriebssystems hat sich geändert. PostgreSQL warnt vor einem Versions-Konflikt — Indizes auf Textspalten sind dann unbrauchbar.