Resolved in iOS 26.6 For anyone following this issue, the user-visible failure has been corrected in iOS 26.6. We reproduced the rejected 0-RTT path again on the same physical iPhone after upgrading it from iOS 26.5.2 to iOS 26.6. The QUIC/TLS logs still showed a cached ticket being offered, early data being sent, and early_data_accepted(0). The important difference was the client recovery: On iOS 26.5.2, the rejected early-data path ended with NSURLErrorDomain -1004 / NSPOSIXErrorDomain 61 and Safari displayed its “server cannot be reached” page. A manual reload was required. On iOS 26.6, Safari automatically abandoned the rejected path and retried with a fresh full HTTP/3 handshake within approximately 1.4–2.8 seconds. The retry returned HTTP 200 and no error page was shown. Cloudflare’s engineering review confirmed that rejecting 0-RTT does not itself constitute a connection failure: the client is expected to continue with a normal handshake. The behavioural difference was therefore in the iOS client’s recovery after rejection. A separate steady-state test with 0-RTT continuously enabled also completed normally. Immediate ticket reuse was accepted, while after approximately 26 hours Safari no longer offered a ticket and simply performed a successful full HTTP/3 handshake. The original end-user issue reported here can therefore be considered fixed in iOS 26.6. The remaining discussion with Cloudflare concerns only the precise lifetime and rejection policy for early data; it no longer produces the Safari failure on the corrected iOS version.

Definitive client-side QUIC logs captured We reproduced the failure again on 2026-07-15, this time with Apple Network/CFNetwork logging enabled and a full iPhone sysdiagnose collected immediately afterwards. Failed navigation (12:51:18.718–12:51:19.504 UTC): Mobile Safari requested https://famille.apgl.fr/ and then /login. com.apple.WebKit.Networking attempted multiple Cloudflare IPv4 and IPv6 endpoints. BoringSSL reported resumed(1), offered_ticket(1), in_early_data(1), early_data_accepted(0), ALPN h3. The QUIC trace contains Initial packets followed by 0-RTT application data. WebKit repeatedly logged “Connection refused” in quic_conn_state_initial_sent / quic_conn_state_handshake, “Early data: yes”, and TLS security error 61. The cellular fallback path was requested but WebKit logged “no path found for pdp_ip0”. The navigation ended with NSURLErrorDomain -1004 / NSPOSIXErrorDomain 61: “server cannot be reached”. Successful reload (12:52:26.122 UTC): A fresh QUIC connection was established in 39.978 ms. BoringSSL reported resumed(0), offered_ticket(0), in_early_data(0), ALPN h3. The main HTTP/3 request returned 200 and the page loaded successfully. The successful request reached Cloudflare CDG. An important additional finding is that Cloudflare 0-RTT had already been disabled almost three hours before this reproduction. Safari still used a previously cached session ticket and sent 0-RTT, which the edge did not accept. The immediate reload no longer offered a ticket and succeeded. Therefore disabling 0-RTT does not immediately protect clients that still hold previously issued tickets; it may only become fully effective after those tickets are discarded or expire. This directly matches Cloudflare’s description of a known Safari/WebKit QUIC session-resumption / connection-racing behavior. Private Feedback FB23764937 now contains the exact timestamps, edge endpoints, QUIC states and error codes. The complete sysdiagnose will be attached privately and will not be posted publicly.Definitive client-side QUIC logs captured We reproduced the failure again on 2026-07-15, this time with Apple Network/CFNetwork logging enabled and a full iPhone sysdiagnose collected immediately afterwards. Failed navigation (12:51:18.718–12:51:19.504 UTC): Mobile Safari requested https://famille.apgl.fr/ and then /login. com.apple.WebKit.Networking attempted multiple Cloudflare IPv4 and IPv6 endpoints. BoringSSL reported resumed(1), offered_ticket(1), in_early_data(1), early_data_accepted(0), ALPN h3. The QUIC trace contains Initial packets followed by 0-RTT application data. WebKit repeatedly logged “Connection refused” in quic_conn_state_initial_sent / quic_conn_state_handshake, “Early data: yes”, and TLS security error 61. The cellular fallback path was requested but WebKit logged “no path found for pdp_ip0”. The navigation ended with NSURLErrorDomain -1004 / NSPOSIXErrorDomain 61: “server cannot be reached”. Successful reload (12:52:26.122 UTC): A fresh QUIC connection was established in 39.978 ms. BoringSSL reported resumed(0), offered_ticket(0), in_early_data(0), ALPN h3. The main HTTP/3 request returned 200 and the page loaded successfully. The successful request reached Cloudflare CDG. An important additional finding is that Cloudflare 0-RTT had already been disabled almost three hours before this reproduction. Safari still used a previously cached session ticket and sent 0-RTT, which the edge did not accept. The immediate reload no longer offered a ticket and succeeded. Therefore disabling 0-RTT does not immediately protect clients that still hold previously issued tickets; it may only become fully effective after those tickets are discarded or expire. This directly matches Cloudflare’s description of a known Safari/WebKit QUIC session-resumption / connection-racing behavior. Private Feedback FB23764937 now contains the exact timestamps, edge endpoints, QUIC states and error codes. The complete sysdiagnose will be attached privately and will not be posted publicly.

