Websocket disconnects with 1006 error, without a reason

[Esqarrouth]

• [x] I've searched for any related issues and avoided creating a duplicate issue.

Description

I'm logging disconnects in my web game. It seems 75% of the sessions are getting disconnected with the code 1001 (normal) and 25% are getting disconnected with the code 1006 (error). https://tools.ietf.org/html/rfc6455

Sometimes on the error reason I see this text:

CloudFlare WebSocket Proxy restarting

But he majority of 1006 disconnects don't give any reason at all. The players just disconnect with no reason at all. This usually happens at 5-30 minutes mark while the player is actively playing the game.

The setup I'm has these:

• Node.js
• Express.js
• Cloudflare
• Digital Ocean
• Docker
• https://github.com/websockets/ws
• SSL
• Nginx timeout = 3600s
• Ping/Pong isAlive = 30s

My question is:

1. How can I debug this problem better?
2. What are common cases which might be causing this problem?

Reproducible in:

• version: 3.3.1
• Node.js version(s): v10.11.0
• OS version(s): Docker 18.09.0

Also posted in: https://stackoverflow.com/questions/54909597/websocket-disconnects-with-1006-error-without-a-reason

[lpinca]

1. How can I debug this problem better?

There is not much you can do about it because it's not an issue. It's a condition you have to deal with.

2. What are common cases which might be causing this problem?

A close frame is not received, likely because it was not sent.

[lpinca]

Btw, update at least to https://github.com/websockets/ws/releases/tag/6.1.3. The bug fixed there is relevant and important.

[lpinca]

Nvm, the 3.x release line should not be affected by that but it doesn't harm anyway to update, if you can.

[Esqarrouth]

I'm tracking the disconnections used ws 3.3.1 until 3 March then updated ws to 6.1.4. I am adding the charts.

Conclusion:

• Updating to 6.1.4 did not solve the disconnect problems.
• It hasn't seem to make any changes in terms of general disconnections. (Volume of 1001 could be ignored because it is largely dependent on the traffic that day)
• 1000 errors completely disappeared after updating and 1005 errors started showing up, while previously we didn't have these. (I hope this is the expected behaviour?)

[lpinca]

I hope this is the expected behaviour?

Yes, 1005 is a close frame with an empty payload.

[Esqarrouth]

1. How can I debug this problem better?

There is not much you can do about it because it's not an issue. It's a condition you have to deal with.

1. You mean it is not an issue with ws, right?
2. What do you mean there is not much you can do about it?
3. What do you mean it's a condition you have to deal with? If it is common, how do you or other people generally deal with this issue?

1. What are common cases which might be causing this problem?

A close frame is not received, likely because it was not sent.

5. Do you mean that socket server didn't send the close frame to client?

[lpinca]

1. You mean it is not an issue with ws, right?

Yes, I'm not aware of ws dropping close frames.

2. What do you mean there is not much you can do about it?

It's outside of your control. You can't force the client to send a close frame. If this is coming from a browser try to call ws.close() before the page unload and see if it makes any difference.

3. What do you mean it's a condition you have to deal with? If it is common, how do you or other people generally deal with this issue?

Treat it for what it is. An "abnormal" closure.

5. Do you mean that socket server didn't send the close frame to client?

The client.