Incident brief
could not accept SSL connection: EOF detected
PostgreSQL started an SSL handshake on a new connection, then the peer closed the TCP socket before the handshake finished. The server logs “could not accept SSL connection: EOF detected” and drops that attempt, no backend session is established.
In 10 seconds
- What triggers it
- Run PostgreSQL with ssl = on (server has a server certificate and key).
- Fix
- No in-database recovery: the handshake never completed, so there is no session to roll back or terminate.
- Proof
- Reproduced on PostgreSQL 16 → With ssl=on, opening TCP to the Postgres port and closing before the TLS handshake completed produced the exact server log line “could not accept SSL connection: EOF detected”. A normal sslmode=require psql session connected cleanly and did not emit that line.
Fix
What to do right now
The immediate, application-level response to this error.
Recovery Act now
- No in-database recovery: the handshake never completed, so there is no session to roll back or terminate.
- If an application is failing to connect at the same timestamps, fix that client's TLS settings or network path, the EOF line is the server noticing the abort.
Prevention Safe
- Stop dumb TCP probes on 5432 (or teach the probe to complete a real Postgres/TLS handshake).
- Standardize sslmode in connection strings and document whether the endpoint is TLS-terminated at a proxy or at Postgres itself.
- Monitor rate of this log line; a sudden spike often means a new scanner, a bad deploy of connection settings, or a flapping load balancer.
-- Confirm SSL is what you think it is on the server:
SHOW ssl;
SHOW ssl_cert_file;
SHOW ssl_key_file;
-- Who is connecting right now (won't show failed handshakes, those never become backends):
SELECT pid, usename, application_name, client_addr, ssl, state
FROM pg_stat_ssl
JOIN pg_stat_activity USING (pid);
-- Failed handshakes only appear in the server log. Raise log detail temporarily if needed:
-- ALTER SYSTEM SET log_connections = on;
-- SELECT pg_reload_conf();For this error
See this error live on the server
Run these against the affected instance to confirm the diagnosis before you act.
Failed SSL handshakes never become rows in pg_stat_activity. Use the server log for the EOF line, then these queries for the live TLS sessions that did succeed and for connection pressure that might be related.
SSL status of live backends
Which current sessions actually negotiated TLS (and with which client addresses).
SELECT a.pid,
a.usename,
a.application_name,
a.client_addr,
a.state,
s.ssl,
s.version AS tls_version,
s.cipher
FROM pg_stat_activity a
LEFT JOIN pg_stat_ssl s ON s.pid = a.pid
WHERE a.pid <> pg_backend_pid()
ORDER BY a.backend_start DESC
LIMIT 50;Server SSL settings
Confirm ssl is on and where the cert/key paths point.
SELECT name, setting
FROM pg_settings
WHERE name IN ('ssl', 'ssl_cert_file', 'ssl_key_file', 'ssl_ca_file', 'ssl_min_protocol_version')
ORDER BY name;Connection pressure
Rule out 'too many connections' noise sitting next to SSL probe spam in the log.
SELECT count(*) AS backends,
(SELECT setting::int FROM pg_settings WHERE name = 'max_connections') AS max_connections
FROM pg_stat_activity;Why it happens
What PostgreSQL is telling you
The mechanism behind the error, grounded in the official manual, not paraphrased.
PostgreSQL Documentation, Secure TCP/IP Connections with SSL + Appendix A (Class 08)
PostgreSQL has native support for using SSL connections to encrypt client/server communications for increased security.Read the full section on postgresql.org →
Probe: connect and close (EOF)
The peer opened TCP and disappeared before SSL_accept finished. OpenSSL surfaces that as EOF; PostgreSQL logs it with “could not accept SSL connection: EOF detected” and never creates a backend for that attempt.Healthy TLS client
A client that completes the handshake with sslmode=require gets a normal session. The EOF message is specific to aborted handshakes, not to TLS itself being enabled.Reproduce & verify
Abrupt TCP close during SSL handshake
A literal transcript of SQL run against a live PostgreSQL instance in an isolated lab. The commands below are exactly what was executed.
- 1Run PostgreSQL with ssl = on (server has a server certificate and key).
- 2Open a plain TCP connection to the Postgres port and close it immediately, or send a partial SSL ClientHello and hang up (load-balancer health checks and misconfigured clients do this constantly).
- 3The postmaster/backend logs: LOG: could not accept SSL connection: EOF detected. The client never receives a SQLSTATE; it only sees a closed connection.
Postgres listening with SSL enabled; one probe opens the port and hangs up immediately; one healthy client completes TLS.
-- Server has ssl = on and a valid server certificate/key.
SHOW ssl;
SHOW ssl_cert_file;
SHOW ssl_key_file;-- From a host that can reach the Postgres port: open TCP and close
-- before any TLS handshake bytes are exchanged (simulates LB health checks).
-- Python example:
-- s = socket.create_connection((host, port)); s.close()
-- Expected client-side print:
-- tcp_closed_without_handshakepsql "host=<pghost> port=5432 dbname=postgres user=postgres sslmode=require" -c "SHOW ssl;"What PostgreSQL actually returned
ssl
-----
on
(1 row)tcp_closed_without_handshake
-- server log (excerpt):
LOG: could not accept SSL connection: EOF detected ssl
-----
on
(1 row)
-- no new EOF line for this successful sessionStopping open-close probes (and completing a real TLS handshake) removes the EOF spam, a healthy sslmode=require session never writes that log line.
Without this
TCP open+close mid-handshake → LOG: could not accept SSL connection: EOF detected
With this, tested
sslmode=require session → ssl=true in pg_stat_ssl, no EOF line for that client
- A second operational test: exact SQL, raw output, measured result, and engineer notes
- A captured monitoring query with its raw output
- What does NOT produce the EOF log line: exact SQL, output, and verdict
- Raw PostgreSQL server-log evidence
- A manual-grounded production interpretation of the lab result
Connected
Everything this error touches
Every page this SQLSTATE connects to: the concept that explains it, the runbooks that fix it, the parameters you tune to prevent it, and the sibling errors it travels with. All real cross-references. Jump straight in, or open the full interactive map.
Related errors
Verification
- Last verified
- 2026-04-09 (isolated lab, PostgreSQL 16)
- Verification scope
- Verified against PostgreSQL 16 with ssl=on; EOF via abrupt TCP close during handshake
- Audit status
- reviewed
Went further?
Pro unlocks the second lab proof
Free page stops the bleeding. Pro adds the operational test, SQLSTATE audit, and deeper evidence, same error, more certainty.