Så här åtgärdar du PostgreSQL Connection Refused på localhost port 5432

Om PostgreSQL säger “connection refused” på localhost:5432 är det första du bör åtgärda tillgängligheten, inte lösenordet. Kör pg_isready -h localhost -p 5432. Om det rapporterar no response är PostgreSQL vanligtvis stoppad, lyssnar på en annan port eller adress, körs i en annan miljö som Docker, eller misslyckas under uppstart. Om det rapporterar accepting connections är servern nåbar och du bör sluta behandla problemet som ett portavvisningsproblem och istället undersöka nästa felmeddelande.

PostgreSQL använder TCP-port 5432 som standard, och den aktuella PostgreSQL 18-dokumentationen säger att listen_addresses är inställd på localhost som standard. Per den 11 september 2026 är PostgreSQL 18 den aktuella stabila huvudversionen, med PostgreSQL 18.6 släppt den 13 augusti 2026; PostgreSQL 19 Beta 3 är fortfarande en utvecklingsversion. Felsökningsstegen nedan gäller i stort sett alla stödda PostgreSQL-versioner, men paketnamn, tjänstenamn och filplatser skiljer sig åt beroende på operativsystem och installationsprogram. Se den officiella PostgreSQL 18.6 släppmeddelandet och dokumentationen för aktuella anslutningsinställningar.

1. Bekräfta att felet verkligen är “Connection Refused”

Börja med den exakta feltexten. Flera PostgreSQL-anslutningsfel låter liknande men pekar på olika lager i stacken.

Denna distinktion förhindrar en vanlig omväg: att redigera lösenord eller pg_hba.conf medan ingenting lyssnar på port 5432. Dessa inställningar spelar roll efter att en anslutning har nått PostgreSQL-servern.

2. Kör pg_isready mot den exakta värden och porten

pg_isready är PostgreSQLs eget verktyg för anslutningsstatus. Kör:

pg_isready -h localhost -p 5432

PostgreSQL dokumenterar fyra avslutstillstånd: 0 när servern accepterar anslutningar, 1 när den avvisar anslutningar, 2 när det inte finns något svar, och 3 när inget giltigt försök gjordes. Du behöver inte ett korrekt databasnamn, användarnamn eller lösenord bara för att få den grundläggande serverstatusen. Se den officiella pg_isready-referensen.

Om du får:

• localhost:5432 - accepting connections: port 5432 är nåbar. Försök med din riktiga psql- eller applikationsanslutning och felsök det nya meddelandet om det misslyckas.
• localhost:5432 - rejecting connections: servern svarade men accepterar inte ännu normala anslutningar, vilket kan inträffa under uppstart eller återställning. Kontrollera serverloggen och vänta om uppstarten legitimt pågår.
• localhost:5432 - no response: fortsätt med server- och lyssnarkontrollerna nedan.

Testa också 127.0.0.1 explicit:

pg_isready -h 127.0.0.1 -p 5432

Om 127.0.0.1 fungerar men localhost inte gör det, är problemet mer sannolikt relaterat till namnupplösning eller IPv4/IPv6-bindning än att PostgreSQL är helt nere.

3. Se till att PostgreSQL-servern körs

Om du installerade PostgreSQL via ett operativsystemspaket eller installationsprogram, använd det paketets normala mekanism för tjänsthantering. PostgreSQLs egen dokumentation rekommenderar att använda den paketerade uppstartsinfrastrukturen när den finns tillgänglig, snarare än att uppfinna en separat uppstartsmetod.

Om du hanterar klustret direkt och känner till dess datakatalog, tillhandahåller PostgreSQL pg_ctl:

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

Värdet för -D måste peka på rätt PostgreSQL datakatalog, vilket är katalogen för det databasklustret. Om PGDATA är konfigurerat kan pg_ctl använda det istället. Den officiella pg_ctl-dokumentationen beskriver status, start, restart och reload.

Windows

Öppna Tjänster och leta efter PostgreSQL-tjänsten som skapats av ditt installationsprogram. Om den är stoppad, starta den. Om flera PostgreSQL-versioner är installerade, verifiera att du startar den instans som är associerad med den datakatalog och port som din applikation förväntar sig.

