Sådan løser du PostgreSQL-forbindelsesfejl på localhost port 5432

Hvis PostgreSQL melder "connection refused" på localhost:5432, er det første, du skal rette, tilgængeligheden, ikke adgangskoden. Kør pg_isready -h localhost -p 5432. Hvis den melder no response, er PostgreSQL typisk stoppet, lytter på en anden port eller adresse, kører i et andet miljø som Docker, eller fejler under opstart. Hvis den melder accepting connections, er serveren tilgængelig, og du skal stoppe med at behandle problemet som et port-nægtelsesproblem og i stedet undersøge den næste fejlbesked.

PostgreSQL bruger som standard TCP-port 5432, og den nuværende PostgreSQL 18-dokumentation angiver, at listen_addresses som standard er sat til localhost. Pr. 11. september 2026 er PostgreSQL 18 den aktuelle stabile hovedudgivelse, med PostgreSQL 18.6 udgivet den 13. august 2026; PostgreSQL 19 Beta 3 er stadig en udviklingsudgivelse. Fejlfindingstrinnene nedenfor gælder generelt for understøttede PostgreSQL-versioner, men pakenavne, tjenestenavne og filplaceringer varierer afhængigt af operativsystem og installationsprogram. Se den officielle udgivelsesmeddelelse for PostgreSQL 18.6 og dokumentationen for aktuelle forbindelsesindstillinger.

1. Bekræft, at fejlen virkelig er "Connection Refused"

Start med den præcise fejltekst. Flere PostgreSQL-forbindelsesfejl lyder ens, men peger på forskellige lag i stakken.

Denne skelnen forhindrer en almindelig omvej: at redigere adgangskoder eller pg_hba.conf, mens der ikke lyttes på port 5432. Disse indstillinger betyder noget, først når en forbindelse når PostgreSQL-serveren.

2. Kør pg_isready mod den præcise vært og port

pg_isready er PostgreSQLs eget værktøj til forbindelsesstatus. Kør:

pg_isready -h localhost -p 5432

PostgreSQL dokumenterer fire afslutningstilstande: 0 når serveren accepterer forbindelser, 1 når den afviser forbindelser, 2 når der ikke er noget svar, og 3 når der ikke blev foretaget et gyldigt forsøg. Du behøver ikke et korrekt databasenavn, brugernavn eller adgangskode for blot at få den grundlæggende serverstatus. Se den officielle pg_isready-referencedokumentation.

Hvis du får:

• localhost:5432 - accepting connections: port 5432 er tilgængelig. Prøv din rigtige psql- eller applikationsforbindelse, og fejlfind den nye besked, hvis den fejler.
• localhost:5432 - rejecting connections: serveren svarede, men accepterer endnu ikke normale forbindelser, hvilket kan ske under opstart eller genopretning. Tjek serverloggen, og vent hvis opstarten legitimt er i gang.
• localhost:5432 - no response: fortsæt med server- og lytterkontrollerne nedenfor.

Test også 127.0.0.1 eksplicit:

pg_isready -h 127.0.0.1 -p 5432

Hvis 127.0.0.1 virker, men localhost ikke gør, skyldes problemet sandsynligvis navneløsning eller IPv4/IPv6-binding snarere end, at PostgreSQL er helt nede.

3. Sørg for, at PostgreSQL-serveren kører

Hvis du installerede PostgreSQL via en operativsystempakke eller et installationsprogram, skal du bruge den pågældende pakkes normale tjenestestyringsmekanisme. PostgreSQLs egen dokumentation anbefaler at bruge den pakkede opstartsinfrastruktur, når den er tilgængelig, frem for at opfinde en separat opstartsmetode.

Hvis du administrerer klyngen direkte og kender dens datakatalog, tilbyder PostgreSQL pg_ctl:

pg_ctl status -D /path/to/data
pg_ctl start -D /path/to/data -l /path/to/postgresql.log

Værdien for -D skal pege på den korrekte PostgreSQL datakatalog, som er kataloget for den pågældende databaseklynge. Hvis PGDATA er konfigureret, kan pg_ctl bruge den i stedet. Den officielle pg_ctl-dokumentation beskriver status, start, restart og reload.

Windows

Åbn Tjenester og led efter den PostgreSQL-tjeneste, der er oprettet af dit installationsprogram. Hvis den er stoppet, skal du starte den. Hvis der er installeret flere PostgreSQL-versioner, skal du verificere, at du starter den instans, der er associeret med den datakatalog og port, din applikation forventer.

