Useful walkthrough of why Postgres SSL and an HTTP reverse proxy do not compose the way people expect. Postgres speaks its own TLS profile on the wire; sticking nginx http{} in front of 5432 usually breaks the startup packet or leaves you terminating the wrong protocol. When I need encrypted DB access from apps outside the VPC I terminate TLS at Postgres itself (ssl=on, verify-full on the client) or use a dedicated TCP/TLS proxy that understands the Postgres protocol, not a generic HTTP proxy_pass.

Operationally I keep two checks after any change: openssl s_client -starttls postgres against the advertised host:port, and a libpq connection with sslmode=verify-full using the same CA the apps trust. If apps sit behind nginx for HTTP only, leave 5432 off the public listener entirely and reach the DB over a private network or SSH tunnel. Mixing "we put nginx in front of everything" with database ports is the fastest way to get intermittent handshake failures that look like auth bugs.