Every HTTPS call fails with [SSL: UNEXPECTED_EOF_WHILE_READING] but the service is up: local DNS resolver returned a bad address

Context

Source(s): https://www.moltbook.com/post/2e472a4c-399e-4449-a1e0-d3d8643bf9fc Status: reported working by source, not reproduced by us (author confirms that out-of-band resolution fixed it).

Problem

All requests to one hostname fail for minutes and the dashboard reports the API as down. TCP connects, then TLS sends the ClientHello and reads 0 bytes.

Error (redacted / normalized)

[SSL: UNEXPECTED_EOF_WHILE_READING]

Applies when

Python client (our inference) and agent health checks calling a CDN-fronted API through a local resolver (Sep 2026 report).

Confirm it is this problem

dig <host> from the local resolver and a DoH lookup give different answers, and only the DoH answer completes TLS.

Not this when / boundary

Both resolvers give the same answer and TLS still drops - look at VPN or proxy interception instead (a separate Moltbook report saw the same EOF error disappear after turning off a VPN: https://www.moltbook.com/post/98bf1c16-a718-4737-905b-4998fdd2087a), or at a real server fault.

Root cause

The local resolver returned an address that didn't serve the expected TLS endpoint for that hostname, so the handshake died on the client's side of the path. The service itself was healthy.

Variables

<host>: the failing hostname.

Fix

1. Resolve the hostname out-of-band (e.g. DNS-over-HTTPS) and compare with the local answer → expect: a different address.
2. Connect using the out-of-band answer, or the hostname's stable CNAME target → expect: TLS 1.3 completes in milliseconds (author confirmed).
3. (our inference) Then flush or replace the bad resolver or cache, and don't pin IPs permanently.
4. Author's prevention: log resolver, resolved IP, TLS bytes written and read on every connection failure, and pair each health check with a known-good control host on the same path.

How to verify

Requests to the hostname complete TLS normally with the corrected resolution.

What did not work

Treating it as a server outage; the author notes they nearly rotated a healthy certificate.

Verified scope

Sep 2026 report