Linux

Pakenavne varierer mellem distributioner. En pakkede installation kan eksponere en systemtjeneste som postgresql eller en versions-/klyngespecifik enhed. Brug pakkens tjenestedefinition frem for at antage ét universelt tjenestenavn.

macOS

Den korrekte opstartsmekanisme afhænger af, om PostgreSQL kom fra en app-pakke, Homebrew, MacPorts, kildekode eller en anden pakke. Det samme princip gælder: start instansen fra den mekanisme, der oprettede den, og kør derefter pg_isready igen.

Hvis serveren straks stopper igen, skal du ikke fortsætte med at genstarte den. Inspektér dens opstartslog. En dårlig konfigurationsværdi, utilgængelig datakatalog, portkonflikt, manglende fil eller genopretningsproblem kan forhindre PostgreSQL i at forblive oppe.

4. Verificér, at der faktisk lyttes på port 5432

En kørende PostgreSQL-proces er ikke nok, hvis den er bundet til en anden port eller kun til en Unix-domænesokkel. Tjek operativsystemets lyttertabel.

Linux

ss -ltnp | grep 5432

macOS

lsof -nP -iTCP:5432 -sTCP:LISTEN

Windows PowerShell

Get-NetTCPConnection -LocalPort 5432 -State Listen

Hvis der ikke er nogen lytter, er PostgreSQL enten ikke kørende, bruger en anden port, er bundet et andet sted eller fejlede ved opstart. Hvis et andet program ejer 5432, kan PostgreSQL være ude af stand til at binde den port. Tjek PostgreSQLs opstartslog, før du beslutter, om du skal stoppe den anden proces eller flytte PostgreSQL til en anden port.

Hvis du bevidst konfigurerede PostgreSQL på 5433, skal din klient f.eks. bruge 5433:

psql -h localhost -p 5433 -U postgres

"Reparér" ikke en bevidst ikke-standardport ved at ændre PostgreSQL tilbage til 5432, medmindre det faktisk er din ønskede arkitektur.

5. Tjek postgresql.conf: listen_addresses og port

PostgreSQLs listen_addresses-indstilling styrer, hvilke TCP/IP-grænseflader der accepterer forbindelsesforsøg. Den dokumenterede standard er localhost. port-indstillingen er som standard 5432. Begge indstillinger anvendes ved serverstart, så ændringer kræver en genstart af serveren.

For en strengt lokal udviklingsdatabase ser de relevante indstillinger typisk sådan ud:

listen_addresses = 'localhost'
port = 5432

Hvis listen_addresses er en tom streng, lytter PostgreSQL ikke på nogen IP-grænseflade, og kun Unix-domænesokler kan bruges, hvor det understøttes. Omvendt beder listen_addresses = '*' PostgreSQL om at lytte på alle tilgængelige grænseflader; det er normalt unødvendigt for en udviklingsdatabase, der kun er til localhost, og kan øge eksponeringen, hvis godkendelse og firewallregler ikke er designet til fjernadgang.

Hvis du kan oprette forbindelse via en Unix-domænesokkel, men TCP på localhost fejler, så spørg den aktive server for at lokalisere de aktive filer og indstillinger:

SHOW config_file;
SHOW hba_file;
SHOW listen_addresses;
SHOW port;

Dette er sikrere end at redigere den første postgresql.conf, du finder, især på en maskine med flere klynger eller PostgreSQL-versioner. PostgreSQL understøtter konfigurationsfiler uden for datakataloget, så filstier er ikke universelle. Se den officielle dokumentation for konfigurationsfilplaceringer.

6. Hvis PostgreSQL kører i Docker, afhænger "localhost" af, hvor klienten kører

Container-netværk ændrer betydningen af værtsnavnet. Dette er en af de mest almindelige årsager til, at en database er sund, mens en applikation stadig får "connection refused".

Applikationen kører på værten

PostgreSQL-containeren har brug for en offentliggjort værtsport. En Compose-tjeneste kan indeholde:

services:
  db:
    image: postgres:18
    ports:
      - "5432:5432"

Derefter kan en klient, der kører på din vært, bruge:

postgresql://postgres:YOUR_PASSWORD@localhost:5432/YOUR_DB

Applikationen kører i en anden Compose-container

Inde i applikationscontaineren refererer localhost til selve applikationscontaineren, ikke databasecontaineren. Docker Compose giver DNS for tjenestenavne, så hvis databasetjenesten hedder db, opretter applikationen normalt forbindelse til:

