Slik løser du PostgreSQL Connection Refused på localhost port 5432

Hvis PostgreSQL sier “connection refused” på localhost:5432, er det første du må fikse tilgjengelighet, ikke passordet. Kjør pg_isready -h localhost -p 5432. Hvis den rapporterer no response, er PostgreSQL vanligvis stoppet, lytter på en annen port eller adresse, kjører i et annet miljø som Docker, eller feiler under oppstart. Hvis den rapporterer accepting connections, er serveren tilgjengelig, og du bør slutte å behandle problemet som et port-nektelsesproblem og i stedet undersøke den neste feilmeldingen.

PostgreSQL bruker TCP-port 5432 som standard, og den gjeldende PostgreSQL 18-dokumentasjonen sier at listen_addresses er satt til localhost som standard. Per 11. september 2026 er PostgreSQL 18 den gjeldende stabile hovedutgivelsen, med PostgreSQL 18.6 utgitt 13. august 2026; PostgreSQL 19 Beta 3 er fortsatt en utviklingsutgivelse. Feilsøkingstrinnene nedenfor gjelder generelt for støttede PostgreSQL-versjoner, men pakenavn, tjenestenavn og filplasseringer varierer etter operativsystem og installasjonsprogram. Se den offisielle kunngjøringen for PostgreSQL 18.6 og dokumentasjonen for gjeldende tilkoblingsinnstillinger.

1. Bekreft at feilen virkelig er “Connection Refused”

Begynn med den nøyaktige feilteksten. Flere PostgreSQL-tilkoblingsfeil høres like ut, men peker på ulike lag i stabelen.

Denne distinksjonen forhindrer en vanlig omvei: å redigere passord eller pg_hba.conf mens ingenting lytter på port 5432. Disse innstillingene betyr noe etter at en tilkobling har nådd PostgreSQL-serveren.

2. Kjør pg_isready mot den nøyaktige verten og porten

pg_isready er PostgreSQLs eget verktøy for tilkoblingsstatus. Kjør:

pg_isready -h localhost -p 5432

PostgreSQL dokumenterer fire avslutningsstatusser: 0 når serveren aksepterer tilkoblinger, 1 når den avslår tilkoblinger, 2 når det ikke er noen respons, og 3 når det ikke ble gjort noe gyldig forsøk. Du trenger ikke et riktig databasenavn, brukernavn eller passord bare for å få den grunnleggende serverstatusen. Se den offisielle pg_isready-referansen.

Hvis du får:

• localhost:5432 - accepting connections: port 5432 er tilgjengelig. Prøv din virkelige psql- eller applikasjonstilkobling og feilsøk den nye meldingen hvis den feiler.
• localhost:5432 - rejecting connections: serveren svarte, men aksepterer ikke normale tilkoblinger ennå, noe som kan skje under oppstart eller gjenoppretting. Sjekk serverloggen og vent hvis oppstarten legitimt er i gang.
• localhost:5432 - no response: fortsett med server- og lytterkontrollene nedenfor.

Test også 127.0.0.1 eksplisitt:

pg_isready -h 127.0.0.1 -p 5432

Hvis 127.0.0.1 fungerer, men localhost ikke gjør det, er problemet mer sannsynlig relatert til navneløsning eller IPv4/IPv6-binding enn at PostgreSQL er helt nede.

3. Forsikre deg om at PostgreSQL-serveren kjører

Hvis du installerte PostgreSQL via et operativsystemspakke eller installasjonsprogram, bruk den normale tjenestestyringsmekanismen for den pakken. PostgreSQLs egen dokumentasjon anbefaler å bruke den pakkede oppstartsinfrastrukturen når den er tilgjengelig, i stedet for å finne på en separat oppstartsmetode.

Hvis du administrerer klyngen direkte og kjenner dens datakatalog, gir PostgreSQL pg_ctl:

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

Verdien for -D må peke til riktig PostgreSQL datakatalog, som er katalogen for den databasaklyngen. Hvis PGDATA er konfigurert, kan pg_ctl bruke den i stedet. Den offisielle pg_ctl-dokumentasjonen beskriver status, start, restart og reload.

Windows

Åpne Tjenester og se etter PostgreSQL-tjenesten opprettet av installasjonsprogrammet ditt. Hvis den er stoppet, start den. Hvis flere PostgreSQL-versjoner er installert, verifiser at du starter instansen assosiert med datakatalogen og porten applikasjonen din forventer.

