Custom domain fails TLS handshake for mobile Safari/Node.js — server requests mid-connection renegotiation

Support
1

(Cross-referencing support ticket #1083530, filed with the same details.)

Netlify site name: quantum-marketresearch-tw (quantum-marketresearch-tw.netlify.app)

Custom domain: www.marketresearch.com.tw (also marketresearch.com.tw)

Error message (mobile Safari, iOS): “Safari無法打開網頁，因為無法與伺服器建立安全連線” (Safari can’t open the page because it can’t establish a secure connection with the server)

Yes, I asked Ask Netlify first — it confirmed my DNS is correct (only 75.2.60.5, no trace of the known bad 99.83.190.102 A record) and my certificate is validly issued, and said this needs a human to look at the edge/TLS layer.

What’s happening: Real visitors on mobile Safari cannot load any page on the site. I reproduced this independently of the browser with a bare Node.js TLS handshake test against the domain — no application code involved, pure TLS negotiation:

  • 3/3 attempts fail with SSL alert number 40 (handshake_failure), both with TLS 1.2 and TLS 1.3 explicitly forced.
    • By contrast, curl on the same machine succeeds — but its verbose output shows the server requesting a mid-connection TLS renegotiation (schannel: remote party requests renegotiation / schannel: renegotiating SSL/TLS connection). curl’s Windows TLS backend tolerates this; strict TLS clients (Node’s OpenSSL stack, and very likely mobile Safari’s TLS stack) don’t.
  • Already ruled out:
    • DNS resolves correctly and consistently to 75.2.60.5 (checked via local resolver and Google DNS 8.8.8.8).
      • SSL certificate state is “issued” via the site’s /ssl API, covering both domains, not expired (valid to 2026-10-30).
        • I manually renewed the certificate via Domain management → HTTPS → Renew certificate. No change — identical failure before and after, confirming this isn’t a certificate-freshness issue.
      • This looks like an edge/CDN-level TLS configuration issue causing server-initiated renegotiation, which modern strict TLS clients reject. Could someone with edge-node visibility take a look? Happy to provide anything else needed.
2

Update: recurring intermittently, 3 times today, always self-resolving within minutes

Since filing this, the error has recurred three separate times for the site owner (Taiwan, WiFi), on three different browsers: mobile Safari (original report), Edge, and Chrome. Each time it self-resolved within minutes without any action taken — no cache clearing, no config change on our end. Throughout all three recurrences, independent TLS testing from a different geographic location (outside Taiwan) has consistently shown the connection working cleanly (TLS 1.3, no errors). This pattern — fails unpredictably from one geographic location, always recovers on its own shortly after, never reproducible from elsewhere — suggests an edge node/PoP serving Taiwan traffic intermittently serves a bad TLS config, possibly getting cycled in and out of rotation. Could someone check the health/consistency of edge nodes serving APAC/Taiwan traffic for this site?