postgresql://postgres:YOUR_PASSWORD@db:5432/YOUR_DB

Dockers officielle Compose-netværksdokumentation skelner eksplicit mellem container-til-container-tjenestenavnet og værtsens offentliggjorte port. Hvis du f.eks. kortlægger 8001:5432, bruger containere stadig db:5432, mens værten bruger localhost:8001. Se Dockers officielle Compose-netværksguide.

Før du redigerer PostgreSQL selv, skal du tjekke:

docker compose ps
docker compose logs db

Hvis containeren genstarter, er loggen normalt mere værdifuld end gentagne gange at ændre forbindelsesstrenge.

7. Betragt firewallregler som en senere kontrol ved en localhost-nægtelse

For en klient og server på samme maskine skal du ikke begynde med at åbne port 5432 for alle netværk. Bekræft først, at PostgreSQL lytter lokalt. En bred firewallregel kan skabe unødvendig eksponering uden at reparere en stoppet server.

Firewallundersøgelse bliver mere relevant, når:

• PostgreSQL er i en VM, container-vært, WSL-miljø eller et andet netværksnavnerum.
• Du ændrede listen_addresses for at tillade ikke-loopback-forbindelser.
• Lokal sikkerhedssoftware anvender regler på loopback eller applikationsprocesser.
• Lytteren findes og virker fra ét miljø, men ikke et andet.

Hvis fjernadgang er tilsigtet, skal du begrænse de tilladte kildenetværk og godkendelsesregler til det, der faktisk er nødvendigt. At port 5432 er tilgængelig overalt er ikke en forudsætning for en lokal applikation.

8. Redigér ikke pg_hba.conf, før serveren er tilgængelig

pg_hba.conf styrer PostgreSQL-klientgodkendelse. En host-post gælder for TCP/IP-forbindelser. Den får ikke en stoppet server til at begynde at lytte, så det er normalt den forkerte første løsning på connection refused.

Når pg_isready melder, at serveren accepterer forbindelser, kan en godkendelsesfejl legitimt lede dig til pg_hba.conf. For localhost-TCP-forbindelser er regler typisk afgrænset til loopback-adresser som 127.0.0.1/32 og ::1/128, hvor databasen, rollen og godkendelsesmetoden vælges til dit miljø.

PostgreSQL 18 sætter som standard password_encryption til scram-sha-256, og dens dokumentation markerer MD5-krypterede adgangskoder som udfasede. Undgå at kopiere gamle godkendelseseksempel blindt. Se den aktuelle pg_hba.conf-dokumentation og aktuelle godkendelsesindstillinger.

På Unix-lignende systemer kan ændringer i pg_hba.conf genindlæses med pg_ctl reload eller SELECT pg_reload_conf();. PostgreSQL dokumenterer en Windows-specifik forskel: ændringer i pg_hba.conf anvendes på efterfølgende nye forbindelser uden samme SIGHUP-krav.

9. Test med psql, når lytteren er sund

Når pg_isready siger, at serveren accepterer forbindelser, skal du teste den samme sti, som din applikation forventer:

psql -h localhost -p 5432 -U postgres -d postgres

En vellykket psql-prompt fortæller dig meget mere end "tjenesten kører": den bekræfter, at en rigtig PostgreSQL-klient nåede serveren og bestod forbindelses- og godkendelsestrinnene for disse parametre.

Hvis psql virker, men din applikation stadig melder "connection refused", så sammenlign applikationskonfigurationen tegn for tegn:

• Værtsnavn
• Port
• Databasenavn
• Brugernavn
• Om appen kører på værten, i Docker, i en VM eller i et andet miljø
• Miljøvariabler indlæst af den faktisk kørende proces
• Om applikationen blev genstartet, efter dens forbindelsesstreng blev ændret

Et almindeligt eksempel er en lokal terminal, der bruger localhost:5432 med succes, mens en Dockeriseret webapp også bruger localhost:5432. Webappen kalder derefter sig selv, ikke databasetjenesten. I det tilfælde er det relevante fix at ændre containerens databasevært til Compose-tjenestenavnet.

10. Læs serverloggen, hvis PostgreSQL ikke kan forblive oppe

Hvis tjenesten starter og straks afsluttes, er netværksfejlen kun et symptom. Opstartsloggen er der, hvor PostgreSQL forklarer, hvorfor den ikke kunne blive klar.

