Fix Postgres Database Is Not Accepting Connections (2026)

The PostgreSQL server is refusing new client connections because the pg_hba.conf file is misconfigured, preventing authentication.

This often happens after a configuration change or when the server is first set up. The pg_hba.conf file is the gatekeeper for who can connect to your database and how. If it doesn’t explicitly allow a connection based on IP address, hostname, user, and database, it will be rejected with a "no pg_hba.conf entry for host" error.

Here are the most common reasons and their fixes:

Incorrect IP Address or Hostname in pg_hba.conf:
- Diagnosis: Check the pg_hba.conf file against the IP address or hostname of the client machine trying to connect. You can find the client’s IP by running ip a or ifconfig on the client machine.
- Fix: Edit pg_hba.conf to include an entry that matches the client’s IP address or hostname. For example, to allow a user myuser to connect to database mydb from any IP address on the 192.168.1.0/24 network using md5 password authentication:
```
host    mydb      myuser      192.168.1.0/24      md5
```
  If you need to allow connections from a specific host, use its IP:
```
host    mydb      myuser      192.168.1.100/32    md5
```
  The /32 is crucial for a single IPv4 address, and /64 is common for IPv6.
- Why it works: This line explicitly tells PostgreSQL to permit connections matching these criteria. Without a matching line, the connection is denied by default.
Incorrect Authentication Method Specified:
- Diagnosis: Review the authentication method (the last column) in your pg_hba.conf file for the relevant connection type (local, host, hostssl, hostnossl). Common methods include trust, reject, md5, scram-sha-256, password, and peer.
- Fix: Ensure the method specified is appropriate for your security needs and supported by your client. For most remote connections, scram-sha-256 (preferred for PostgreSQL 10+) or md5 is recommended for password-based authentication. If you’re using peer authentication, it only works for local connections via Unix-domain sockets and requires the OS username to match the database username.
```
# Example for SCRAM-SHA-256
host    mydb      myuser      192.168.1.0/24      scram-sha-256
```
- Why it works: The authentication method defines how the client’s identity is verified. If the client attempts a method not listed or supported by the server for that connection type, authentication fails.
pg_hba.conf File Not Reloaded After Changes:
- Diagnosis: You’ve edited pg_hba.conf but the server is still refusing connections.
- Fix: PostgreSQL needs to be told to re-read its configuration files. This is typically done by sending a SIGHUP signal to the PostgreSQL master process or by using the pg_ctl reload command.
  - Using pg_ctl:
```
sudo -u postgres pg_ctl reload -D /var/lib/postgresql/14/main
```
    (Replace /var/lib/postgresql/14/main with your actual data directory path).
  - Using systemctl (common on modern Linux):
```
sudo systemctl reload postgresql
```
- Why it works: PostgreSQL doesn’t automatically detect file changes. A reload signal forces it to parse the pg_hba.conf file again, applying the new rules.
Client is Trying to Connect via SSL When Server Isn’t Configured For It (or vice-versa):
- Diagnosis: Check the pg_hba.conf entries for hostssl and hostnossl. If your client is configured to require SSL (often the default for many tools), but your pg_hba.conf has only host entries (which don’t enforce SSL) or hostnossl entries for that connection, it might fail. Conversely, if the client is not configured for SSL and pg_hba.conf requires hostssl, it will also fail.
- Fix: Ensure the pg_hba.conf entries match the connection type your client is attempting. If you want to enforce SSL for a range of IPs, use hostssl:
```
hostssl    mydb      myuser      192.168.1.0/24      scram-sha-256
```
  If you want to allow non-SSL connections:
```
host       mydb      myuser      192.168.1.0/24      scram-sha-256
```
  You might need to configure SSL certificates on the server and client if hostssl is used.
- Why it works: hostssl specifically requires an SSL/TLS connection to be established before authentication occurs. hostnossl allows connections only if they are not SSL. host allows either.
Order of Rules in pg_hba.conf Matters:
- Diagnosis: You have multiple rules that could match a connection, and an earlier, more general, or incorrect rule is being applied. PostgreSQL processes pg_hba.conf from top to bottom and uses the first rule that matches the connection attempt (database, user, connection type, and client address).
- Fix: Reorder your pg_hba.conf file. More specific rules should generally come before more general rules. For example, a rule for a specific IP address should appear before a rule for an entire subnet. A rule for all databases or all users should be at the very end, often as a default reject rule.
```
# Specific host allowed first
host    mydb      myuser      192.168.1.100/32    scram-sha-256

# Then a broader subnet
host    mydb      myuser      192.168.1.0/24      scram-sha-256

# Catch-all for other users/databases on this subnet (if needed)
host    all       all         192.168.1.0/24      reject

# Default reject for everything else
host    all       all         0.0.0.0/0           reject
host    all       all         ::/0                reject
```
- Why it works: The first match wins. By placing the most restrictive or intended rules higher up, you ensure they are evaluated and applied correctly before broader, potentially conflicting rules.
Client IP Address is Unexpected (e.g., NAT, Docker):
- Diagnosis: The IP address you see in PostgreSQL logs (if available) or the IP you think your client is coming from is not what’s actually reaching the server. This is common with Network Address Translation (NAT), load balancers, or containerized applications (like Docker).
- Fix: Identify the actual IP address the PostgreSQL server sees from the client.
  - For Docker: If your client is in a Docker container, it often uses the host’s IP or a bridge network IP. You might need to expose ports or configure the Docker network. The client might be originating from 172.17.0.x or the host’s IP.
  - For NAT/Firewalls: The connection might be coming from the firewall’s public IP.
  - Debugging: Temporarily add a very broad host all all <client_ip>/32 <method> rule for the IP you suspect, then reload. Check PostgreSQL logs (/var/log/postgresql/postgresql-X.Y-main.log or similar) for connection attempts and the IP they are coming from. Once identified, create a permanent, specific rule.
- Why it works: You’re aligning the pg_hba.conf rule with the true source IP of the connection attempt as seen by the PostgreSQL server.

After applying any of these fixes, remember to reload the PostgreSQL configuration. If you’ve exhausted these common causes and are still facing issues, the next problem you’ll likely encounter is a password authentication failed error, indicating that the connection is now reaching the server but the provided credentials are incorrect.