Has anyone else observed intermittent first-navigation failures in Safari on iOS 26 when HTTP/3 0-RTT resumption is available?
Environment:
- iPhone 16 Pro, iOS 26.5.2 (23F84), Mobile Safari
- Wi-Fi with native IPv6
- Cloudflare-proxied HTTPS hostname
- Normal browsing, not Private Browsing
- Reproduced almost daily on the first visit; an immediate reload succeeds
Safari shows its native “cannot open the page because the server cannot be reached” page. The origin is healthy and neither the origin nor Cloudflare HTTP/security analytics records a corresponding HTTP failure.
We captured the iPhone network interface over USB and compared a failed navigation with the successful reload.
Failed navigation:
- DNS A, AAAA and HTTPS/SVCB answers completed normally.
- The HTTPS record advertised h3 and h2 with IPv4 and IPv6 hints.
- MobileSafari/WebKit opened several QUIC connections across the available IPv4 and IPv6 endpoints.
- Nearly all sent QUIC Initial packets plus 0-RTT application data.
- The edge replied promptly with Initial, Handshake and protected packets on both address families.
- Several flows did not settle and the edge retransmitted repeatedly.
- Safari also established a TCP/TLS fallback and received data, but still declared the navigation failed.
Successful reload:
- One IPv4 QUIC connection.
- Full handshake, without 0-RTT.
- Normal bidirectional protected traffic and the page loaded.
Control tests:
- Another proxied hostname succeeded with a full HTTP/3 handshake and no 0-RTT.
- A direct, non-proxied hostname succeeded over IPv6/TLS.
- HTTP/3 requests from the same Safari version otherwise received normal 200/204/302/304 responses.
This looks like a CFNetwork/Network.framework/libquic session-resumption or connection-racing recovery issue rather than a WebKit rendering or origin-server problem. The encrypted capture does not let us determine whether the early data was accepted or rejected by the edge.
Feedback filed: FB23764937.
Important reproduction note: 0-RTT has now been disabled on the affected production zone while HTTP/3 remains enabled. Therefore that hostname can no longer reproduce the original 0-RTT path. This is an intentional mitigation; it will not be re-enabled on production solely for testing.
Questions:
- Has anyone seen the same first-load failure followed by a successful reload on iOS 26?
- Is there a recommended way to collect CFNetwork/libquic diagnostics for a failure that occurs before an HTTP response exists?
- Should Safari replay the navigation after 0-RTT rejection or use the already-successful TCP/TLS fallback in this situation?
A raw packet capture is available to Apple through the private Feedback report on request, but is not posted publicly because it contains client network identifiers.Has anyone else observed intermittent first-navigation failures in Safari on iOS 26 when HTTP/3 0-RTT resumption is available?
Environment:
- iPhone 16 Pro, iOS 26.5.2 (23F84), Mobile Safari
- Wi-Fi with native IPv6
- Cloudflare-proxied HTTPS hostname
- Normal browsing, not Private Browsing
- Reproduced almost daily on the first visit; an immediate reload succeeds
Safari shows its native “cannot open the page because the server cannot be reached” page. The origin is healthy and neither the origin nor Cloudflare HTTP/security analytics records a corresponding HTTP failure.
We captured the iPhone network interface over USB and compared a failed navigation with the successful reload.
Failed navigation:
- DNS A, AAAA and HTTPS/SVCB answers completed normally.
- The HTTPS record advertised h3 and h2 with IPv4 and IPv6 hints.
- MobileSafari/WebKit opened several QUIC connections across the available IPv4 and IPv6 endpoints.
- Nearly all sent QUIC Initial packets plus 0-RTT application data.
- The edge replied promptly with Initial, Handshake and protected packets on both address families.
- Several flows did not settle and the edge retransmitted repeatedly.
- Safari also established a TCP/TLS fallback and received data, but still declared the navigation failed.
Successful reload:
- One IPv4 QUIC connection.
- Full handshake, without 0-RTT.
- Normal bidirectional protected traffic and the page loaded.
Control tests:
- Another proxied hostname succeeded with a full HTTP/3 handshake and no 0-RTT.
- A direct, non-proxied hostname succeeded over IPv6/TLS.
- HTTP/3 requests from the same Safari version otherwise received normal 200/204/302/304 responses.
This looks like a CFNetwork/Network.framework/libquic session-resumption or connection-racing recovery issue rather than a WebKit rendering or origin-server problem. The encrypted capture does not let us determine whether the early data was accepted or rejected by the edge.
Feedback filed: FB23764937.
Important reproduction note: 0-RTT has now been disabled on the affected production zone while HTTP/3 remains enabled. Therefore that hostname can no longer reproduce the original 0-RTT path. This is an intentional mitigation; it will not be re-enabled on production solely for testing.
Questions:
- Has anyone seen the same first-load failure followed by a successful reload on iOS 26?
- Is there a recommended way to collect CFNetwork/libquic diagnostics for a failure that occurs before an HTTP response exists?
- Should Safari replay the navigation after 0-RTT rejection or use the already-successful TCP/TLS fallback in this situation?
A raw packet capture is available to Apple through the private Feedback report on request, but is not posted publicly because it contains client network identifiers.
