PostgreSQL reads pg_hba.conf from the top and uses the first record that matches the connection type, client address, database and user. There is no fall through. If that record rejects the login, later records are never tried. If nothing matches, access is denied.
What a record contains
Each line names a connection type, a client address range where relevant, a database, a user and an authentication method. The documentation describes the types you will see most:
| Type | Matches |
|---|---|
| local | Unix socket connections |
| host | TCP connections, with or without SSL |
| hostssl | TCP connections made with SSL only |
| hostnossl | TCP connections made without SSL |
The documentation also notes that a host record matches SSL and non SSL attempts alike. If you want encryption to be mandatory, use hostssl and make sure no broader host line sits above it.
The two gates
Two separate settings control who can reach the server. The first is network reach. The PostgreSQL docs state that remote TCP connections are not possible unless listen_addresses has an appropriate value, because the default is to listen only on the local loopback address. The second is pg_hba.conf, which decides who may authenticate once the network allows the packet through.
Both gates matter. A permissive pg_hba.conf on a server that only listens on loopback is not reachable from outside. A server bound to every interface with a broad rule is.
Why order is the whole game
Because the first match wins, a wide rule placed early can swallow narrower ones below it. Consider two lines in this order:
host all all 10.0.0.0/8 scram-sha-256
host billing app_runtime 10.0.5.0/24 reject
The second line is dead. Every connection from the 10.0.5.0 range already matched the first line. Put the specific rule first, then the general one.
A review routine
- List the records in the order PostgreSQL reads them.
- For each, ask which connections it catches and whether a line above already catches them.
- Look for broad address ranges with all as the database or user.
- Look for hostssl versus host, and decide whether plain TCP should exist at all.
- Confirm the authentication method is scram-sha-256 and not trust. See what trust means in pg_hba.conf.
- Check listen_addresses against what you expect.
- Keep the file in version control and review changes like code.
The documentation also describes a reject method, useful for filtering out specific hosts from a group, with a later line allowing the rest of a network. That pattern only works when the reject line comes first.
Managed databases
Hosted services may not expose this file at all. Check your provider's documentation for how network and authentication rules are set, and whether rule order matters there.
For connection encryption, see sslmode require versus verify-full.
Safeguard scans dependencies and infrastructure code in your repositories, and policy gates can hold a pull request that changes access rules. A free scan is at gold.safeguard.sh/scan.
Quick check
What happens if no pg_hba.conf record matches?
Access is denied.
Does a later record act as a backup if the first fails?
No. The docs say there is no fall through or backup. The first matching record decides.
Is pg_hba.conf enough to hide the server from the internet?
No. Also check listen_addresses and your firewall. They are separate controls.
Sources
Last reviewed: 19 October 2026.
