Connecting to WebSockets results in 502 Bad Gateway


#1

I’m writing an application that connects to a Node.js WebSocket server (using ws) running on Cloud9. Previously this had been working without fault. However, today I suddenly started getting:

Error during WebSocket handshake: Unexpected response code: 502

when creating a new WebSocket, on the client (running outside Cloud9). I hadn’t changed anything with either the server or the client in between having a successful connection and getting these error responses.

Where might this problem be arising from? Could this be an issue with some change in Cloud9 recently? It seems odd that it arose without any changes on my part.


#2

Hi there, thanks for your message! I have forwarded this to our platform team to see what the issue is.


#3

Hi,

we did not make any changes, which could explain this. Usually a 502 indicates a problem with the reverse proxy. Maybe you hit this while we were in the middle of updating one of our servers. I could not reproduce it with one of my websocket applications. Do you still see this error?

Best,
Fabian


#4

Maybe that’s it — today everything was working again, so the issue is gone (hopefully for good!). Very odd. I’ll tell you if it starts happening again! Thanks!


#5

If anyone else runs across this from a Google search, there is a problem with private workspaces where the websockets request will be presented with the login screen and return a 502. An easy way to fix this:

  • Go to ‘Share’ and make your application public (your code is still private)…

Alternatively one of the support folks gave me this suggestion, although I never tried it:

If you have to initiate this with a GET request, try doing the following to the headers in the call:

- remove Mozilla and AppleWebKit strings from user-agent
- add Headless or PhantomJS to user-agent
- add cookie c9.live.user.click-through = ok
- add origin, postman-token, or x-request-id header to the request

#6

Just to provide a bit more context: this was because it was a private workspace, which requires an active session with a logged-in account that has read access to the workspace. The advice regarding headers is if you’re running into the preview splash page when making a GET request to the service, since general GET requests will trigger the splash page.