Linux

Paketnamn skiljer sig mellan distributioner. En paketerad installation kan exponera en systemtjänst som postgresql eller en versions-/klusterspecifik enhet. Använd paketets tjänstedefinition snarare än att anta ett universellt tjänstenamn.

macOS

Den korrekta uppstartsmekanismen beror på om PostgreSQL kom från en app-bundle, Homebrew, MacPorts, källkod eller ett annat paket. Samma princip gäller: starta instansen från mekanismen som skapade den, och kör sedan om pg_isready.

Om servern omedelbart stoppar igen, fortsätt inte att starta om den. Inspektera dess uppstartlogg. Ett felaktigt konfigurationsvärde, otillgänglig datakatalog, portkonflikt, saknad fil eller återställningsproblem kan hindra PostgreSQL från att hålla sig igång.

4. Verifiera att något faktiskt lyssnar på port 5432

En körande PostgreSQL-process räcker inte om den är bunden till en annan port eller endast till ett Unix-domänuttag. Kontrollera operativsystemets lyssnartabell.

Linux

ss -ltnp | grep 5432

macOS

lsof -nP -iTCP:5432 -sTCP:LISTEN

Windows PowerShell

Get-NetTCPConnection -LocalPort 5432 -State Listen

Om det inte finns någon lyssnare, är antingen PostgreSQL inte igång, använder en annan port, är bunden någon annanstans, eller misslyckades med att starta. Om ett annat program äger 5432, kan PostgreSQL vara oförmöget att binda den porten. Kontrollera PostgreSQLs uppstartlogg innan du bestämmer dig för att stoppa den andra processen eller flytta PostgreSQL till en annan port.

Om du avsiktligt konfigurerade PostgreSQL på 5433, måste din klient använda 5433:

psql -h localhost -p 5433 -U postgres

“Fixa” inte en avsiktlig icke-standardport genom att ändra PostgreSQL tillbaka till 5432 om det inte faktiskt är din önskade arkitektur.

5. Kontrollera postgresql.conf: listen_addresses och port

PostgreSQLs inställning listen_addresses styr vilka TCP/IP-gränssnitt som accepterar anslutningsförsök. Det dokumenterade standardvärdet är localhost. Inställningen port är inställd på 5432 som standard. Båda inställningarna tillämpas vid serverstart, så ändringar kräver en omstart av servern.

För en strikt lokal utvecklingsdatabas ser de relevanta inställningarna vanligtvis ut så här:

listen_addresses = 'localhost'
port = 5432

Om listen_addresses är en tom sträng, lyssnar PostgreSQL inte på något IP-gränssnitt och endast Unix-domänuttag kan användas där det stöds. Omvänt, att sätta listen_addresses = '*' ber PostgreSQL att lyssna på alla tillgängliga gränssnitt; det är vanligtvis onödigt för en localhost-endast utvecklingsdatabas och kan öka exponeringen om autentisering och brandväggsregler inte är utformade för fjärråtkomst.

Om du kan ansluta via ett Unix-domänuttag men TCP på localhost misslyckas, fråga den aktiva servern för att lokalisera de aktiva filerna och inställningarna:

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

Detta är säkrare än att redigera den första postgresql.conf du hittar, särskilt på en maskin med flera kluster eller PostgreSQL-versioner. PostgreSQL stöder konfigurationsfiler utanför datakatalogen, så filsökvägar är inte universella. Se den officiella dokumentationen för konfigurationsfilplatser.

6. Om PostgreSQL körs i Docker, beror “localhost” på var klienten körs

Container-nätverk ändrar betydelsen av värdnamnet. Detta är en av de vanligaste anledningarna till att en databas är frisk medan en applikation fortfarande får connection refused.

Applikationen körs på värddatorn

PostgreSQL-containern behöver en publicerad värdport. En Compose-tjänst kan innehålla:

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

En klient som körs på din värd kan då använda:

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

Applikationen körs i en annan Compose-container

Inuti applikationscontainern refererar localhost till själva applikationscontainern, inte databascontainern. Docker Compose tillhandahåller DNS för tjänstenamn, så om databastjänsten heter db, ansluter applikationen normalt till:

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

