no pg_hba.conf entry for host

What it means

pg_hba.conf (“host-based authentication”) is the server’s list of who may connect, from where, and how they sign in. Each line names a connection type, a database, a user, a client address and a method. PostgreSQL reads the lines from the top and uses the first one that matches. When none matches, it refuses the connection with this message, before any password is asked for. Your password isn’t the problem, and changing it won’t help.

The message lists exactly what the server tried to match:

• host: your client’s IP address as the server sees it. Behind NAT, a VPN, a proxy or Docker, that’s often not your machine’s own address.
• user and database: the role and database you asked for.
• encryption: SSL encryption if the connection used TLS, no encryption if it didn’t. Lines of type hostssl only match TLS connections; hostnossl only match plain ones.

A close relative, pg_hba.conf rejects connection for host …, means a line did match, and its method is reject. The fix is the same: find which line, and connect in a way an earlier line allows.

The SQLSTATE is 28000 (invalid_authorization_specification).

Common causes

1. The server only accepts TLS, and you connected without it. The message ends in no encryption. The client used sslmode=disable, or prefer fell back to a plain connection. Amazon RDS for PostgreSQL 15 and later requires TLS by default (rds.force_ssl = 1) and reports it this way.
2. Your address isn’t listed. The server allows only localhost or a private network, and you’re connecting from elsewhere: home, a new office IP, a CI runner, another Docker network.
3. The rule names a different database or user. For example, the rule allows database appdb and you connected to postgres. Without a database name, psql and other libpq clients use your user name.
4. The file was edited but not reloaded, or the reload failed because of a typo and the server kept the old rules.
5. You edited a different file from the one the server reads (SHOW hba_file says which).

How to fix it

Read the four values in the message

They tell you what to allow. host "192.168.215.1", user "postgres", database "postgres", no encryption needs a line that covers that address, that user and that database, of type host (or hostnossl), or a TLS connection that matches a hostssl line instead.

Connect with TLS

If the server has hostssl lines, or a hostnossl … reject line, connect with TLS:

psql "host=<host> port=5432 user=<user> dbname=<database> sslmode=require"

In a URL, add ?sslmode=require. Use verify-full when you have the server’s CA certificate, so the client also checks it’s talking to the right server.

Look at the rules the server uses

As a superuser, on a connection that works (locally on the server, for example):

SHOW hba_file;

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

pg_hba_file_rules shows the file as it is now on disk, with an error column for lines the server can’t parse. That makes it a way to check an edit before you reload.

Add a rule and reload

Add a line above any broader reject line, with the narrowest address that works:

# TYPE   DATABASE  USER  ADDRESS          METHOD
hostssl  all       all   203.0.113.0/24   scram-sha-256

Then reload. No restart is needed:

SELECT pg_reload_conf();

(pg_ctl reload on the server does the same.) Check the server log afterwards. If a line has a mistake, the log says so and the server keeps the old rules:

LOG:  invalid connection type "hots"
CONTEXT:  line 6 of configuration file "/etc/seo/pg_hba.conf"
LOG:  /etc/seo/pg_hba.conf was not reloaded

An IPv4 address range matches only IPv4 connections, and an IPv6 range only IPv6 ones. If the host in the message is an IPv6 address such as 2001:db8::5, the rule needs an IPv6 range. Avoid trust on any line a network can reach; it lets anyone in as any user without a password.

On a hosted database

Managed services (RDS, Cloud SQL, Azure, Supabase and others) don’t let you edit pg_hba.conf. There, a message ending in no encryption usually means the service requires TLS: connect with sslmode=require or stronger. Which addresses may connect is set in the provider’s network or firewall settings instead.

Reproduce it

We started a temporary PostgreSQL 18.6 server with TLS turned on and this pg_hba.conf:

# TYPE  DATABASE  USER  ADDRESS        METHOD
local   all       all                  trust
host    all       all   127.0.0.1/32   trust
host    appdb     all   all            scram-sha-256

Connecting from the Mac to database postgres matches no line. With the default sslmode=prefer, psql tries TLS first, then without, and reports both:

psql -h localhost -p 55410 -U postgres -d postgres -c 'select 1'

psql: error: connection to server at "localhost" (::1), port 55410 failed: FATAL:  no pg_hba.conf entry for host "192.168.215.1", user "postgres", database "postgres", SSL encryption
connection to server at "localhost" (::1), port 55410 failed: FATAL:  no pg_hba.conf entry for host "192.168.215.1", user "postgres", database "postgres", no encryption

The host is 192.168.215.1, not ::1: that’s the address the server saw, after Docker’s port forwarding. The server’s log shows the SQLSTATE:

2026-10-09 10:07:06.858 UTC [96] 28000 FATAL:  no pg_hba.conf entry for host "192.168.215.1", user "postgres", database "postgres", no encryption

After adding hostssl all all 0.0.0.0/0 scram-sha-256 and running SELECT pg_reload_conf(), a connection with sslmode=require gets in, and one with sslmode=disable is still refused:

psql: error: connection to server at "localhost" (::1), port 55410 failed: FATAL:  no pg_hba.conf entry for host "192.168.215.1", user "postgres", database "postgres", no encryption

PostgreSQL 14.24 gives the same wording. Some provider documentation quotes an older form that ends in SSL off.

Our TLS-only test server (PostgreSQL 18.6 on port 54328) ends its file with hostnossl all all all reject instead, so a plain connection matches a line and gets the rejects form:

psql "host=localhost port=54328 user=inlet dbname=inlet sslmode=disable" -c 'select 1'

psql: error: connection to server at "localhost" (::1), port 54328 failed: FATAL:  pg_hba.conf rejects connection for host "192.168.148.1", user "inlet", database "inlet", no encryption

In Inlet

When the server turns a connection away, Inlet shows its message with a hint for common causes. Inlet supports every libpq sslmode, so if the message ends in “no encryption”, set the connection’s TLS mode to require (or verify-full, which checks the certificate against the ones macOS trusts) and connect again.