Something broken with establishing websocket connection with Browser as a service provider

We have been using Zenrows with puppeteer running in Durable Objects for quite some time now. But as of 2/6 (and we momentarily saw this issue last week too), we get this error on trying to connect to their wss endpoint on a brand new invocation.

We are using the cloudflare/puppeteer package. The error is:

Uncaught TypeError: Failed to establish the WebSocket connection: expected server to reply with HTTP status code 101 (switching protocols), but received 520 instead."

Uncaught TypeError: Failed to establish the WebSocket connection: expected server to reply with HTTP status code 101 (switching protocols), but received 520 instead."

Uncaught TypeError: Failed to establish the WebSocket connection: expected server to reply with HTTP status code 101 (switching protocols), but received 520 instead."

Uncaught TypeError: Failed to establish the WebSocket connection: expected server to reply with HTTP status code 101 (switching protocols), but received 520 instead."

Does anyone know what's going on? This is happening with no code change from our side. Last week, I thought it was because the Zenrows API key variable might have gotten corrupt in our worker/DO deployment, so I manually updated it and the issue resolved itself.

Today, the issue is not resolving on rotating the Zenrows API key (to the same value really) - so I am not sure what's up.

sup filistineOP•2/6/25, 6:10 PM

I know there is a simultaneous outbound connection limit of 6 in CF, I have never run into this before though.

The only other outbound connections we have apart from the wss (Zenrows) is some http connections for uploading our logs to betterstack.

sup filistineOP•2/6/25, 6:12 PM

Oh, I just noticed that the issue resolves momentarily post the deployment, but returns on subsequent requests - so perhaps I am running into some rate limit.

sup filistineOP•2/6/25, 7:17 PM

The issue doesn't happen when using cloudflare's own browser rendering. That's weird because on the face of it, that also uses websockets.

sup filistineOP•2/7/25, 3:30 AM

What the most heady-scratchy thing about this is that the issue stops happening randomly based on a little code changes that are supposedly noops, so that makes me think this resets some counter nearer to deployments.

Something broken with establishing websocket connection with Browser as a service provider

Similar Threads

Similar Threads

Similar Threads