Kako riješiti odbijanje veze PostgreSQL na localhost portu 5432

Ako PostgreSQL javlja “connection refused” na localhost:5432, prva stvar koju treba popraviti je dostupnost, a ne lozinka. Pokrenite pg_isready -h localhost -p 5432. Ako javi no response, PostgreSQL je obično zaustavljen, sluša na drugom portu ili adresi, radi u drugom okruženju poput Dockera ili ne uspijeva tijekom pokretanja. Ako javi accepting connections, poslužitelj je dostupan i prestanite tretirati problem kao odbijanje porta te istražite sljedeću poruku o pogrešci.

PostgreSQL koristi TCP port 5432 prema zadanim postavkama, a trenutna dokumentacija za PostgreSQL 18 navodi da listen_addresses prema zadanim postavkama ima vrijednost localhost. Od 11. rujna 2026. godine, PostgreSQL 18 je trenutno stabilno glavno izdanje, pri čemu je PostgreSQL 18.6 objavljen 13. kolovoza 2026.; PostgreSQL 19 Beta 3 i dalje je razvojno izdanje. Koraci za rješavanje problema u nastavku općenito se primjenjuju na podržane verzije PostgreSQL-a, ali nazivi paketa, nazivi usluga i lokacije datoteka razlikuju se ovisno o operativnom sustavu i instalatoru. Pogledajte službenu objavu izdanja PostgreSQL 18.6 i trenutnu dokumentaciju o postavkama veze.

1. Potvrdite da je pogreška doista “Connection Refused”

Počnite s točnim tekstom pogreške. Nekoliko neuspjeha veze PostgreSQL zvuči slično, ali ukazuje na različite slojeve stoga.

Ova razlika sprječava čestu skretanje: uređivanje lozinki ili pg_hba.conf dok ništa ne sluša na portu 5432. Te postavke su važne nakon što veza dosegne poslužitelj PostgreSQL.

2. Pokrenite pg_isready protiv točnog hosta i porta

pg_isready je vlastiti alat PostgreSQL-a za status veze. Pokrenite:

pg_isready -h localhost -p 5432

PostgreSQL dokumentira četiri izlazna stanja: 0 kada poslužitelj prihvaća veze, 1 kada odbija veze, 2 kada nema odgovora i 3 kada nije poduzet valjan pokušaj. Ne trebate ispravno ime baze podataka, korisničko ime ili lozinku samo da biste dobili osnovni status poslužitelja. Pogledajte službenu referencu za pg_isready.

Ako dobijete:

• localhost:5432 - accepting connections: port 5432 je dostupan. Pokušajte s stvarnom psql ili aplikacijskom vezom i riješite novu poruku ako ne uspije.
• localhost:5432 - rejecting connections: poslužitelj je odgovorio, ali još ne prihvaća normalne veze, što se može dogoditi tijekom pokretanja ili oporavka. Provjerite dnevnik poslužitelja i pričekajte ako je pokretanje legitimno u tijeku.
• localhost:5432 - no response: nastavite s provjerama poslužitelja i slušatelja u nastavku.

Također eksplicitno testirajte 127.0.0.1:

pg_isready -h 127.0.0.1 -p 5432

Ako 127.0.0.1 radi, ali localhost ne, problem je vjerojatnije povezan s rješavanjem imena ili IPv4/IPv6 vezanjem nego s potpunim padom PostgreSQL-a.

3. Provjerite radi li poslužitelj PostgreSQL

Ako ste instalirali PostgreSQL putem paketa operativnog sustava ili instalatora, koristite uobičajeni mehanizam za upravljanje uslugama tog paketa. Dokumentacija PostgreSQL-a preporučuje korištenje zapakirane infrastrukture za pokretanje kada je dostupna, umjesto izmišljanja zasebne metode pokretanja.

Ako izravno upravljate klasterom i znate njegov direktorij podataka, PostgreSQL pruža pg_ctl:

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

Vrijednost -D mora ukazivati na ispravan direktorij podataka PostgreSQL-a, koji je direktorij za taj klaster baze podataka. Ako je PGDATA konfiguriran, pg_ctl ga može koristiti umjesto toga. Službena dokumentacija za pg_ctl opisuje status, start, restart i reload.

Windows

Otvorite Usluge i potražite uslugu PostgreSQL koju je stvorio vaš instalator. Ako je zaustavljena, pokrenite je. Ako je instalirano više verzija PostgreSQL-a, provjerite pokrećete li instancu povezanu s direktorijem podataka i portom koji vaša aplikacija očekuje.

Linux

