# no pg_hba.conf entry for host

> What "no pg_hba.conf entry for host" means, why SupaHost's own Postgres shouldn't return it, and how to find the server that does (often a local Postgres or your previous host).

Source: https://supahost.app/kb/no-pg-hba-entry · Updated 2026-11-11

## What you see

```
FATAL:  28000: no pg_hba.conf entry for host "198.51.100.23", user "postgres", database "p_app_one", no encryption
```

The last part varies (`no encryption`, `SSL encryption` or `GSS encryption`) depending on how the client connected.

## Why it happens

`pg_hba.conf` is the server's list of who may connect from where, and how they must prove who they are. Postgres reads it top to bottom and uses the first line that matches the client's address, user, database and connection type. If no line matches, it refuses the connection with this error before checking any password.

You'll mostly see it in two situations:

- The server only allows encrypted connections (`hostssl` lines) and your client connected without SSL.
- The server only allows certain IP addresses and yours isn't one of them.

## Why SupaHost probably isn't the server saying it

SupaHost manages `pg_hba.conf` for you, and you can't edit it. Its rules accept password sign-in (`scram-sha-256`) from any address, encrypted or not, and Postgres itself is only reachable through the SSH tunnel on Business and Enterprise. So when you connect through the tunnel, there's always a matching line. A wrong password gives [password authentication failed](/kb/password-authentication-failed), not this error.

If you see it, your client is almost always talking to a different server.

## How to fix it

1. **Check for a local Postgres on the same port.** If something on your machine already listens on 5432, `ssh -L 5432:...` can't bind it and prints `Address already in use`, and your client reaches the local server instead. Forward a free port:

   ```bash
   ssh -N -L 55432:127.0.0.1:5432 supahost@acme.supahost.space
   ```

   Then connect with port 55432:

   ```bash
   psql "postgresql://postgres:<password>@127.0.0.1:55432/p_app_one" -c "select current_database();"
   ```

   The query should print `p_app_one`.

2. **Check your connection string.** A `DATABASE_URL` that still points at your previous host (Supabase Cloud, RDS, Heroku and so on) gets that host's rules. Copy the SupaHost string from *Dashboard → your project → **Connect** tab → Database → Show connection string*.

3. **If you meant to reach another provider** (for example running `pg_dump` against your old database before moving), follow that provider's rules. Usually that means adding `sslmode=require` to the connection string, or adding your IP to its allow list:

   ```bash
   pg_dump "postgresql://user:pass@old-host.example.com:5432/app?sslmode=require" -Fc -f app.dump
   ```

4. **Confirm which server answered.** Once connected, run:

   ```sql
   select inet_server_addr(), inet_server_port(), current_database(), version();
   ```

   Through the SupaHost tunnel, the database is `p_<project>` and the version is Postgres 17.

## On SupaHost

- To check the database itself, SSH in and run `sudo supahost-psql app-one`, or use Studio's SQL editor. If those work and your local client doesn't, the problem is between your client and the tunnel.
- Importing from Supabase Cloud through *Dashboard → your project → **Import** tab* needs the Session pooler string (port 5432, user `postgres.<ref>`), not the direct `db.<ref>.supabase.co` host.

## Related

- [Connection refused or timeout when connecting to Postgres](/kb/connection-refused)
- [FATAL: password authentication failed](/kb/password-authentication-failed)
- [SSH access and direct Postgres](/docs/platform/ssh)
- [Connecting directly to Postgres (psql, pg_dump, ORMs)](/kb/direct-postgres-connection)