Yes @piwel — we reproduced what appears to be the same issue independently, on a different site, in a different country, with a different device model. Environment: iPhone 15 Pro and iPhone 11 Pro, both iOS 26.5.2 Mobile Safari; also reproduced in Chrome for iOS (same WebKit networking stack) Cloudflare-proxied hostname (news site, ladiaria.com.uy), Montevideo, Uruguay Both Wi-Fi and cellular Never reproduced in Private Browsing Affected multiple users for months; a manual reload always succeeded Captured with rvictl over USB. Failed navigation (21:17:21 UTC, 2026-07-14): Safari sends QUIC Initial packets immediately followed by 0-RTT application data. The Cloudflare edge responds correctly within ~13 ms (Initial + ACK + CRYPTO + protected payloads). Safari sends its Handshake packet and then abandons the connection. It retries 6 times within ~75 ms, each with a fresh DCID, racing both edge IPv4 addresses; every attempt is abandoned the same way. The edge keeps retransmitting CRYPTO at 21:17:23 and 21:17:26 to connections the client has already given up on. The user sees "Safari can't open the page because it couldn't connect to the server." Manual reload 8 seconds later (21:17:29 UTC): single QUIC connection, full handshake, no 0-RTT, page loads immediately. The same capture contains three earlier resumption episodes with the identical pattern. Control capture after disabling 0-RTT Connection Resumption on the zone: same device, same site — zero 0-RTT packets, all resumptions clean Initial → Handshake → 1-RTT, no failures. The same device continued to use 0-RTT successfully against other origins that accept early data during the same capture, which is consistent with the problem being in the rejected-early-data path rather than in 0-RTT as such. One data point that may explain the "only some users, only some pages" pattern. Cloudflare support told us they reject early data when a request cannot be safely replayed — non-idempotent methods, authenticated sessions, or cache-bypassing conditions. That matches our observations exactly: the affected users were all logged in (so their navigations bypass cache and hit the origin), anonymous readers receiving cached pages essentially never saw it, and a static page (terms and conditions) did not reproduce it either. It also explains why Private Browsing never failed — no persisted tickets, no resumption. If your affected host serves authenticated traffic, that may be the common factor. On your question 3: from an operator's perspective, either recovery path would be acceptable — replaying the navigation in 1-RTT after early data is rejected, or falling through to the TCP/TLS connection that already succeeded. What is hard to defend is surfacing a connectivity error page to the user while the server is responding normally, since it is indistinguishable from an outage and sends both users and site operators chasing the wrong layer. We spent months suspecting our origin, our CDN and our service worker before the packet capture pointed at the client. Filed as [FB23773289], with both sanitized captures attached (failure with 0-RTT and control without). Referencing FB23764937 as the same issue. Happy to run further tests — we still have devices that reproduced this reliably and the capture tooling set up, although like you we have disabled 0-RTT in production and will not re-enable it there. Thank you @DTS Engineer for the feedback as well. Glad to see we were not the only ones with this issue.