Dockers officiella Compose-nätverksdokumentation skiljer explicit på containertillcontainer-tjänstenamnet och värdens publicerade port. Till exempel, om du mappar 8001:5432, använder containrar fortfarande db:5432, medan värden använder localhost:8001. Se Dockers officiella Compose-nätverksguide.

Innan du redigerar PostgreSQL själv, kontrollera:

docker compose ps
docker compose logs db

Om containern startar om, är loggen vanligtvis mer värdefull än att upprepade gånger ändra anslutningssträngar.

7. Behandla brandväggsregler som en senare kontroll för en localhost-avvisning

För en klient och server på samma maskin, börja inte med att öppna port 5432 för alla nätverk. Bekräfta först att PostgreSQL lyssnar lokalt. En bred brandväggsregel kan skapa onödig exponering utan att fixa en stoppad server.

Brandväggsundersökning blir mer relevant när:

• PostgreSQL finns i en VM, container-värd, WSL-miljö eller ett annat nätverksnamnrymde.
• Du ändrade listen_addresses för att tillåta icke-loopback-anslutningar.
• Lokal säkerhetsprogramvara tillämpar regler på loopback eller applikationsprocesser.
• Lyssnaren finns och fungerar från en miljö men inte en annan.

Om fjärråtkomst är avsiktlig, begränsa de tillåtna källnätverken och autentiseringsreglerna till vad som faktiskt krävs. Att port 5432 är nåbar överallt är inte ett krav för en lokal applikation.

8. Redigera inte pg_hba.conf förrän servern är nåbar

pg_hba.conf styr PostgreSQL-klientautentisering. En host-post gäller för TCP/IP-anslutningar. Den orsakar inte att en stoppad server börjar lyssna, så det är vanligtvis fel första åtgärd för connection refused.

När pg_isready rapporterar att servern accepterar anslutningar, kan ett autentiseringsfel legitimt leda dig till pg_hba.conf. För localhost-TCP-anslutningar är regler vanligtvis avgränsade till loopback-adresser som 127.0.0.1/32 och ::1/128, med databas, roll och autentiseringsmetod vald för din miljö.

PostgreSQL 18 ställer in password_encryption till scram-sha-256 som standard, och dess dokumentation markerar MD5-krypterade lösenord som föråldrade. Undvik att blindt kopiera gamla autentiseringsexempel. Se den aktuella pg_hba.conf-dokumentationen och aktuella autentiseringsinställningar.

På Unix-liknande system kan ändringar i pg_hba.conf laddas om med pg_ctl reload eller SELECT pg_reload_conf();. PostgreSQL dokumenterar en Windows-specifik skillnad: ändringar i pg_hba.conf tillämpas på efterföljande nya anslutningar utan samma SIGHUP-krav.

9. Testa med psql efter att lyssnaren är frisk

När pg_isready säger att servern accepterar anslutningar, testa samma väg som din applikation förväntar sig:

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

En lyckad psql-prompt berättar mycket mer än “tjänsten körs”: den bekräftar att en riktig PostgreSQL-klient nådde servern och passerade anslutnings- och autentiseringsstadierna för dessa parametrar.

Om psql fungerar men din applikation fortfarande rapporterar connection refused, jämför applikationskonfigurationen tecken för tecken:

• Värdnamn
• Port
• Databasnamn
• Användarnamn
• Huruvida appen körs på värden, i Docker, i en VM eller i en annan miljö
• Miljövariabler som laddas av den faktiskt körande processen
• Huruvida applikationen startades om efter att dess anslutningssträng ändrades

Ett vanligt exempel är en lokal terminal som använder localhost:5432 framgångsrikt medan en Dockeriserad webbapp också använder localhost:5432. Webbappen ringer då till sig själv, inte databastjänsten. I det fallet är det relevanta fixet att ändra containerns databasvärd till Compose-tjänstenamnet.

10. Läs serverloggen om PostgreSQL inte vill hålla sig igång

Om tjänsten startar och omedelbart avslutas, är nätverksfelet bara ett symptom. Uppstartloggen är där PostgreSQL förklarar varför den inte kunde bli redo.

Leta efter meddelanden om:

