Troubleshooting connection issues

    Possible explanations:

    You are trying to reach a plain WebSocket server

    As explained in the “What Socket.IO is not” section, the Socket.IO client is not a WebSocket implementation and thus will not be able to establish a connection with a WebSocket server, even with :

    The server is not reachable

    Please make sure the Socket.IO server is actually reachable at the given URL. You can test it with:

    1. curl "<the server URL>/socket.io/?EIO=4&transport=polling"

    which should return something like this:

    1. 0{"sid":"Lbo5JLzTotvW3g2LAAAA","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":20000}

    If that’s not the case, please check that the Socket.IO server is running, and that there is nothing in between that prevents the connection.

    The client is not compatible with the version of the server

    Here is the compatibility table for the :

    [1] Yes, with [allowEIO3: true]($73f5a1bff1f580e3.md#allowEIO3)

    Here is the compatibility table for the Java client:

    [1] Yes, with [allowEIO3: true]($73f5a1bff1f580e3.md#allowEIO3)

    Here is the compatibility table for the :

    [1] Yes, with [allowEIO3: true]($73f5a1bff1f580e3.md#allowEIO3) (server) and (client):

    [3] Yes, with .version(.two) (client):

    1. SocketManager(socketURL: URL(string:"http://localhost:8087/")!, config: [.version(.two)])

    The server does not send the necessary CORS headers

    If you see the following error in your console:

    1. Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at ...

    It probably means that:

    Please see the documentation .

    You didn’t enable sticky sessions (in a multi server setup)

    When scaling to multiple Socket.IO servers, you need to make sure that all the requests of a given Socket.IO session reach the same Socket.IO server. The explanation can be found .

    Failure to do so will result in HTTP 400 responses with the code: {"code":1,"message":"Session ID unknown"}

    Please see the documentation here.

    First and foremost, please note that disconnections are common and expected, even on a stable Internet connection:

    • the server itself may be killed as part of an autoscaling policy
    • the user may lose connection or switch from WiFi to 4G, in case of a mobile browser
    • the browser itself may freeze an inactive tab
    • …

    That being said, the Socket.IO client will always try to reconnect, unless specifically told .

    Possible explanations for a disconnection:

    The client is not compatible with the version of the server

    Since the format of the packets sent over the WebSocket transport is similar in v2 and v3/v4, you might be able to connect with an incompatible client (see ), but the connection will eventually be closed after a given delay.

    You are trying to send a huge payload

    If you get disconnected while sending a huge payload, this may mean that you have reached the value, which defaults to 1 MB. Please adjust it according to your needs:

    A huge payload taking more time to upload than the value of the pingTimeout option can also trigger a disconnection (since the fails during the upload). Please adjust it according to your needs:

    1. const io = require("socket.io")(httpServer, {
        pingTimeout: 60000
      });

    In most cases, you should see something like this:

    1. the Engine.IO handshake (contains the session ID — here, zBjrh...AAAK — that is used in subsequent requests)
    2. the Socket.IO handshake request (contains the value of the auth option)
    3. the Socket.IO handshake response (contains the Socket#id)
    4. the WebSocket connection
    5. the first HTTP long-polling request, which is closed once the WebSocket connection is established

    If you don’t see a response for the 4th request, that means that something between the server and your browser is preventing the WebSocket connection.

    Please note that this is not necessarily blocking since the connection is still established with HTTP long-polling, but it is less efficient.

    You can get the name of the current transport with:

    Client-side

      Server-side

      Possible explanations:

      A proxy in front of your servers does not accept the WebSocket connection

      Please see the documentation here.