How to fix FATAL: no pg_hba.conf entry for host in PostgreSQL

Determine which IP address the client is connecting from. The error message usually includes this information. For example:

FATAL: no pg_hba.conf entry for host "192.168.1.100", user "myuser", database "mydb", SSL off

This tells you:
- Client IP: 192.168.1.100
- User: myuser
- Database: mydb
- Connection type: TCP/IP without SSL (host)

If connecting from localhost/127.0.0.1, the error typically indicates a 'local' socket or 'host' with loopback IP.

Find where pg_hba.conf is stored on your PostgreSQL server:

Linux/Unix:

# Typical locations
/etc/postgresql/VERSION/main/pg_hba.conf
/var/lib/postgresql/VERSION/main/pg_hba.conf
/usr/local/var/postgres/pg_hba.conf (macOS)

Windows:

C:\Program Files\PostgreSQL\VERSION\data\pg_hba.conf

Find via psql (if you have local access):

sudo -u postgres psql -c "SHOW hba_file;"

This command shows the exact path PostgreSQL is using.

Open pg_hba.conf in a text editor and examine existing rules. The format is:

TYPE  DATABASE  USER  CIDR-ADDRESS  METHOD

Example entries:

# Local connections (Unix socket)
local   all             all                                     peer

# IPv4 localhost
host    all             all             127.0.0.1/32            scram-sha-256

# IPv6 localhost
host    all             all             ::1/128                 scram-sha-256

# Remote IPv4 connections
host    all             all             192.168.1.0/24          scram-sha-256

# Reject all other connections
host    all             all             0.0.0.0/0               reject

Note that rules are evaluated in order—the first matching rule wins. Rules that appear early must be more specific than later rules.

Based on the error message, add a new rule for the client IP. Place it BEFORE any 'reject' rules, otherwise the reject will match first and your new rule will never be reached:

For the example error (192.168.1.100, user myuser, database mydb):

# Allow myuser from 192.168.1.100
host    mydb        myuser      192.168.1.100/32      scram-sha-256

# Or allow all users from that network
host    all         all         192.168.1.0/24        scram-sha-256

Choose the authentication method:
- scram-sha-256 - Strongest password method and the recommended default (PostgreSQL 10+, default since 14). Prefer this for all network connections.
- md5 - Legacy password method. It is cryptographically weaker than SCRAM and vulnerable to known attacks, so prefer scram-sha-256 wherever your clients support it. Note that md5 is kept mainly for old client compatibility; if you switch a user to scram-sha-256, the stored password must be SCRAM-hashed (set password_encryption = 'scram-sha-256' in postgresql.conf and reset the user's password with ALTER ROLE myuser PASSWORD '...';) or authentication will fail.
- trust - DANGEROUS: allows connection with NO password whatsoever for ANYONE whose connection matches the rule (IP/user/database). It performs zero authentication. Never use trust for host/hostssl (networked) rules, and never combine it with a broad CIDR such as 192.168.1.0/24 or 0.0.0.0/0 — doing so hands your database to anyone who can reach the port. It is only ever acceptable for tightly-scoped local development (e.g. a local Unix-socket rule on a single-user machine). For remote access always use scram-sha-256.
- reject - Deny the connection.

CIDR notation:
- 192.168.1.100/32 - Single IP address (most secure; grant the narrowest range that works)
- 192.168.1.0/24 - Network (192.168.1.0 to 192.168.1.255)
- 0.0.0.0/0 - All IPv4 addresses (not recommended in production)

Fixing pg_hba.conf only controls *which* clients are authorized. PostgreSQL must also be *listening* on the network interface the client connects to, which is governed by listen_addresses in postgresql.conf. If pg_hba.conf is correct but listen_addresses = 'localhost' (the common default), remote clients will no longer hit the pg_hba error — instead they'll get connection refused/could not connect, and it's easy to wrongly conclude the pg_hba fix failed.

Check the current value:

sudo -u postgres psql -c "SHOW listen_addresses;"
sudo -u postgres psql -c "SHOW config_file;"   # path to postgresql.conf

Edit postgresql.conf to listen on the relevant interface:

# Bind to a SPECIFIC address the clients reach (preferred)
listen_addresses = 'localhost,10.0.0.5'

# '*' listens on ALL interfaces — only do this when the host is
# firewalled/in a private network, since it exposes the port broadly.
# listen_addresses = '*'

For security, bind to the specific private/internal address(es) you actually need rather than blindly using '*', and keep the port behind a firewall or security group. Note that listen_addresses is not reloadable — changing it requires a full restart (not just pg_reload_conf()):

sudo systemctl restart postgresql

Verify the server is listening where you expect:

ss -ltnp | grep 5432

Apply the pg_hba.conf changes by reloading the configuration. (pg_hba.conf changes only need a reload; a listen_addresses change from the previous step requires a full restart.)

Reload (no downtime, sufficient for pg_hba.conf):

# Linux with systemd
sudo systemctl reload postgresql

# Or with pg_ctl
pg_ctl reload -D /path/to/data/directory

# Or from psql (as superuser)
SELECT pg_reload_conf();

If reload fails or doesn't work, restart PostgreSQL:

# Linux with systemd
sudo systemctl restart postgresql

# Or with pg_ctl
pg_ctl restart -D /path/to/data/directory

# macOS with Homebrew
brew services restart postgresql

# Docker
docker restart postgres_container_name

Reload is preferred for pg_hba.conf because it doesn't drop existing connections.

Confirm PostgreSQL parsed your rules as expected using the pg_hba_file_rules view (PostgreSQL 10+), which surfaces parse errors per line:

SELECT line_number, type, database, user_name, address, auth_method, error
FROM pg_hba_file_rules;

Any non-null error column points to a malformed line that was ignored.

Test from the client machine:

psql -h postgres-server-ip -U myuser -d mydb

From the PostgreSQL server (if connecting locally):

psql -h 127.0.0.1 -U myuser -d mydb

In application connection strings:

postgresql://myuser:password@postgres-host:5432/mydb

If the error persists, check PostgreSQL logs for more details:

# Linux
sudo tail -50 /var/log/postgresql/postgresql.log

# Or from psql
SELECT pg_current_logfile();