Update after Cloudflare investigation Cloudflare inspected the edge around the exact UTC timestamp. They confirmed that the failed navigation produced no HTTP request or CF-Ray because it ended during the QUIC handshake/early-data phase. Their edge was responding normally on IPv4 and IPv6. Cloudflare says this matches a known client-side Safari/iOS QUIC session-resumption and connection-racing pattern seen in other cases: a cold navigation attempts 0-RTT, raced QUIC and TCP paths do not converge, then an immediate reload succeeds with a full handshake and no 0-RTT. They do not consider this an edge rejection. Their recommended mitigation is our current configuration: HTTP/3 enabled, 0-RTT disabled. The production hostname therefore cannot reproduce the original 0-RTT path anymore. For a definitive future trace they would need a stable client IP, exact UTC timestamp, PCAP with edge IPv4/IPv6 and colo, plus Safari com.apple.network:quic os_log. We have the client IP, timestamp, PCAP and edge addresses. Paris (CDG) is inferred from surrounding successful traffic; the failed handshake itself has no CF-Ray, so its colo cannot be proven from an HTTP log. We do not have the Apple QUIC os_log from the original failure. If the symptom recurs with 0-RTT disabled, we will capture both a new PCAP and Apple QUIC logs. Private Apple Feedback FB23764937 has been updated with the full findings.Update after Cloudflare investigation Cloudflare inspected the edge around the exact UTC timestamp. They confirmed that the failed navigation produced no HTTP request or CF-Ray because it ended during the QUIC handshake/early-data phase. Their edge was responding normally on IPv4 and IPv6. Cloudflare says this matches a known client-side Safari/iOS QUIC session-resumption and connection-racing pattern seen in other cases: a cold navigation attempts 0-RTT, raced QUIC and TCP paths do not converge, then an immediate reload succeeds with a full handshake and no 0-RTT. They do not consider this an edge rejection. Their recommended mitigation is our current configuration: HTTP/3 enabled, 0-RTT disabled. The production hostname therefore cannot reproduce the original 0-RTT path anymore. For a definitive future trace they would need a stable client IP, exact UTC timestamp, PCAP with edge IPv4/IPv6 and colo, plus Safari com.apple.network:quic os_log. We have the client IP, timestamp, PCAP and edge addresses. Paris (CDG) is inferred from surrounding successful traffic; the failed handshake itself has no CF-Ray, so its colo cannot be proven from an HTTP log. We do not have the Apple QUIC os_log from the original failure. If the symptom recurs with 0-RTT disabled, we will capture both a new PCAP and Apple QUIC logs. Private Apple Feedback FB23764937 has been updated with the full findings.