Linux

Pakenavn varierer mellom distribusjoner. En pakkert installasjon kan eksponere en systemtjeneste som postgresql eller en versjons-/klyngespesifikk enhet. Bruk tjenestedefinisjonen for pakken i stedet for å anta ett universelt tjenestenavn.

macOS

Den riktige oppstartsmekanismen avhenger av om PostgreSQL kom fra en app-bundle, Homebrew, MacPorts, kildekode eller en annen pakke. Samme prinsipp gjelder: start instansen fra mekanismen som opprettet den, og kjør pg_isready på nytt.

Hvis serveren stopper umiddelbart igjen, ikke fortsett å starte den på nytt. Inspekter oppstartloggen. En dårlig konfigurasjonsverdi, utilgjengelig datakatalog, portkonflikt, manglende fil eller gjenopprettingsproblem kan hindre PostgreSQL i å forbli oppe.

4. Verifiser at noe faktisk lytter på port 5432

En kjørende PostgreSQL-prosess er ikke nok hvis den er bundet til en annen port eller kun til en Unix-domensokkel. Sjekk operativsystemets lyttertabell.

Linux

ss -ltnp | grep 5432

macOS

lsof -nP -iTCP:5432 -sTCP:LISTEN

Windows PowerShell

Get-NetTCPConnection -LocalPort 5432 -State Listen

Hvis det ikke er noen lytter, kjører ikke PostgreSQL, bruker en annen port, er bundet et annet sted, eller startet ikke. Hvis et annet program eier 5432, kan PostgreSQL være udestandig til å binde den porten. Sjekk PostgreSQLs oppstartlogg før du bestemmer deg for å stoppe den andre prosessen eller flytte PostgreSQL til en annen port.

Hvis du bevisst konfigurerte PostgreSQL på 5433, må klienten din bruke 5433:

psql -h localhost -p 5433 -U postgres

Ikke “fiks” en bevisst ikke-standardport ved å endre PostgreSQL tilbake til 5432 med mindre det faktisk er din ønskede arkitektur.

5. Sjekk postgresql.conf: listen_addresses og port

PostgreSQLs listen_addresses-innstilling styrer hvilke TCP/IP-grensesnitt som aksepterer tilkoblingsforsøk. Den dokumenterte standarden er localhost. port-innstillingen er 5432 som standard. Begge innstillingene anvendes ved serverstart, så endringer krever en serveromstart.

For en strengt lokal utviklingsdatabase ser de relevante innstillingene vanligvis slik ut:

listen_addresses = 'localhost'
port = 5432

Hvis listen_addresses er en tom streng, lytter ikke PostgreSQL på noen IP-grensesnitt, og kun Unix-domensokler kan brukes der de støttes. Omvendt ber listen_addresses = '*' PostgreSQL om å lytte på alle tilgjengelige grensesnitt; det er vanligvis unødvendig for en lokal utviklingsdatabase og kan øke eksponeringen hvis autentisering og brannmureregler ikke er designet for ekstern tilgang.

Hvis du kan koble til via en Unix-domensokkel, men TCP på localhost feiler, spør den aktive serveren for å finne de aktive filene og innstillingene:

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

Dette er tryggere enn å redigere den første postgresql.conf du finner, spesielt på en maskin med flere klynger eller PostgreSQL-versjoner. PostgreSQL støtter konfigurasjonsfiler utenfor datakatalogen, så filbaner er ikke universelle. Se den offisielle dokumentasjonen for konfigurasjonsfilplasseringer.

6. Hvis PostgreSQL kjører i Docker, avhenger “localhost” av hvor klienten kjører

Container-nettverk endrer betydningen av vertsnavnet. Dette er en av de vanligste årsakene til at en database er sunn mens en applikasjon fortsatt får connection refused.

Applikasjonen kjører på vertsmaskinen

PostgreSQL-containeren trenger en publisert vertsport. En Compose-tjeneste kan inneholde:

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

Da kan en klient som kjører på verten din bruke:

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

Applikasjonen kjører i en annen Compose-container

Inne i applikasjonscontaineren refererer localhost til selve applikasjonscontaineren, ikke databasecontaineren. Docker Compose gir DNS for tjenestenavn, så hvis databasetjenesten er navngitt db, kobler applikasjonen seg vanligvis til:

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

