Socket.IO v4 client reconnection timing inconsistency after WebSocket handshake failure

Answer

Socket.IO v4 does not expose a client‑side flag to force long‑polling only after a WebSocket handshake failure; the fallback is handled automatically by Engine.IO.

Confirmed facts

• Transport selection is performed by Engine.IO; you can pre‑define the allowed transports with the transports option (e.g., { transports: ['polling'] }).
• When transports is omitted or includes both ['websocket','polling'], Engine.IO tries WebSocket first and falls back to polling only if the WebSocket upgrade fails.
• Reconnection timing is controlled by Engine.IO’s reconnection options: reconnectionAttempts, reconnectionDelay, reconnectionDelayMax, and randomizationFactor.

Likely explanation

If a corporate proxy blocks the Upgrade: websocket header, the initial WebSocket handshake fails, Engine.IO detects the error and switches to the next transport in the allowed list (usually polling). Because this switch happens per‑connection attempt, the observed reconnection interval can vary between environments where the proxy allows WebSocket (fast reconnect) and those that force polling (extra HTTP round‑trips and longer delay).

Steps to obtain predictable reconnection behavior

1. Decide which transport you want to guarantee (usually polling for proxy‑friendly behavior) and set it upfront:

   const socket = io(serverUrl, {
     transports: ['polling'],          // force polling only
     reconnectionAttempts: 5,
     reconnectionDelay: 1000,
     reconnectionDelayMax: 5000,
     randomizationFactor: 0.5
   });
   

2. If you prefer to keep WebSocket when possible but bound the fallback delay, keep both transports and tighten the reconnection parameters:

   const socket = io(serverUrl, {
     transports: ['websocket','polling'],
     reconnectionAttempts: 10,
     reconnectionDelay: 2000,
     reconnectionDelayMax: 10000,
     randomizationFactor: 0
   });
   

3. Monitor the actual transport after each handshake to verify behavior:

   socket.io.engine.on('upgrade', (transport) => {
     console.log('Transport upgraded to', transport.name);
   });
   socket.io.engine.on('error', (err) => {
     console.error('Transport error', err);
   });
   

Missing diagnostic detail

Can you confirm whether the proxy in your environment blocks the Upgrade header for WebSocket? Knowing this will tell us if the observed delay is due to forced polling or another issue.