Bug 298616 – REGRESSION (iOS 26): WebSocket instability in Safari browser and in Standalone mode

• Component: Page Loading
• Status: RESOLVED CONFIGURATION CHANGED

[Leif Andreas Rudlang]

Created attachment 476685 [details]
Inspection of the same call failing and succeeding in safari and chrome

We’re seeing somewhat consistent WebSocket failures in Safari on iOS: connections return HTTP 400, and the requests never reach our servers (no server logs are triggered). 

The same endpoints work on the same devices in other browsers, and they also work in older versions of iOS Safari. 
This occurs across multiple web applications that use SignalR in websocket mode, which suggests a Safari-specific regression in the WebSocket handshake.

The websocket handshake works as normal in IOS 26 Chrome, Brave and Firefox, but fails in Safari and in standalone mode.

I have attached a screenshot from the handshake working in iOS chrome and one failing on iOS safari running on the same device. (Safari to the left, Chrome to the right, same device running 26 RC1)
The handshake intermittently works in Safari, but not frequent enough to be able to reproduce. Toggling certain tracking settings on and off seems to make it work for a few minutes before it starts failing again.

For us, this is quite urgent, I am at your full disposal. I can provide login details to the impacted applications if you need to reproduce, but they can't be posted publicly.

Kind regards,
Leif

[Leif Andreas Rudlang]

Update: Located a similar case.

https://learn.microsoft.com/en-us/answers/questions/5523188/safari-on-ios-26-(developer-beta-6-public-beta)-di

[Radar WebKit Bug Importer]

<rdar://problem/160238014>

[Zhenchao Li]

Hi, I can probably take a look. Will reach out for credentials off of this forum.

[M]

We encountered the same bug:

- started after update to iOS 26 yesterday
- WebSocket fails with code 400
- happens on all our test devices
- fails also on Mac
- fails on Safari, works on Chrome 
- it seems that Safari randomly tries to force WS over HTTP/3 - WireShark shows that UDP is used instead of TCP

Can we provide you some additional data?

Thanks,
Mateusz

(In reply to Leif Andreas Rudlang from comment #1)
> Update: Located a similar case.
> 
> https://learn.microsoft.com/en-us/answers/questions/5523188/safari-on-ios-26-
> (developer-beta-6-public-beta)-di

Hi
We are hitting the same issue. 
Safari 26 on Tahoa and on iOS fails to connect.

[Leif Andreas Rudlang]

To everyone currently struggling with this, disabling HTTP/3 (QUIC) negotiation (credit to Zhenchao Li) temporarily resolves the issue.

[Jesper Bendtsen]

We are also having problems with the new update "iOS26". Our PWA use wss:// which is not working after the new update. We have tested it on both iOS 26 and iPadOS 26, Safari browser and in standalone mode (Added to home screen) and it is the same, not working.

We also ran into the same problem today. Thanks a lot for the tip about disabling HTTP/3 (QUIC) negotiation - after updating the GCP load balancer configuration, the issue was resolved on our side.

It turned out to be quite tricky to reproduce, but in case you’re curious, here’s the most reliable way we found:

* Open a website that establishes a WebSocket connection
* Send a few messages over the connection
* Close Safari
* Reopen the same website → you'll see that the WebSocket connection can no longer be established

We are also having this issue. This is quite urgent for us.

[Zhenchao Li]

(In reply to derrick from comment #9)
> We are also having this issue. This is quite urgent for us.

If turning off QUIC negotiation is an option for your backend infrastructure, you could try if this resolves the issue for you.
More specifically, turning off "SETTINGS_ENABLE_CONNECT_PROTOCOL" option in your QUIC settings should resolve the issue.
There should be a similar settings if your infrastructure is using HTTP/2

Out of curiosity, are you using Google Cloud load balancer?

Yes, we were able to turn of QUIC in our load balancer and this seems to solve the problem for new clients connecting to our service. Clients which have previously connected seem to continue to use the QUIC connection and fail unfortunately. 
Yes, we're using the Google Cloud Load Balancer.

We are also experiencing this issue. Our infrastructure is deployed in GCP, and we have also used disabling QUIC as a temporary workaround.

We would like to re-enable QUIC as soon as a permanent solution is available. Is there a long-term fix planned for this?

(In reply to Zhenchao Li from comment #10)
> (In reply to derrick from comment #9)
> > We are also having this issue. This is quite urgent for us.
> 
> If turning off QUIC negotiation is an option for your backend
> infrastructure, you could try if this resolves the issue for you.
> More specifically, turning off "SETTINGS_ENABLE_CONNECT_PROTOCOL" option in
> your QUIC settings should resolve the issue.
> There should be a similar settings if your infrastructure is using HTTP/2
> 
> Out of curiosity, are you using Google Cloud load balancer?

Are there any update on the long term solution?

[Jesper Bendtsen]

Thank you very much, it works again in iOS 26.1 :)

[Alexey Proskuryakov]

Thank you for the follow up! Indeed, the underlying framework issue got fixed in 26.1. Please file new bugs if you observe similar issues, as those will need to be investigated separately.