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

Socket.IO v4 client reconnection timing after WebSocket handshake failure

Goal: understand whether the client should automatically switch to long‑polling when a WebSocket handshake is blocked by a restrictive proxy, and how this decision influences the reconnection schedule.

Constraint: Socket.IO v4 delegates transport selection to Engine.IO, which does not expose an explicit fallback‑to‑long‑polling flag; consequently, reconnection attempts may vary between environments where proxies allow WebSocket and those that force long‑polling, leading to unpredictable latency.

Questions:

• Does Socket.IO v4 offer a client‑side option to force long‑polling fallback after a WebSocket handshake failure?
• How can developers anticipate or constrain the reconnection interval when Engine.IO autonomously picks a transport based on proxy behavior?
• What are the operational impacts of relying on Engine.IO’s automatic transport selection for applications deployed behind corporate proxies?