| Port | 5432 |
|---|---|
| Transport | TCP |
| Service | PostgreSQL |
| Category | Databases and caches |
| Range | registered (1024–49151) |
| Encrypted | Optional: plaintext with STARTTLS upgrade |
| Exposure | Private network or VPN only |
Port 5432 PostgreSQL · TCP
PostgreSQL. The server listens on localhost by default (listen_addresses), and pg_hba.conf decides who may connect from where and how; "host all all 0.0.0.0/0 md5" plus an open firewall is the configuration behind most exposed PostgreSQL servers.
What runs on port 5432
PostgreSQL. The server listens on localhost by default (listen_addresses), and pg_hba.conf decides who may connect from where and how; "host all all 0.0.0.0/0 md5" plus an open firewall is the configuration behind most exposed PostgreSQL servers. TLS is negotiated in-protocol; require it with hostssl rules and sslmode=verify-full on clients. Scram-sha-256 is the modern password method.
Software that uses it: PostgreSQL · PgBouncer (6432) · Patroni · TimescaleDB, Citus · Amazon RDS/Aurora, Cloud SQL, Neon, Supabase
Should port 5432 be open?
Private network or VPN only. Nothing good comes from this port being reachable from the internet. Keep it on an internal network, reach it over a VPN or an SSH tunnel, and firewall it from everything that does not need it.
- psql "host=db port=5432 dbname=x user=y sslmode=require" tests TLS and auth together.
- pg_hba.conf is read top to bottom; the first matching line wins, which explains most "no pg_hba.conf entry" surprises.
- Paste EXPLAIN (ANALYZE, FORMAT JSON) output into our EXPLAIN visualizer to read a plan.
Check port 5432
# on the host: is anything listening, and which process? ss -ltnp 'sport = :5432' sudo lsof -i :5432 # from another machine: is it reachable? nc -zv host 5432 nmap -p 5432 host curl -v telnet://host:5432 # raw TCP connect test, Ctrl-C to leave
A port that answers from the internet when it should not is the finding; nmap from a machine outside your network (or a VPS) is the honest test, because scans from inside the LAN pass the firewall you are trying to verify.
Allow or block port 5432
# ufw (Ubuntu/Debian) sudo ufw allow from 10.0.0.0/8 to any port 5432 proto tcp sudo ufw deny 5432/tcp # nftables nft add rule inet filter input ip saddr 10.0.0.0/8 tcp dport 5432 accept nft add rule inet filter input tcp dport 5432 drop # iptables (legacy) iptables -A INPUT -p tcp --dport 5432 -s 10.0.0.0/8 -j ACCEPT iptables -A INPUT -p tcp --dport 5432 -j DROP # firewalld sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=10.0.0.0/8 port port=5432 protocol=tcp accept'
Replace 10.0.0.0/8 with the networks that need access. Allowing by source address is the rule that matters; "allow 5432" with no source is just "open".
Related ports
Part of the port number reference. Ports are 16-bit numbers; see also the subnet calculator and the packet decoder, which shows ports inside TCP and UDP headers.
Questions
Is port 5432 TCP or UDP?
TCP. PostgreSQL is a connection-oriented protocol; there is no UDP service on 5432 by default (a scanner reporting UDP 5432 open is usually seeing a filtered port).
Is port 5432 encrypted?
Optional: plaintext with STARTTLS upgrade. The connection starts in plaintext and the client asks to upgrade; a server that accepts logins before the upgrade is the common weakness, so configure it to require TLS.
How do I check whether port 5432 is open?
On the server, ss -ltnp (or -lunp for UDP) shows whether something listens on 5432 and which process. From another machine, nc -zv host 5432 or nmap -p 5432 host tests reachability. "Open" in a scan means something answered; a firewall usually makes the port filtered (no answer) rather than closed (RST).
Can PostgreSQL run on a different port?
Yes; the number is a convention, not a requirement. Changing it reduces log noise from scanners but does not add security, and every client, firewall rule and monitoring check then needs the new number. Keep the default unless you have a concrete reason.