Dockers offisielle Compose-nettverksdokumentasjon skiller eksplisitt mellom container-til-container-tjenestenavnet og vertens publiserte port. For eksempel, hvis du mapper 8001:5432, bruker containere fortsatt db:5432, mens verten bruker localhost:8001. Se Dockers offisielle Compose-nettverksguide.

Før du redigerer PostgreSQL selv, sjekk:

docker compose ps
docker compose logs db

Hvis containeren starter på nytt, er loggen vanligvis mer verdifull enn å endre tilkoblingsstrenger gjentatte ganger.

7. Behandle brannmureregler som en senere sjekk for en localhost-nektelse

For en klient og server på samme maskin, begynn ikke med å åpne port 5432 for alle nettverk. Bekreft først at PostgreSQL lytter lokalt. En bred brannmureregel kan skape unødvendig eksponering uten å fikse en stoppet server.

Brannmurundersøkelse blir mer relevant når:

• PostgreSQL er i en VM, containervert, WSL-miljø eller et annet nettverksnavnerom.
• Du endret listen_addresses for å tillate ikke-loopback-tilkoblinger.
• Lokal sikkerhetsprogramvare anvender regler på loopback eller applikasjonsprosesser.
• Lytteren finnes og fungerer fra ett miljø, men ikke et annet.

Hvis ekstern tilgang er bevisst, begrens de tillatte kildenettverkene og autentiseringsreglene til det som faktisk er nødvendig. At port 5432 er tilgjengelig fra alle steder er ikke en forutsetning for en lokal applikasjon.

8. Ikke rediger pg_hba.conf før serveren er tilgjengelig

pg_hba.conf styrer PostgreSQL-klientautentisering. En host-post gjelder for TCP/IP-tilkoblinger. Den forårsaker ikke at en stoppet server begynner å lytte, så den er vanligvis feil første fiks for connection refused.

Når pg_isready rapporterer at serveren aksepterer tilkoblinger, kan en autentiseringsfeil legitimt lede deg til pg_hba.conf. For localhost TCP-tilkoblinger er regler vanligvis avgrenset til loopback-adresser som 127.0.0.1/32 og ::1/128, med databasen, rollen og autentiseringsmetoden valgt for ditt miljø.

PostgreSQL 18 setter password_encryption til scram-sha-256 som standard, og dokumentasjonen merker MD5-krypterte passord som utfaset. Unngå å kopiere gamle autentiseringseksempler blindt. Se den gjeldende pg_hba.conf-dokumentasjonen og gjeldende autentiseringsinnstillinger.

På Unix-lignende systemer kan endringer i pg_hba.conf lastes inn på nytt med pg_ctl reload eller SELECT pg_reload_conf();. PostgreSQL dokumenterer en Windows-spesifikk forskjell: endringer i pg_hba.conf anvendes på påfølgende nye tilkoblinger uten samme SIGHUP-krav.

9. Test med psql etter at lytteren er sunn

Når pg_isready sier at serveren aksepterer tilkoblinger, test den samme banen applikasjonen din forventer:

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

En vellykket psql-prompt forteller deg mye mer enn “tjenesten kjører”: den bekrefter at en ekte PostgreSQL-klient nådde serveren og besto tilkoblings- og autentiseringsfasene for disse parameterne.

Hvis psql fungerer, men applikasjonen din fortsatt rapporterer connection refused, sammenlign applikasjonskonfigurasjonen tegn for tegn:

• Vertsnavn
• Port
• Databasenavn
• Brukernavn
• Om appen kjører på verten, i Docker, i en VM eller i et annet miljø
• Miljøvariabler lastet av den faktisk kjørende prosessen
• Om applikasjonen ble startet på nytt etter at tilkoblingsstrengen endret seg

Et vanlig eksempel er en lokal terminal som bruker localhost:5432 vellykket, mens en Dockerisert webapp også bruker localhost:5432. Webappen ringer da seg selv, ikke databasetjenesten. I det tilfellet er det å endre containerens databasevert til Compose-tjenestenavnet den relevante fiksen.

10. Les serverloggen hvis PostgreSQL ikke vil forbli oppe

Hvis tjenesten starter og umiddelbart avsluttes, er nettverksfeilen bare et symptom. Oppstartloggen er der PostgreSQL forklarer hvorfor den ikke kunne bli klar.

Se etter meldinger om:

