Binance WebSocket frequent disconnections are often not network problems. Instead, your client is likely not handling the heartbeat (Ping/Pong) mechanism and the messages per second (message frequency) limit correctly. Both are mandatory requirements. If your configuration is wrong, the server will actively disconnect you.
Step 1: Verify Heartbeat Mechanism Compliance
Check if your client correctly responds to the server's Ping frames. The Binance WebSocket server periodically sends Ping frames to check if the connection is alive. Your client must reply with a Pong frame within the required time; otherwise the connection will be dropped.
Spot market: Server sends a Ping frame every 20 seconds; you must reply with a Pong frame within 1 minute.
USDⓈ-M Futures: Server sends a Ping frame every 3 minutes; you must reply with a Pong frame within 10 minutes.
Options market: Server sends a Ping frame every 5 minutes; you must reply with a Pong frame within 15 minutes.
If you only implemented passive Ping responses, certain features (such as the WebSocket API) also recommend that the client actively send a PING message every 30 seconds. This prevents the connection from being unexpectedly dropped because the server thinks it is idle.
Risk reminder: When sending a Pong frame, you must include the exact same payload as the received Ping frame; otherwise the server may reject it. Unsolicited pong frames are allowed, but the official documentation does not recommend relying on that method to keep the connection alive.
Step 2: Check for Message Rate Limit Breaches
Confirm whether your client is sending too many messages per second. The Binance WebSocket server enforces a hard limit on the total number of messages received per second. All message types count toward this limit.
Spot market: Maximum 5 messages per second.
Futures market: Maximum 10 messages per second.
If you exceed this limit, the connection is immediately disconnected. If it happens repeatedly, your IP address may be banned by the server.
Common failure reason: Many people overlook that JSON control messages like "subscribe" and "unsubscribe" also count toward the 5‑per‑second limit. If you send too many instructions at once when subscribing to many data streams, or if you send a burst of Ping/Pong frames, you can easily hit the rate limit and get disconnected.
Step 3: Check if the Connection Has Reached 24 Hours
Check whether the current WebSocket connection has been running for nearly 24 hours. Each WebSocket connection is valid for a maximum of 24 hours. After that time, the server will disconnect it. This is expected behavior, not a fault.
Next steps: Implement the following logic in your client code:
Correct heartbeat response: Listen for Ping frames from the server and immediately reply with a Pong frame that carries the same payload.
Proactive heartbeat sending (for WebSocket API): If you use the API connection, add a timer that sends a PING message every 30 seconds.
Exponential backoff reconnection: Build an auto‑reconnect mechanism that increases the delay after each failure (e.g., 1s, 2s, 4s…). This avoids flooding the server with rapid reconnection attempts and getting your IP banned.
Scheduled 24‑hour reconnect: As soon as a connection is established, set a timer for 23.5 hours. When it fires, gracefully disconnect and open a new connection. This prevents the server from forcefully disconnecting you at the 24‑hour mark.
