Intermittent TLS handshake failure (tlsv1 alert protocol version) on anycast IP 216.198.79.x

— valid cert, fails from some networks Domain shyan.world (Hobby plan), DNS A record → 216.198.79.1 (Vercel anycast). Dashboard shows Valid Configuration for both apex and www.

Symptom: the site loads on some networks but the TLS handshake fails on others, aborting before any certificate is presented with:

error:1404B42E:SSL routines:ST_CONNECT:tlsv1 alert protocol version

This does not appear to be a cert problem — SSL Labs reads a fully valid, trusted Let's Encrypt chain (RSA 2048, valid Jul 10 → Oct 8 2026, revocation Good, no chain issues). But SSL Labs can't complete a full assessment; it reports "Unexpected failure — multiple TLS servers behind the same IP" and "possibly only a draft version of TLS 1.3."

That reads like a TLS protocol/version-negotiation inconsistency across the anycast edge nodes: some nodes serve the valid cert, others reject the handshake with a protocol-version alert. It varies by network because different routes hit different nodes.

Already tried: DNS is correct; removed and re-added both domains (no change — expected, since the cert itself is valid).

Questions: (1) Is there a known issue with specific nodes on the 216.198.79.x / 64.29.17.x ranges rejecting certain TLS versions? (2) Anything I can do from a Hobby account to force a consistent TLS config across POPs?

Hi 5hy 8a8y,

This sounds worth narrowing down with SNI + TLS-version-specific tests. The SSL Labs result is useful, but I’d try to capture a smaller repro from both a working and failing network.

From each network, run:

date -u
dig A shyan.world +short
dig A www.shyan.world +short
curl -I http://shyan.world
openssl s_client -connect shyan.world:443 -servername shyan.world -tls1_2 -brief </dev/null
openssl s_client -connect shyan.world:443 -servername shyan.world -tls1_3 -brief </dev/null

The key is to include -servername shyan.world, otherwise the test may not match the custom-domain TLS path.

If TLS 1.2 succeeds but TLS 1.3 fails only from some networks, that points more toward a protocol negotiation/edge-path issue. If both fail from the affected network with no peer certificate, while the same commands succeed elsewhere, that’s stronger evidence that different anycast paths are hitting inconsistent TLS behavior for the same hostname.

I’d also test a direct custom-domain request to each resolved IP:

curl -4Iv --connect-timeout 10 --connect-to shyan.world:443:216.198.79.1:443 https://shyan.world/

and repeat with any other IPs you see. If one IP/path consistently fails and another works, include the failing IP, UTC time, and full openssl output.

I don’t think there’s a project-level setting on Hobby to force a specific POP or TLS config. I would avoid removing/re-adding the domain again if the dashboard already shows Valid Configuration, because that changes the state Vercel would need to inspect.