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.