## Intermittent ERR_SSL_PROTOCOL_ERROR on custom domain — Chrome/Edge only, Firefox unaffected
**Project:** mymathstrainer (Hobby plan)
**Domain:** www.mymathstrainer.ie
### Symptom
Visitors intermittently get `ERR_SSL_PROTOCOL_ERROR` in Chrome and Edge when loading `www.mymathstrainer.ie`. Firefox is never affected. Once a visitor successfully completes one connection in a browser session, subsequent loads in that session work fine — the failure only seems to hit fresh/cold connections.
### What I’ve ruled out
- **Firewall:** Bot Protection is Inactive, 0 custom rules, 0 requests Challenged in the affected window.
- **Domains:** All three domains (`mymathstrainer.ie`, `www.mymathstrainer.ie`, `mymathstrainer.vercel.app`) show “Valid Configuration” with no duplicate/pending certs.
- **Local network on my end:** No proxy configured (`netsh winhttp show proxy` → direct access), no third-party AV/interception software found on the test machine.
### Diagnostic script results (ran official `vercel-connect-debug` tool)
Tested all 8 anycast IPs currently resolving for the domain:
`216.198.79.1`, `216.198.79.65`, `216.198.79.129`, `216.198.79.193`, `64.29.17.1`, `64.29.17.65`, `64.29.17.129`, `64.29.17.193`
Every single one of the 8 IPs:
- Returned `200 OK` with the correct page content and a valid Vercel-issued cert
- 0% ping packet loss, 12–40ms latency
- Showed this in the curl/Schannel handshake log, twice per connection, before succeeding:
```
* Request completely sent off
* schannel: remote party requests renegotiation
* schannel: renegotiating SSL/TLS connection
* schannel: SSL/TLS connection renegotiated
* schannel: remote party requests renegotiation
* schannel: renegotiating SSL/TLS connection
* schannel: SSL/TLS connection renegotiated
< HTTP/1.1 200 OK
```
This is **100% reproducible across the entire anycast range** for this domain — not just one flaky edge node.
### DNS (for reference, via 8.8.8.8)
```
Name: 0adb41897e277c87.vercel-dns-017.com
Addresses: 216.198.79.65, 64.29.17.65
Aliases: www.mymathstrainer.ie
```
### My working theory
Chrome/Edge use BoringSSL, which for years has deliberately refused to support server-initiated renegotiation on regular HTTPS page loads — the browser just kills the connection, and that specific failure mode surfaces as `ERR_SSL_PROTOCOL_ERROR`. Firefox/NSS tolerates it more gracefully. Windows Schannel (what `curl.exe` used above) also handles it transparently, which is why the raw test still succeeds even though the same event is present.
I can’t tell from the client side whether this is genuine TLS 1.2-style renegotiation, or Schannel mislabeling a normal TLS 1.3 post-handshake `NewSessionTicket` message (which would be benign and unrelated) — that distinction needs server-side TLS logs. Could someone from the Vercel team check the edge/TLS termination config for this project/domain for anything triggering a renegotiation event during the handshake?
Happy to provide the full debug script output if useful.
### Possibly related
Not claiming any of these are the exact same bug, but there’s a recurring pattern of intermittent/inconsistent TLS behavior reported on this same anycast range (`216.198.79.x` / `64.29.17.x`) that seems relevant:
- [Intermittent TLS handshake failure (tlsv1 alert protocol version) on anycast IP 216.198.79.x](Intermittent TLS handshake failure (tlsv1 alert protocol version) on anycast IP 216.198.79.x) — SSL Labs flagged their domain with *“Unexpected failure — multiple TLS servers behind the same IP.”* If several distinct TLS terminators genuinely sit behind one anycast IP via load balancing, that would explain both their intermittent per-network failures and my renegotiation event as different symptoms of the same underlying multi-terminator inconsistency.
- [TLS handshake aborts at 5 bytes from residential ISPs but works from datacenters](TLS handshake aborts at 5 bytes from residential ISPs but works from datacenters) — same anycast range, home WiFi fails while phone hotspot/datacenter probes succeed, hypothesized as an “edge POP cert binding desync.” Still unresolved as of posting.
- [Custom domain cert stuck on 1 of 8 edge IPs — other 7 reset TLS (cleanbumblebee.com)](Custom domain cert stuck on 1 of 8 edge IPs — other 7 reset TLS (cleanbumblebee.com)) — same 8-anycast-IP-per-domain topology, but a harder failure mode (7/8 IPs reset the connection outright rather than renegotiating).
Given how many independent reports describe inconsistent TLS behavior specifically on this IP range, it seems worth checking whether there’s a shared root cause in how TLS/cert state is distributed or load-balanced across POPs on `216.198.79.x` / `64.29.17.x`.