5432
Where a PostgreSQL cluster listens — and, when psql refuses, the port that is either loopback-only, occupied by a second cluster, or gated by pg_hba.conf.
Run the line for your platform. Each one names the process holding the port and the address it bound to, which is usually the whole answer.
sudo lsof -nP -iTCP:5432 -sTCP:LISTEN`-n` keeps addresses numeric and `-P` keeps 5432 from becoming a service name, so the NAME column stays readable; `-iTCP:5432` picks the port and `-sTCP:LISTEN` keeps only listeners. COMMAND is usually `postgres`, PID is the number to act on, USER is the account it runs as, and NAME is the bind: `127.0.0.1:5432` is the `listen_addresses = 'localhost'` default and is exactly why another machine cannot connect, while `*:5432` means every interface. No output at all, with lsof exiting 1, means nothing is listening. Without `sudo` you see only your own processes, so a Postgres.app instance or a Docker-published port belonging to another user looks like a free port — and `com.docker.backend` in the COMMAND column means the container is the owner, so stop the container rather than the process.
sudo ss -tlnp 'sport = :5432'`-t` displays TCP sockets, `-l` only listening ones, `-n` skips service-name resolution, `-p` shows the process using each socket, and `sport = :5432` filters on the source port. Read the Local Address:Port column before anything else: `127.0.0.1:5432` is the stock `listen_addresses` default, `0.0.0.0:5432` means somebody set it to `*` or a real address, and `[::]:5432` is the IPv6 wildcard. The owner prints as `users:(("postgres",pid=1123,fd=6))`. Widen the filter to `'sport >= :5432 and sport <= :5435'` when several clusters are installed — a second one on 5433 is the single most common surprise here. The net-tools spelling `sudo netstat -tlnp | grep :543` does the same job with a slash-separated pid/program column; both need superuser privileges to name processes you do not own.
netstat -ano | findstr ":5432"`-a` displays all connections and the ports being listened on, `-n` expresses addresses and ports numerically, and `-o` includes the owning process ID as the last column. The row you want has State LISTENING; Local Address tells you whether it is `127.0.0.1:5432` or `0.0.0.0:5432`, which is the difference between a server only this machine can use and one the network can. Resolve the PID with `tasklist /FI "PID eq 4212"` — the PID filter accepts eq, ne, gt, lt, ge and le — and expect `postgres.exe`. `findstr` matches substrings, so confirm the column really is the local address and really ends at 5432 before you act on it.
Get-NetTCPConnection -LocalPort 5432 | Select-Object LocalAddress,LocalPort,State,OwningProcessMatches the port exactly instead of by substring, which makes it the safer of the two when several clusters are installed on nearby numbers. A `State` of `Listen` on `LocalAddress` `127.0.0.1` is the loopback-only case; `0.0.0.0` or `::` is network-wide. Feed `OwningProcess` to `Get-Process -Id` for the image name. If the result is empty and a start still fails, the port is reserved rather than occupied — `netsh interface ipv4 show excludedportrange protocol=tcp` lists the ranges Hyper-V, WSL2 and Docker Desktop claim at boot, and no process will ever show up for those.
`nmap -Pn -p 5432 db.example.com` checks reachability from where the client actually sits, with `-Pn` skipping host discovery so a host that drops pings is still scanned. The three states have precise meanings: `open` means an application on the target is listening on that port; `closed` means the host answered but nothing is listening; `filtered` means a firewall, filter or other network obstacle is blocking the probe so nmap cannot tell which of the two it is. For PostgreSQL, `closed` almost always means `listen_addresses` is still `localhost` — the server is running perfectly and simply not on that interface — while `filtered` means a security group or host firewall is dropping the packet. `--reason` shows which packet decided it, and `-sV` asks nmap to identify the service. Scan only hosts you are responsible for.
| What you see | What it means |
|---|---|
psql: error: connection to server at "db.example.com" (203.0.113.9), port 5432 failed: Connection refused — Is the server running on that host and accepting TCP/IP connections? | libpq prints that hint exactly when the kernel refused the connection, and the second half of the question is the important half. The host is up and answered with a reset, so this is almost never a firewall. Either the cluster is stopped, or it is running with `listen_addresses = 'localhost'` and is not on the interface you dialled. Run the probe on the database host and read the bind address; if it says `127.0.0.1`, no amount of firewall work will help. |
psql: error: connection to server at "db.example.com" (203.0.113.9), port 5432 failed: Connection timed out | Nothing answered at all. This is the packet-filter case that the refused message is not: a cloud security group, an on-host firewall, or a network ACL is dropping the SYN rather than rejecting it. A refusal comes back instantly and a drop takes the full connect timeout, so the wait itself is the signal. `nmap --reason` reports `filtered` here and `closed` for the refusal above. |
psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory — Is the server running locally and accepting connections on that socket? | The port was never involved. libpq took the Unix domain socket path because `host` was empty or looked like an absolute path, and no socket file exists there — usually because the server runs in a container, or because your client was built expecting `/tmp` while the packaged server puts its socket in `/var/run/postgresql`. Pass `-h 127.0.0.1` to force TCP, or point `-h` at the directory that really holds the socket. |
FATAL: no pg_hba.conf entry for host "10.0.0.5", user "app", database "appdb", no encryption | The best failure on this list: the network, the port and the server are all fine, and PostgreSQL got far enough to consult its host-based authentication rules and find none that match. Note the last field — it reports the encryption state, so `no encryption` against a rule that requires `hostssl` is the mismatch. Add or widen a line in `pg_hba.conf` and reload; nothing in the network needs touching. |
FATAL: password authentication failed for user "app" | Also not a port problem — the handshake completed and the credentials were rejected. Wrong password, or a `pg_hba.conf` method the client cannot satisfy: an old driver that only knows `md5` fails against a `scram-sha-256` line even with the right password. `FATAL: Peer authentication failed for user "app"` is the sibling case and means the opposite of a network fault: you came in over the Unix socket, where PostgreSQL compares your operating-system user name to the database role. |
LOG: could not bind IPv4 address "0.0.0.0": Address already in use — HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry. | The server's own words for `EADDRINUSE`, and the hint is doing real work: if a postmaster genuinely is running, find it with the probe for your platform and expect a second cluster rather than a mystery. If nothing is listening, the previous server left sockets in `TIME_WAIT` and the port frees itself shortly — waiting is the fix, and so is starting the new cluster on 5433. |
could not bind IPv4 address: Permission denied | Not the privileged-port rule, which only applies below 1024. On a Linux host this is usually SELinux or AppArmor refusing the bind for that binary — commonly after moving PostgreSQL to a non-standard port that the policy does not label — or a container started without the capability. Check the audit log rather than the firewall. On Windows the same shape means the port is inside a reserved exclusion range, where there is no owning process to find at all. |
The application connects but reads stale data, or a table it just created is missing | Two clusters, one port apart. A machine that has been upgraded in place often runs the old major version on 5432 and the new one on 5433, and a connection string that omits the port silently takes 5432. Ask the session which one it is on with `SHOW port;` and `SHOW server_version;` before assuming replication is broken. |
IANA registers 5432 to `postgresql` for TCP and UDP; PostgreSQL only ever uses the TCP half. The documentation is blunt about the number — the TCP port the server listens on is 5432 by default — but the running server is the authority, and `SHOW port;` is how you ask it. That matters more than it sounds, because a machine with two major versions installed usually has the second cluster on 5433, and a `psql` session that appears to be looking at the wrong database is very often looking at the right port on the wrong cluster. Two defaults then decide whether anyone can reach it. `listen_addresses` defaults to `localhost`, which the documentation describes as allowing only local TCP/IP loopback connections, so a stock server is unreachable from another machine until a human changes it; ask the server with `SHOW listen_addresses;` rather than reading a `postgresql.conf` it may not have loaded. And unlike MySQL, `localhost` in a libpq connection string is an ordinary TCP host name: libpq switches to a Unix domain socket only when `host` is empty or looks like an absolute path, in which case the value names the directory holding the socket file — `/tmp` in an upstream build, though packagers commonly move it. Finally, reaching the port is only half the job. `pg_hba.conf` decides per source address, user and database whether a connection that already completed its TCP handshake is allowed to go any further, which is why so many 5432 problems produce a server error rather than a network one.
Do not expose 5432 to the internet. The upstream defaults are already on your side — `listen_addresses` is `localhost`, so an internet-reachable PostgreSQL is something someone deliberately switched on — and what usually gets switched on beside it is a `pg_hba.conf` line broad enough to match the entire world. Two more defaults matter the moment the port is reachable. `ssl` defaults to `off`, so unless it was enabled the protocol runs in the clear, passwords and result sets included. And libpq's `sslmode` defaults to `prefer`, documented as "first try an SSL connection; if that fails, try a non-SSL connection" — opportunistic encryption that validates nothing and downgrades quietly, so it cannot notice an interceptor. If the database must be reached from elsewhere, tunnel it over SSH, put it on a private subnet, or restrict it by source address at the firewall. Require `scram-sha-256` in `pg_hba.conf` rather than `md5`, and never `trust` on anything but a socket. On the client, `verify-ca` checks the certificate chain up to the root certificate stored on the client, and `verify-full` also verifies that the server host name matches the name in the certificate — `verify-full` with an `sslrootcert` is the only combination that resists an interceptor.
All of these run in your browser — nothing is uploaded.
Ports people usually end up checking in the same session as 5432.
Almost always permissions. lsof and ss list the socket but hide the owning process when it belongs to another user, so a server started by a system account, by a container runtime or by launchd shows up as an anonymous listener until you re-run the command with sudo. On Windows the opposite happens: netstat shows nothing at all, yet a bind still fails, which means the port sits inside a range that Hyper-V, WSL2 or Docker Desktop reserved at boot.
Look at what it is first. An orphaned dev server is safe to kill; a database with a write in flight is not, and neither is a system service that something else depends on. If the owner is a container, stop the container instead — killing the process the host sees only makes the runtime restart it. When the process is something you need, moving your own service to another port is the faster fix.
The listener bound to 127.0.0.1 rather than 0.0.0.0. The probes on every page print the bound address next to the process for exactly this reason: a loopback bind is reachable from the machine itself and from nowhere else, no matter how the firewall is configured. Many frameworks made that the default deliberately, so it is usually a flag rather than a bug. If the address is already 0.0.0.0 and it still fails, the next suspect is a host firewall or a cloud security group.
Barely. Internet-wide scanners sweep the whole port range continuously, so an unusual number buys hours, not safety, and it costs you every colleague who now has to remember it. It does cut the noise in your logs from opportunistic scans of the default port, which is a real if modest benefit. Authentication, a firewall that restricts source addresses, and not exposing the service at all are the measures that actually change the outcome.
Still stuck on port 5432? browse every port in the reference — or go back to the failure message you actually got, above.