• Adresse eller port allerede i bruk
• Ugyldig postgresql.conf-syntaks
• Manglende eller utilgjengelig datakatalog
• Problemer med fil-eierskap eller tillatelser
• Gjenopprettings- eller WAL-problemer
• Inkompatibel datakatalog og serverhovedversjon

Hvis du starter en direkte administrert klynge med pg_ctl, anbefaler PostgreSQL å fange serveroutput, for eksempel med -l logfile. Prosjektets dokumentasjon for serveroppstart forklarer hvorfor oppstartoutput er nyttig for diagnose.

Rask diagnose etter scenario

Vanlige fiks som kan gjøre situasjonen verre

Å sette listen_addresses til '*' uten grunn

Dette kan gjøre PostgreSQL tilgjengelig fra ytterligere grensesnitt, men det er ikke nødvendig for en normal localhost-tilkobling på samme maskin. Det kan også utvide eksponeringen. Bruk den smaleste bindingen som samsvarer med arkitekturen din.

Å åpne port 5432 for hele nettverket

En brannmurunntak kan ikke få en stoppet PostgreSQL-prosess til å lytte. Bekreft lytteren først, legg deretter kun til nettverkstilgangen du faktisk trenger.

Å nullstille postgres-passordet for en tilkoblingsnektelse

Passordautentisering skjer etter at klienten nådde PostgreSQL. Hvis TCP-tilkoblingen nektes, adresserer endring av passordet vanligvis feil lag.

Å redigere feil postgresql.conf

Maskiner med flere installasjoner kan inneholde flere konfigurasjonsfiler. Bruk en fungerende lokal sokkeltilkobling og SHOW config_file; når mulig, eller identifiser datakatalogen til serverprosessen du faktisk intenderte å kjøre.

Å anta at 5432 er obligatorisk

5432 er standarden, ikke et krav. Hvis den tiltenkte klyngen din er konfigurert for 5433 og alle klienter bruker 5433, er det gyldig. Konsistens betyr mer enn å tvinge standarden.

Når du bør endre feilsøkingsmetoden

Du bør slutte å jobbe med “connection refused” spesifikt når pg_isready rapporterer aksepterende tilkoblinger eller psql når en autentiserings-/databasefeil. På det tidspunktet gjør nettverkslytteren jobben sin, og å fortsette å endre porter, brannmureregler eller listen_addresses kan introdusere nye problemer.

På samme måte, hvis PostgreSQL ikke kan starte, skift fra klientbasert feilsøking til serveroppstartsdiagnose. Hvis en container kontinuerlig starter på nytt, gå til containerloggen. Hvis en vertsklient fungerer, men en containerklient feiler, gå til container-DNS og portmapping. Det nyttige spørsmålet er ikke “Hvilken PostgreSQL-innstilling bør jeg veksle?” men “På hvilket lag stopper tilkoblingen å gjøre fremdrift?”

Hva en vellykket fiks ser ut som

Du kan betrakte localhost-tilgjengelighetsproblemet som fikset når alle følgende er sanne for miljøet du faktisk bruker:

1. pg_isready -h localhost -p 5432 rapporterer accepting connections, eller den rapporterer den ekvivalente vert/porten du bevisst konfigurerte.
2. Operativsystemet viser at PostgreSQL lytter på den forventede adressen og porten.
3. psql kan nå serveren ved å bruke samme nettverksbane som applikasjonen.
4. Applikasjonen din mottar ikke lenger connection refused.
5. Hvis en annen PostgreSQL-feil dukker opp, feilsøker du den nye feilen separat i stedet for å fortsette å endre lytteren.

Grensen for denne prosedyren er viktig: den diagnostiserer om en PostgreSQL-server kan nås på den forventede verten og porten. Den kan ikke alene fikse et ugyldig passord, manglende rolle, manglende database, SQL-feil, skjemaproblem eller applikasjonsfeil i tilkoblingspoolen. Disse blir relevante først etter at tilkoblingen kommer forbi nektelsesfasen.

For de fleste localhost-tilfeller er den korteste veien fortsatt den samme: test 5432 med pg_isready, bekreft at den tiltenkte PostgreSQL-instansen kjører, verifiser lytteren, og endre konfigurasjonen først deretter. Den rekkefølgen holder feilsøkingen fokusert og reduserer sjansen for å gjøre et enkelt stoppet-tjeneste-problem til et større nettverks- eller sikkerhetsproblem.