Safari/iOS 26 WebSocket Problems???

# Bug Report: Safari/iOS 26 – WebSocket Upgrade Fails with Open-WebUI


## Summary

Since upgrading to iOS 26, Safari consistently fails to connect to Open-WebUI

through a Caddy reverse proxy. The error displayed in Safari is:


> "The String did not match the expected pattern"


Other browsers (Firefox ESR on Linux, Windows, macOS, and Firefox on iOS) do not

exhibit this issue. This strongly suggests a Safari/WebKit regression.


---


## Environment

- **Server OS**: Debian (latest stable)

- **Reverse Proxy**: Caddy (from Debian repository)

- **Backend**: Open-WebUI (running via Uvicorn)

- **TLS/ALPN**: `h3 h2` (HTTP/3 and HTTP/2 enabled, HTTP/1.1 disabled for HTTPS)

- **Safari**: iOS 26 (problematic)

- **Other Browsers**: Firefox ESR (Linux/macOS/Windows) → works fine

Firefox on iOS → works fine so far


---


## Expected Behavior

Safari should correctly upgrade the connection to WebSocket when connecting

to Open-WebUI (via `/ws/socket.io/...`).


---


## Actual Behavior

Safari/iOS 26 attempts a WebSocket upgrade, but the server rejects it with

`400 Bad Request`. Safari then shows the error

*"The String did not match the expected pattern"*.


---


## Snippets from journalctl (possibly related)

The following entries appear whenever Safari/iOS 26 attempts a connection:


```

Sep 20 22:13:58 coyote open-webui[3959566]: Unsupported upgrade request.

Sep 20 22:13:52 coyote open-webui[3959566]: 2025-09-20 22:13:52.816 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 2003:xyz… - "CONNECT /ws/socket.io/?EIO=4&transport=websocket HTTP/1.1" 400

```


This indicates:

- Safari sends an **HTTP/1.1 CONNECT request** to upgrade to WebSocket.

- Open-WebUI/Uvicorn rejects it with `400 Unsupported upgrade request`.

- Other clients successfully perform the WebSocket handshake through the same

Caddy reverse proxy configuration.


---


## Notes

- The issue **only occurs with Safari/iOS 26**.

- Clearing Safari cache/data does **not** resolve the issue.

- Restarting the server or reverse proxy has **no effect**.

- Firefox on the same iOS device does not exhibit the problem, suggesting

a Safari/WebKit-specific bug.


---


## Conclusion

There appears to be a regression in Safari/iOS 26 where the WebSocket upgrade

request is malformed or incompatible with standard server implementations

(Open-WebUI/Uvicorn). This leads to connection failures not reproducible

with other browsers or clients.




[Edited by Moderator]

iPhone 16, iOS 26

Posted on Sep 20, 2025 1:30 PM

Reply
Question marked as Top-ranking reply

Posted on Sep 25, 2025 4:26 AM

Having similar problems with google cloud, but on MacOS / safari 26. Also submitted a bug report to apple.


GCP load balancer reports an invalid_http2_client_header format. Funnily enough, safari 26.0.1 seems to work fine on Sequoia.


As a workaround we are now running HAProxy that only accepts HTTP 1.1 and proxies to the main server. Less than optimal, but it works for now. Hoping to see this fixed soon.

6 replies
Question marked as Top-ranking reply

Sep 25, 2025 4:26 AM in response to Sebastian Elsner

Having similar problems with google cloud, but on MacOS / safari 26. Also submitted a bug report to apple.


GCP load balancer reports an invalid_http2_client_header format. Funnily enough, safari 26.0.1 seems to work fine on Sequoia.


As a workaround we are now running HAProxy that only accepts HTTP 1.1 and proxies to the main server. Less than optimal, but it works for now. Hoping to see this fixed soon.

Sep 22, 2025 5:36 AM in response to Sebastian Elsner

We have this issue as well. It seems Safari 26 on iOS seems to be sending websocket upgrade requests over HTTP2 but also adds the HTTP1.1 style headers. This is not according to HTTP2 spec and thus certain pieces of software (such as a GCP external load balancer) reject these requests as invalid. An example request from the iphone 15 plus ios 26 simulator:


Request

Cache-Control: no-cache

Origin: HIDDEN BY ME

Pragma: no-cache

Sec-Fetch-Dest: websocket

Sec-Fetch-Mode: websocket

Sec-Fetch-Site: cross-site

Sec-WebSocket-Extensions: permessage-deflate

Sec-WebSocket-Key: xxxxxxxxxxx

Sec-WebSocket-Version: 13

User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Mobile/15E148 Safari/604.1


If you look at RGC 8441 this does not seem compliant.

Sep 22, 2025 12:18 PM in response to mjvk

Hello mjvk,


Thanks for confirming this.




I’m running Caddy as a reverse proxy in front of Open-WebUI, with only HTTP/2 and HTTP/3 enabled (HTTP/1.1 explicitly disabled).




Because of that, Safari 26’s request with HTTP/1.1-style upgrade headers over HTTP/2 fails right away with:


400 Unsupported upgrade request


Good to know this isn’t a local misconfiguration.

Sep 20, 2025 10:31 PM in response to Sebastian Elsner

Hello John,




I wasn’t even aware of Apple’s Feedback Assistant channel at first — it’s probably not easy to find for regular users.


I discovered it later and have now filed a detailed bug report there as well.


I’ll keep this thread open for visibility, so other users who might run into the same issue can find it and share their experiences.

Sep 25, 2025 3:42 PM in response to Sebastian Elsner

We're encountering the same issue. Our SaaS frontend web application, which is hosted on Netlify and proxied through Cloudflare, is failing to function correctly. The app displays a "WebSocket connection error". Notably, this problem appears to affect only this specific iOS 26 version - while iOS 18.6 and all other operating systems work without any issues.


Edit: just found out about the bug report channel, sorry for posting here,

Safari/iOS 26 WebSocket Problems???

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.