WebSocket — close code 1001 going away disconnects clients

Diagnose WebSocket 1001 closures by identifying scheduled restarts, idle proxies and deployment churn.

intermediatedebuggingwebsocketnetworking

Symptoms

WebSocket closes with code 1001 (going away)
Reconnections happen on a regular schedule
Disconnects coincide with restarts or deploy events
A load balancer closes idle connections

Possible causes

A server restart or deployment closes connections deliberately
A proxy or load balancer times out idle connections
The server shuts down for maintenance with a going-away close
Scaling down terminates connections on removed instances

Diagnosis steps

Correlate closures with events

journalctl --since "10 min ago" | grep -i "shutdown\|restart"

Interpretation

Matching close times to restart or deploy logs identifies whether the cause is planned churn or an idle timeout.

Check proxy idle timeouts

nginx -T 2>/dev/null | grep -i "proxy_read_timeout\|proxy_send_timeout"

Interpretation

A short proxy read timeout closes idle websockets even when the server is healthy.

Add keepalive pings

client ping interval < proxy idle timeout

Interpretation

Pinging below the proxy idle timeout keeps connections alive through intermediaries.

Root cause

The connection was closed with a going-away code because the server, proxy or orchestrator deliberately ended it, either for a restart or because it was idle past a timeout.

Fix

Add keepalive pings shorter than the smallest idle timeout, raise proxy timeouts where appropriate, and implement client reconnection with backoff and graceful server draining so deploys cause only brief interruptions.

Verify the fix

Observe connections through a deploy or idle period and confirm they either persist or reconnect quickly with no data loss.

Symptom walkthrough

WebSocket clients disconnect with close code 1001, going away, often on a regular cadence or around deployments. This code means an endpoint deliberately closed the connection, which points at a server restart, a drain during a deploy, or a proxy that closed an idle connection after a timeout. Unlike abnormal closures, 1001 usually has an intentional cause waiting to be found in logs or configuration.

Fix in practice

Correlate close times with restart and deploy logs, and check proxy read and send timeouts. Send keepalive pings shorter than the smallest idle timeout so intermediaries do not reap the connection, and implement client reconnection with backoff. Graceful server draining lets deploys close connections in an orderly way.

Verification

Observe connections across a deploy and an idle period and confirm they either remain open or reconnect promptly without losing messages. Stable or promptly restored sessions confirm the fix.

Diagnostic commands

Check the behavior with commands like these:

journalctl --since "10 min ago" | grep -i "shutdown\|restart"
nginx -T 2>/dev/null | grep -i "proxy_read_timeout\|proxy_send_timeout"
client ping interval < proxy idle timeout