Se efter beskeder om:

• Adresse eller port allerede i brug
• Ugyldig postgresql.conf-syntaks
• Manglende eller utilgængelig datakatalog
• Problemer med fil ejerskab eller tilladelser
• Genopretnings- eller WAL-problemer
• Inkompatibel datakatalog og serverhovedversion

Hvis du starter en direkte administreret klynge med pg_ctl, anbefaler PostgreSQL at fange serveroutput, f.eks. med -l logfile. Projektets dokumentation for serveropstart forklarer, hvorfor opstartsoutput er nyttigt til diagnose.

Hurtig diagnose efter scenarie

Almindelige løsninger, der kan gøre situationen værre

Sætte listen_addresses til '*' uden grund

Dette kan gøre PostgreSQL tilgængelig fra yderligere grænseflader, men det er ikke nødvendigt for en normal localhost-forbindelse på samme maskine. Det kan også udvide eksponeringen. Brug den snævrste binding, der matcher din arkitektur.

Åbne port 5432 for hele netværket

En firewallundtagelse kan ikke få en stoppet PostgreSQL-proces til at lytte. Bekræft lytteren først, og tilføj derefter kun den netværksadgang, du faktisk har brug for.

Nulstille postgres-adgangskoden ved en forbindelsesnægtelse

Adgangskodegodkendelse sker, efter klienten når PostgreSQL. Hvis TCP-forbindelsen nægtes, adresserer ændring af adgangskoden normalt det forkerte lag.

Redigere den forkerte postgresql.conf

Maskiner med flere installationer kan indeholde flere konfigurationsfiler. Brug altid en fungerende lokal sokkel-forbindelse og SHOW config_file;, når det er muligt, eller identificér datakataloget for den serverproces, du faktisk har til hensigt at køre.

Antage, at 5432 er obligatorisk

5432 er standarden, ikke et krav. Hvis din tilsigtede klynge er konfigureret til 5433, og alle klienter bruger 5433, er det gyldigt. Konsistens betyder mere end at tvinge standarden.

Når du skal ændre din fejlfindingstilgang

Du skal stoppe med at arbejde på "connection refused" specifikt, når pg_isready melder accepterende forbindelser, eller psql når en godkendelses-/databasefejl. På det tidspunkt gør netværkslytteren sit arbejde, og fortsat ændring af porte, firewallregler eller listen_addresses kan introducere nye problemer.

Ligeledes, hvis PostgreSQL ikke kan starte, skal du skifte fra klient-side fejlfinding til serveropstartsdiagnose. Hvis en container konstant genstarter, skal du gå til containerloggen. Hvis en værtsklient virker, men en containerklient fejler, skal du gå til container-DNS og port-kortlægning. Det nyttige spørgsmål er ikke "Hvilken PostgreSQL-indstilling skal jeg skifte?", men "På hvilket lag stopper forbindelsen med at gøre fremskridt?"

Hvad en vellykket løsning ser ud

Du kan betragte localhost-tilgængelighedsproblemet som løst, når alle følgende er sande for det miljø, du faktisk bruger:

1. pg_isready -h localhost -p 5432 melder accepting connections, eller den melder den ækvivalente vært/port, du bevidst konfigurerede.
2. Operativsystemet viser, at PostgreSQL lytter på den forventede adresse og port.
3. psql kan nå serveren ved hjælp af den samme netværkssti som applikationen.
4. Din applikation modtager ikke længere connection refused.
5. Hvis en anden PostgreSQL-fejl opstår, fejlfinder du den nye fejl separat i stedet for fortsat at ændre lytteren.

Grænsen for denne procedure er vigtig: den diagnosticerer, om en PostgreSQL-server kan nås på den forventede vært og port. Den kan ikke i sig selv reparere en ugyldig adgangskode, manglende rolle, manglende database, SQL-fejl, skemaproblem eller applikationsforbindelsespul-fejl. Disse bliver først relevante, efter forbindelsen kommer forbi nægtelsesfasen.

For de fleste localhost-tilfælde er den korteste vej stadig den samme: test 5432 med pg_isready, bekræft at den tilsigtede PostgreSQL-instans kører, verificér lytteren, og ændr først derefter konfigurationen. Den rækkefølge holder fejlfindingen fokuseret og reducerer chancen for at gøre et simpelt stoppet-tjeneste-problem til et større netværks- eller sikkerhedsproblem.