• Adress eller port redan i bruk
• Ogiltig postgresql.conf-syntax
• Saknad eller otillgänglig datakatalog
• Problem med filägande eller behörigheter
• Återställnings- eller WAL-problem
• Inkompatibel datakatalog och serverhuvudversion

Om du startar ett direkt hanterat kluster med pg_ctl, rekommenderar PostgreSQL att fånga serverutdata, till exempel med -l logfile. Projektets dokumentation för serveruppstart förklarar varför uppstartutdata är användbar för diagnos.

Snabb diagnos efter scenario

Vanliga fixar som kan göra situationen värre

Att sätta listen_addresses till '*' utan anledning

Detta kan göra PostgreSQL nåbar från ytterligare gränssnitt, men det är inte nödvändigt för en normal localhost-anslutning på samma maskin. Det kan också öka exponeringen. Använd den smalaste bindningen som matchar din arkitektur.

Att öppna port 5432 för hela nätverket

En brandväggsundantag kan inte få en stoppad PostgreSQL-process att lyssna. Bekräfta lyssnaren först, lägg sedan bara till det nätverksåtkomst du faktiskt behöver.

Att återställa postgres-lösenordet för en anslutningsavvisning

Lösenordsautentisering sker efter att klienten når PostgreSQL. Om TCP-anslutningen avvisas, adresserar ändring av lösenordet normalt fel lager.

Att redigera fel postgresql.conf

Maskiner med flera installationer kan innehålla flera konfigurationsfiler. Använd när som helst möjligt en fungerande lokal socket-anslutning och SHOW config_file;, eller identifiera datakatalogen för den serverprocess du faktiskt avser att köra.

Att anta att 5432 är obligatoriskt

5432 är standard, inte ett krav. Om ditt avsedda kluster är konfigurerat för 5433 och alla klienter använder 5433, är det giltigt. Konsistens är viktigare än att tvinga fram standarden.

När du bör ändra din felsökningsmetod

Du bör sluta arbeta med “connection refused” specifikt när pg_isready rapporterar att anslutningar accepteras eller psql når ett autentiserings-/databasfel. Vid den punkten gör nätverkslyssnaren sitt jobb, och att fortsätta ändra portar, brandväggsregler eller listen_addresses kan introducera nya problem.

På samma sätt, om PostgreSQL inte kan starta, byt från klientfelsökning till serveruppstartsdiagnos. Om en container ständigt startar om, gå till containerloggen. Om en värdklient fungerar men en containerklient misslyckas, gå till container-DNS och portmappning. Den användbara frågan är inte “Vilken PostgreSQL-inställning ska jag växla?” utan “På vilket lager slutar anslutningen att göra framsteg?”

Hur en lyckad fix ser ut

Du kan betrakta localhost-nåbarhetsproblemet som löst när alla följande är sanna för den miljö du faktiskt använder:

1. pg_isready -h localhost -p 5432 rapporterar accepting connections, eller rapporterar den motsvarande värd/port du avsiktligt konfigurerade.
2. Operativsystemet visar att PostgreSQL lyssnar på den förväntade adressen och porten.
3. psql kan nå servern med samma nätverksväg som applikationen.
4. Din applikation tar inte längre emot connection refused.
5. Om ett annat PostgreSQL-fel dyker upp, felsöker du det nya felet separat istället för att fortsätta modifiera lyssnaren.

Gränsen för denna procedur är viktig: den diagnostiserar om en PostgreSQL-server kan nås på den förväntade värden och porten. Den kan inte i sig fixa ett ogiltigt lösenord, saknad roll, saknad databas, SQL-fel, schemaproblem eller applikationsfel i anslutningspoolen. Dessa blir relevanta först efter att anslutningen passerar avvisningsstadiet.

För de flesta localhost-fall är den kortaste vägen fortfarande densamma: testa 5432 med pg_isready, bekräfta att den avsedda PostgreSQL-instansen körs, verifiera lyssnaren, och ändra sedan konfiguration. Den ordningen håller felsökningen fokuserad och minskar risken för att förvandla ett enkelt stoppat tjänstproblem till ett större nätverks- eller säkerhetsproblem.