Nazivi paketa razlikuju se među distribucijama. Instalacija iz paketa može izložiti sustavnu uslugu poput postgresql ili jedinicu specifičnu za verziju/klaster. Koristite definiciju usluge paketa umjesto pretpostavljanja jednog univerzalnog naziva usluge.

macOS

Točan mehanizam pokretanja ovisi o tome je li PostgreSQL došao iz aplikacijskog paketa, Homebrewa, MacPorts-a, izvornog koda ili drugog paketa. Isti princip vrijedi: pokrenite instancu iz mehanizma koji ju je stvorio, a zatim ponovno pokrenite pg_isready.

Ako se poslužitelj odmah ponovno zaustavi, nemojte ga nastavljati ponovno pokretati. Pregledajte njegov dnevnik pokretanja. Loša vrijednost konfiguracije, nedostupan direktorij podataka, sukob portova, nedostajuća datoteka ili problem s oporavkom mogu spriječiti PostgreSQL da ostane aktivan.

4. Provjerite sluša li nešto stvarno na portu 5432

Pokrenuti proces PostgreSQL nije dovoljan ako je vezan na drugi port ili samo na Unix-domain utičnicu. Provjerite tablicu slušatelja operativnog sustava.

Linux

ss -ltnp | grep 5432

macOS

lsof -nP -iTCP:5432 -sTCP:LISTEN

Windows PowerShell

Get-NetTCPConnection -LocalPort 5432 -State Listen

Ako ne postoji slušatelj, ili PostgreSQL ne radi, koristi drugi port, vezan je negdje drugdje ili nije uspio pokrenuti se. Ako drugi program posjeduje 5432, PostgreSQL možda neće moći vezati taj port. Provjerite dnevnik pokretanja PostgreSQL-a prije odluke hoćete li zaustaviti drugi proces ili premjestiti PostgreSQL na drugi port.

Ako ste namjerno konfigurirali PostgreSQL na 5433, na primjer, vaš klijent mora koristiti 5433:

psql -h localhost -p 5433 -U postgres

Nemojte “popravljati” namjerni ne-zadani port vraćanjem PostgreSQL-a na 5432 osim ako to nije stvarno vaša željena arhitektura.

5. Provjerite postgresql.conf: listen_addresses i port

Postavka listen_addresses u PostgreSQL-u kontrolira koje TCP/IP sučelja prihvaćaju pokušaje veze. Dokumentirana zadana vrijednost je localhost. Postavka port prema zadanim postavkama ima vrijednost 5432. Obje se postavke primjenjuju pri pokretanju poslužitelja, pa promjene zahtijevaju ponovno pokretanje poslužitelja.

Za strogo lokalnu razvojnu bazu podataka, relevantne postavke obično izgledaju ovako:

listen_addresses = 'localhost'
port = 5432

Ako je listen_addresses prazan niz, PostgreSQL ne sluša na nijednom IP sučelju i samo Unix-domain utičnice se mogu koristiti gdje su podržane. Obrnuto, postavljanje listen_addresses = '*' traži od PostgreSQL-a da sluša na svim dostupnim sučeljima; to je obično nepotrebno za razvojnu bazu podataka samo za localhost i može povećati izloženost ako autentifikacija i pravila vatrozida nisu dizajnirana za udaljeni pristup.

Ako se možete povezati putem Unix-domain utičnice, ali TCP na localhostu ne uspijeva, upitajte aktivni poslužitelj da locirate aktivne datoteke i postavke:

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

Ovo je sigurnije od uređivanja prve postgresql.conf koju pronađete, posebno na računalu s nekoliko klastera ili verzija PostgreSQL-a. PostgreSQL podržava konfiguracijske datoteke izvan direktorija podataka, pa putanje datoteka nisu univerzalne. Pogledajte službenu dokumentaciju o lokacijama konfiguracijskih datoteka.

6. Ako PostgreSQL radi u Dockeru, “localhost” ovisi o tome gdje se klijent pokreće

Umrežavanje spremnika mijenja značenje naziva hosta. To je jedan od najčešćih razloga zašto je baza podataka zdrava, a aplikacija i dalje dobiva odbijanje veze.

Aplikacija se pokreće na host računalu

Spremniku PostgreSQL treba objavljeni host port. Compose usluga može sadržavati:

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

Tada klijent koji radi na vašem hostu može koristiti:

postgresql://postgres:VAŠA_LOZINKA@localhost:5432/VAŠA_BAZA

Aplikacija se pokreće u drugom Compose spremniku

Unutar spremnika aplikacije, localhost se odnosi na sam spremnik aplikacije, a ne na spremnik baze podataka. Docker Compose pruža DNS nazive usluga, pa ako je usluga baze podataka nazvana db, aplikacija se obično povezuje na:

postgresql://postgres:VAŠA_LOZINKA@db:5432/VAŠA_BAZA

Službena dokumentacija Docker Compose umrežavanja eksplicitno razlikuje naziv usluge između spremnika od objavljenog porta hosta. Na primjer, ako mapirate 8001:5432, spremnici i dalje koriste db:5432, dok host koristi localhost:8001. Pogledajte Službeni Docker Compose vodič za umrežavanje.

Prije uređivanja samog PostgreSQL-a, provjerite:

docker compose ps
docker compose logs db

Ako se spremnik ponovno pokreće, dnevnik je obično vrijedniji od ponovnog mijenjanja nizova veze.

7. Pravila vatrozida tretirajte kao kasniju provjeru za odbijanje localhosta

Za klijenta i poslužitelja na istom računalu, nemojte započeti otvaranjem porta 5432 za svaku mrežu. Prvo potvrdite da PostgreSQL sluša lokalno. Široko pravilo vatrozida može stvoriti nepotrebnu izloženost bez rješavanja zaustavljenog poslužitelja.

Istraživanje vatrozida postaje relevantnije kada:

• PostgreSQL je u VM-u, hostu spremnika, WSL okruženju ili drugom mrežnom prostoru.
• Promijenili ste listen_addresses da dopustite veze koje nisu loopback.
• Lokalni sigurnosni softver primjenjuje pravila na loopback ili procese aplikacija.
• Slušatelj postoji i radi iz jednog okruženja, ali ne i iz drugog.

Ako je udaljeni pristup namjeran, ograničite dopuštene izvorne mreže i pravila autentifikacije na ono što je stvarno potrebno. Dostupnost porta 5432 od svugdje nije preduvjet za lokalnu aplikaciju.

8. Nemojte uređivati pg_hba.conf dok poslužitelj nije dostupan

pg_hba.conf kontrolira autentifikaciju klijenata PostgreSQL-a. Zapis host primjenjuje se na TCP/IP veze. On ne uzrokuje da zaustavljeni poslužitelj počne slušati, pa je obično pogrešno prvo rješenje za connection refused.

Kada pg_isready javi da poslužitelj prihvaća veze, pogreška autentifikacije može legitimno usmjeriti na pg_hba.conf. Za TCP veze localhosta, pravila su obično ograničena na loopback adrese poput 127.0.0.1/32 i ::1/128, s bazom podataka, ulogom i metodom autentifikacije odabranom za vaše okruženje.

PostgreSQL 18 postavlja password_encryption na scram-sha-256 prema zadanim postavkama, a njegova dokumentacija označava MD5-šifrirane lozinke kao zastarjele. Izbjegavajte slijepo kopiranje starih primjera autentifikacije. Pogledajte trenutnu dokumentaciju za pg_hba.conf i trenutne postavke autentifikacije.

Na Unix-sličnim sustavima, promjene u pg_hba.conf mogu se ponovno učitati s pg_ctl reload ili SELECT pg_reload_conf();. PostgreSQL dokumentira razliku specifičnu za Windows: promjene u pg_hba.conf primjenjuju se na naknadne nove veze bez istog zahtjeva za SIGHUP.

9. Testirajte s psql nakon što je slušatelj zdrav

Kada pg_isready kaže da poslužitelj prihvaća veze, testirajte isti put koji vaša aplikacija očekuje:

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

Uspješan psql upit govori vam mnogo više od “usluga radi”: potvrđuje da je stvarni klijent PostgreSQL-a dosegao poslužitelj i prošao faze veze i autentifikacije za te parametre.

Ako psql radi, ali vaša aplikacija i dalje javlja odbijanje veze, usporedite konfiguraciju aplikacije znak po znak:

• Naziv hosta
• Port
• Naziv baze podataka
• Korisničko ime
• Pokreće li se aplikacija na hostu, u Dockeru, u VM-u ili u drugom okruženju
• Varijable okruženja učitane od strane stvarnog pokrenutog procesa
• Je li aplikacija ponovno pokrenuta nakon što se njezin niz veze promijenio

Čest primjer je lokalni terminal koji uspješno koristi localhost:5432, dok Dockerizirana web aplikacija također koristi localhost:5432. Web aplikacija tada zove samu sebe, a ne uslugu baze podataka. U tom slučaju, promjena hosta baze podataka spremnika na naziv Compose usluge je relevantno rješenje.

10. Pročitajte dnevnik poslužitelja ako PostgreSQL ne želi ostati aktivan

Ako se usluga pokrene i odmah izađe, mrežna pogreška je samo simptom. Dnevnik pokretanja je mjesto gdje PostgreSQL objašnjava zašto nije mogao postati spreman.

Potražite poruke o:

