Safari iOS 26.5.2: first navigation fails during HTTP/3 0-RTT; reload succeeds (FB23764937)

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.

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.

Thanks for your post, I see you filed a complete bug for your description and got routed to a team to review.

Please give time to engineering to review all that information.

You can see the status of your feedback in Feedback Assistant. There, you can track if the report is still being investigated, has a potential identifiable fix, or has been resolved in another way. The status appears beside the label "Resolution." We're unable to share any updates on specific reports on the forums.

For more details on when you'll see updates to your report, please see What to expect after submission.

Albert  WWDR

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.

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.