Connection issue to postgres sql flexible server

Question

Hi, from today morning we are facing issue with connection to postgress db. There was a notification for a planned for Scheduled Maintenance to Azure Database for PostgreSQL Flexible Server (Tracking ID RMB6-HFZ). Error we receive: FATAL: pg_hba.conf rejects connection for host ... In Networking we tried with recommendations about allowing IP's, but no success so far.

Answer 1

Hello Beriflapp DEV,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you are having connection issue to postgres sql flexible server.

To resolve Azure PostgreSQL Flexible Server connection failures showing “FATAL: pg_hba.conf rejects connection…”, begin by verifying whether your server uses Public Access, Private Endpoint, or VNet Integration, since access control depends on these modes rather than manual pg_hba configuration. Immediately test TLS with:

psql "host=<server>.postgres.database.azure.com port=5432 dbname=<db> user=<user> sslmode=require"

Correct TLS usage and client egress IP alignment are foundational steps. - https://learn.microsoft.com/en-us/azure/postgresql/troubleshoot/how-to-troubleshoot-common-connection-issues, and https://stackoverflow.com/questions/62301317/azure-database-for-postgresql-server-no-pg-hba-conf-entry-for-host

If public access is enabled, determine your current outbound IP and ensure it is permitted in Networking > Firewall Rules, because maintenance can shift outbound paths. Always enforce encrypted connections by keeping sslmode=require and avoiding disabling require_secure_transport. Reference tests and TLS rules here: Azure TLS guidance and CLI error behavior.

For private endpoint and VNet-integrated deployments, confirm that you are connecting from inside the permitted subnet, and validate that DNS resolves your server name to a private IP using: nslookup <server>.postgres.database.azure.com

If resolution shows a public IP from inside the VNet, re-link your Private DNS Zone. Guidance: VNet Integration Networking and Private Endpoint DNS checks.

If authentication was switched to Microsoft Entra-only, all Postgres-password users will fail with the same pg_hba-style message. Verify authentication settings and re-enable Postgres authentication or migrate clients to token-based login. See the confirmed behavior here: Auth mode causing pg_hba rejection.

Finally, if errors aligned with the scheduled maintenance (Tracking ID RMB6‑HFZ), implement retry logic because short‑lived disconnects are normal, but persistent failures beyond 60 seconds require investigation. Confirm event timing in Azure Service Health: Maintenance behavior and Planned Maintenance Panel.

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

---

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Answer 2

Hi Beriflapp DEV,

Thank you for the update. This behavior can occur after scheduled platform maintenance.

During the January 23 maintenance, Azure re-applied database connection security and TLS settings and may also have rotated the TLS certificate chain. If a client was attempting a non-SSL connection, or if it could not validate the updated certificate chain, the SSL handshake would fail and the connection would be rejected. Disabling Require Secure Transport allowed non-SSL connections, which explains why connectivity was restored.

To avoid this in the future and continue using secure connections, we recommend configuring clients to connect using sslmode=require or, preferably, sslmode=verify-ca (or verify-full) with the current Azure Database for PostgreSQL root CA certificates installed in the client trust store. Once clients are successfully connecting using SSL, Require Secure Transport can be re-enabled on the server to enforce encrypted connections.

This ensures stable and secure connectivity across future maintenance events.

Hope this helps, Please let us know if you have any questions and concerns.