• Adresi ili portu koji su već u upotrebi
• Neispravnoj sintaksi postgresql.conf
• Nedostajućem ili nedostupnom direktoriju podataka
• Problemima s vlasništvom datoteka ili dopuštenjima
• Problemima s oporavkom ili WAL-om
• Nekompatibilnom direktoriju podataka i glavnoj verziji poslužitelja

Ako pokrećete izravno upravljani klaster s pg_ctl, PostgreSQL preporučuje hvatanje izlaza poslužitelja, na primjer s -l logfile. Dokumentacija o pokretanju poslužitelja projekta objašnjava zašto je izlaz pokretanja koristan za dijagnozu.

Brza dijagnoza po scenariju

Uobičajena rješenja koja mogu pogoršati situaciju

Postavljanje listen_addresses na '*' bez razloga

Ovo može učiniti PostgreSQL dostupnim s dodatnih sučelja, ali nije potrebno za normalnu vezu localhosta na istom računalu. Također može proširiti izloženost. Koristite najuže vezanje koje odgovara vašoj arhitekturi.

Otvaranje porta 5432 za cijelu mrežu

Izuzetak vatrozida ne može natjerati zaustavljeni proces PostgreSQL-a da sluša. Prvo potvrdite slušatelja, a zatim dodajte samo mrežni pristup koji stvarno trebate.

Ponovno postavljanje lozinke postgres za odbijanje veze

Autentifikacija lozinkom događa se nakon što klijent dosegne PostgreSQL. Ako je TCP veza odbijena, promjena lozinke obično rješava pogrešan sloj.

Uređivanje pogrešne postgresql.conf

Računala s više instalacija mogu sadržavati nekoliko konfiguracijskih datoteka. Kada je god moguće, koristite radnu lokalnu utičnicu veze i SHOW config_file;, ili identificirajte direktorij podataka procesa poslužitelja koji stvarno namjeravate pokrenuti.

Pretpostavljanje da je 5432 obavezan

5432 je zadani, a ne zahtjev. Ako je vaš željeni klaster konfiguriran za 5433 i svi klijenti koriste 5433, to je valjano. Dosljednost je važnija od forsiranja zadane vrijednosti.

Kada trebate promijeniti pristup rješavanju problema

Trebate prestati raditi na “connection refused” specifično kada pg_isready javi prihvaćanje veza ili psql dosegne pogrešku autentifikacije/baze podataka. U tom trenutku, mrežni slušatelj obavlja svoj posao, a nastavak mijenjanja portova, pravila vatrozida ili listen_addresses može uvesti nove probleme.

Slično tome, ako se PostgreSQL ne može pokrenuti, prebacite se s rješavanja problema na strani klijenta na dijagnozu pokretanja poslužitelja. Ako se spremnik neprestano ponovno pokreće, prebacite se na dnevnik spremnika. Ako klijent hosta radi, ali klijent spremnika ne uspijeva, prebacite se na DNS spremnika i mapiranje portova. Korisno pitanje nije “Koju postavku PostgreSQL-a trebam prebaciti?” već “Na kojem sloju veza prestaje napredovati?”

Kako uspješno rješenje izgleda

Možete smatrati problem dostupnosti localhosta riješenim kada su sve sljedeće tvrdnje točne za okruženje koje stvarno koristite:

1. pg_isready -h localhost -p 5432 javlja accepting connections, ili javlja ekvivalentni host/port koji ste namjerno konfigurirali.
2. Operativni sustav pokazuje da PostgreSQL sluša na očekivanoj adresi i portu.
3. psql može doseći poslužitelj koristeći isti mrežni put kao i aplikacija.
4. Vaša aplikacija više ne prima connection refused.
5. Ako se pojavi druga pogreška PostgreSQL-a, tu novu pogrešku rješavate zasebno, umjesto da nastavljate mijenjati slušatelja.

Ograničenje ovog postupka je važno: ono dijagnosticira je li poslužitelj PostgreSQL dostupan na očekivanom hostu i portu. Sam po sebi ne može popraviti nevažeću lozinku, nedostajuću ulogu, nedostajuću bazu podataka, SQL pogrešku, problem sa shemom ili grešku u bazenu veza aplikacije. To postaje relevantno tek nakon što veza prođe fazu odbijanja.

Za većinu slučajeva localhosta, najkraći put je i dalje isti: testirajte 5432 s pg_isready, potvrdite da je željena instanca PostgreSQL-a pokrenuta, provjerite slušatelja i tek tada promijenite konfiguraciju. Taj redoslijed održava fokus rješavanja problema i smanjuje šansu da jednostavan problem zaustavljene usluge pretvorite u veći problem umrežavanja ili sigurnosti.