Continual “transport close” on client

[ForgeableSum]

I've setup socket.io v.1.4.5 w express and I have been unable to trace the reason for unexplainable disconnects on the clients. The reason given by the disconnect event on the client is "transport close." It happens very consistently on some clients.

Is there any explanation for a client getting "transport close" disconnects on what seems to be a timed interval? The client reconnects just fine but it causes extreme inconvenience because it happens so frequently.

I've tried various settings, like changing the pingInterval, pingTimeout and the port for websockets (I am now using port 80). But no matter what I seem to do, the problem never goes away.

[ForgeableSum]

Updated to socket.io v2.0.3. and still having the problem. It only seems to happen on one of my PCs. I also disabled the windows firewall, but the problem is still happening.

[ForgeableSum]

Switched to ws (https://github.com/websockets/ws) which involved massive rewrites, but i now use the native websocket browser object on the client side and everything works perfectly. I no longer have the problem. So long socket.io!

[matthewtmoran]

Experiencing the same thing. I really don't want to have to go through a rewrite. Any one have any success with this issue?

[althjs]

I was really tired of this problem.
I think you guys should check the version of "socket.io" with "socket.io-client".
if server / client version is mismatch, the connection was very unstable.

I recommend simply using CDN like below for client.

<script src="https://cdnjs.cloudflare.com/ajax/libs/socket.io/2.0.3/socket.io.slim.js"></script>

@ref: https://cdnjs.com/libraries/socket.io

I hope it helps.

[dnwldbs84]

Feudal Wars dev?? It`s great.
I also have this problem too.
The user was disconnected randomly due to transport close and ping timeout.
I also tried changing many options (ping interval, ping timeout, transfer ...) but it does not work.
I checked the version of server and client's socket.io
Many people suffer from this issue, but I can't find any solution.

[talas9]

Any news on this problem, cuz i have the exact same problem!

[muhammadnasr]

I have the same issue as well when I deploy to k8ns but when I run locally it works fine.

[htamop]

I'm also suffering from this...

[darrachequesne]

@talas9 @muhammadnasr @htamop the common questions to be able to debug / reproduce the issue:

• which version of the client / server are you using?
• which browser?
• is it reproducible with the fiddle?

Thanks!

[muhammadnasr]

I have tried it with 2.1.0 and 2.0.4 client and server. On chrome and safari (latest).
When I run locally it works fine (can be connected for over an hour without disconnect), but when I deploy to K8ns behind ingress loadbalancer, this issue happens...

FYI connection is closed exactly after 25 seconds every time, see screen shot

[muhammadnasr]

@talas9 @htamop @dnwldbs84 are you using a load balancer?

[muhammadnasr]

@darrachequesne Which load balancer(s) do you recommend using with socket.io ?

[htamop]

@muhammadnasr @darrachequesne
I used 2.1.0 sever and 1.0.0 client (android)
I need to keep connection stable for 8~9 hour but it unexpectedly disconnect.
I changed both version to 1.7.4 and 0.8.3? according other solution post. I will try test if it works well tomorrow

[dnwldbs84]

I had not used a load balancer. Both the client and server used the 2.0.3 version of Socket.io (I can't remember all version I used). I do not know which browser is causing the problem However, most users have used Chrome. In my case, the disconnect was randomely so it can't reproduce.
And I changed to ws. I am not sure if the problem is solved.

[htamop]

@muhammadnasr @darrachequesne @dnwldbs84
I think it is solved in my case.
I use 0.8.3 socket.io-client in android foreground service(api 26) and 1.3.5 version in nodejs server.
However, the problem might be not version.
I changed pingInterval in server to 10ms and it seems to work properly(ping timeout and transport close not occured)
var io = require('socket.io')(http, {pingInterval: 10, pingTimeout: 4000 });

[muhammadnasr]

10 millseconds is too narrow, this way the network will be overwhelmed.

[darrachequesne]

10 millseconds is to narrow, this way the network will be overwhelmed.

Correct!

@muhammadnasr any load-balancer should work. Please see the following examples:

• https://github.com/socketio/socket.io/tree/master/examples/cluster-haproxy
• https://github.com/socketio/socket.io/tree/master/examples/cluster-nginx
• https://github.com/socketio/socket.io/tree/master/examples/cluster-httpd

Sticky-session is required though, if you enable polling (which is the default).

[DannyFeliz]

@darrachequesne I have the same issue, after like 8~9 hours the socket disconnects with the reason of "transport close"

I'm using:

Chrome: 61.0.3163.100
Electron: 2.0.2
Socket.io: 2.1.1

[borisgern]

Had a same issue, was able to fix it using CDN from this comment #3025 (comment) and setting timeout and interval like below:

io.set('heartbeat timeout', 60000);
io.set('heartbeat interval', 25000);

[odeddoek]

Hey,
We have the same issue with socket.io when it runs under Kubernetes and NGINX Ingress Controller.
When nginx configuration is reloaded, it recreates the process and all the existing communications are dropped, which caused the transport close, any other deployments that uses the ingress controller might cause the configuration reload

[dennisat]

First of all really thanks for this awesome project.

Same issue here, maybe I'll bring your something new.

I have a ws server, and a ws client on node js.
This ws client is used from a node js app where is a service (micro service).

Other ws clients from web browsers (from client apps) are communicating through the ws server with this node js service.

Everything is working as expected.

On stress tests now (10 clients are asking intensively data), at the end of the tests, when all the jobs and transactions have been finished the connection of the service is closed with error "transport close". This is not happening always.

This is the config of the server:
pingTimeout: 15000,
pingInterval: 20000,
It looks like during the heavy load some ping(s) are lost...? or I don't know.
Is this something that I should expect?

Also, with the default config pingTimeout: 2000, I was getting this error in the middle of the stress test. This also was completely unexpected, but let's say that the server was overloaded and couldn't respond within 2secs(!) and we might get this error. But now with pingTimeout: 15000 it happens almost 50% and only after the end of the tests.

Hmho, I believe the micro-services should expected this kind of errors, even if they are running on the same lan, but the question is why is this happening?

I tried to create a small setup to reproduce this problem but I couldn't make it.

How to activate the logs? the DEBUG=socket.io* is not working. Although the variable is set, I don't get any output.

[tilsander]

I strongly believe that this is related to #2924.
The reconnects on a client are caused by some browsers (safari and chrome) throttling timers for inactive tabs to save battery.
This results in delayed heartbeat messages from the client and the server closing the connection due to pingTimeout.
Increasing pingTimeout works to some extent but i still get reconnects in a production environment.

[bheema01]

I have the same issue as well when I deploy to k8ns but when I run locally it works fine.

@muhammadnasr where you able to get past the deploy issue on K8s? I am experiencing similar issues.

[muhammadnasr]

@bheema01 just make sure you have stickysession enabled on your proxy/loadbalancer and it should work

[Faizanq]

Got same error

[varunSabnis]

Same issue .....clients connect and disconnect repeatedly when server side socket endpoint is behind a load balancer. Even after configuring sticky sessions , issue still exists . @muhammadnasr were u able to resolve the issue.

[dennisat]

I have seen this error, when the thread was blocked frequently for more than 200ms.
If this happens frequently this is bad for the socket.io and for your app as well.
The socket.io has a timeout to check the heartbeat of the connection.
If this timeout is exceeded then it shutdowns the connection and we get this error.

[muhammadnasr]

@varunSabnis after fixing sticky session, everything worked smoothly.

[varunSabnis]

@dennisat I tried checking how long it took for my client to receive a pong packet. Every time it was beyond 200ms, which was tested both with socket server in the cloud and socket server on my localhost. The local setup doesn't disconnect the socket(everything works fine) , whereas in the cloud setup socket continually connects and disconnects. So , i don't think that's the issue.
@muhammadnasr okay , that's great. Have actually enabled it but still having some issues.

[CodeBishop]

I encountered the problem of socket.io disconnection every 30 seconds after deploying to Google Cloud Platform (GCP). It turned out to be a default http timeout used by the Global Load Balancer. The GCP documentation said you should change the value when using websockets. Instructions for changing the setting are here:
https://cloud.google.com/load-balancing/docs/backend-service#timeout-setting

[FaizanZahid]

still facing same issue on "socket.io": "2.2.0",
"socket.io-client": "2.2.0",

socket.io-client:socket close (ping timeout) +22s

[alexyoux]

Same here. The local server never gets a problem. But when deploying behind a load balancer, it has ping timeout randomly. Probably 1 in 50 times. I have tried to use the CDN version and adding the sticky session. The problem still exists.

[tmusaev]

Nothing worked for me besides some custom reconnect logic. If the client gets a socket open event with a different id than the previous one, send the server a reconnect event with the old & new id. Then on the server just update the socket id of the player and resend the game state.

[Raagh]

@tmusaev could you post that custom reconnect logic for the client?

[javaLuo]

I have the same issue: 'transport close'

[ikitty]

have the same problem. finally I resolve it. Nginx is my proxy server , but proxy_read_timeout of config is 60s , it indicates that if client or server doesnot emit any message in 60s , nginx will disconnect , so we can got that transport close errorMsg.

the solution:

1. increase the proxy_read_timeout to 600s or more
2. using setInterval to send some message at Front-end

[jaydeep1992]

"react": "16.8.3",
"react-native": "^0.59.9",
"socket.io": "^2.2.0"

I've used this library for chatting and to get some events. It works fine in ios but creates an issue in android. It lost socket connection anytime and re-connect. It continuously display same behavior. and also give this transport close or ping timeout error

[BrijeshShiroya]

"react": "16.8.3",
"react-native": "^0.59.9",
"socket.io": "^2.2.0"

I've used this library for chatting and to get some events. It works fine in ios but creates an issue in android. It lost socket connection anytime and re-connect. It continuously display same behavior. and also give this transport close or ping timeout error

+1

[picodoth]

In our case, the issue is caused by CDN proxy. I solved this problem by connecting socket.io to the original site that was not CDN proxied.

[baflo]

We tackled this problem by updating the nginx ingress controller!

[Roderik-EY]

After reading several comments on different threads, I've tried pretty much all suggestions made in order to mitigate this transport close issue. Despite the versions I use on the client/server (currently 2.0.3), I get this behavior once I deploy my microservices using Kubernetes.
Currently, the server has the following configuration:

As others have mentioned, whenever I run the application locally there is no disconnection. I have read on a different thread that version 3 for socket.io will change the ping/pong so it's done for the server and this might help to fix this. Has anyone have any news or updates regarding this issue or a possible date for this new version?

[micahbule]

I have seen this error, when the thread was blocked frequently for more than 200ms.
If this happens frequently this is bad for the socket.io and for your app as well.
The socket.io has a timeout to check the heartbeat of the connection.
If this timeout is exceeded then it shutdowns the connection and we get this error.

For those that are using Socket.IO to send large amounts of data, make sure to do it in a manner that doesn't block the thread. I encountered this today using the socket client on React Native and I'm using it to send files to the server. Because of how we wrote the sending of files through the socket, which is essentially all-in-one-go instead of sequentially, the JS thread gets choked and can't send a pong back to the server, disconnecting it, giving us this error.

[robert-bitguild]

I have same issue on my app, I don't think is ping pong issue. I doubt it should be issue cause by server side which closed the transport of socket.

[ErnandesAJr]

The same problem. In an Angular browser.

This configuration has considerably reduced the number of reconnections :

I used forceJSONP because of cors

[ranupoju0126]

After my analysis, I found the below issue

ISSUE:
Sockets are working fine without any disconnects locally, but when deployed to environments sockets are disconnecting with "transport close" as disconnect reason.

I saw this issue only when running the node application using an upstart service or systemmd service, if we run the application like node app.js, I am NOT seeing this issue.

SIMPLE FIX/WORKAROUND:
On the client-side, on socket disconnect, socket emit add a user (angular 11)

  self.socket.on('disconnect',  (reason) => {
        if(currentUser){
            self.socket.emit('add user', currentUser);
        }
    })

With the above scenario, all the users are always connected and online, will be disconnected when loggedout

[rayliao]

have the same problem. finally I resolve it. Nginx is my proxy server , but proxy_read_timeout of config is 60s , it indicates that if client or server doesnot emit any message in 60s , nginx will disconnect , so we can got that transport close errorMsg.

the solution:

1. increase the proxy_read_timeout to 600s or more
2. using setInterval to send some message at Front-end

It works !

[darrachequesne]

I'm going to close this issue, because there seems a lot of different problems thrown here.

I need to keep connection stable for 8~9 hour but it unexpectedly disconnect.

In any case, please note that this is not possible. There is a lot of things that can break a TCP connection (and thus a WebSocket connection), your application shouldn't rely on a always-healthy connection.

[smali-kazmi]

Today i was suddenly facing this issue on production when i debug this error root cause was that there was an exception in code and was reseting all my socket connection

[sergiofm]

I my case, this was the problem: https://socket.io/docs/v4/troubleshooting-connection-issues/#you-are-trying-to-send-a-huge-payload
I was sending a huge payload and was with the default ping timeout.
Changing the pingTimeout to 90000 solved the problem for me.
Hope this helps somebody.

[Cuieney]

i try to upgrade node version to > 10.0.0 is working for me

[YeshrajB]

I was using the socket-io client package for flutter and made a mistake of assigning a string to the auth parameter of the socket instance
Socket socket = io(...);
socket.auth = "my auth token";

I changed it to an object and it worked.

socket.auth = { "auth_token": "my auth token"};

[nivapo95]

For anyone still facing this issue after trying all the solutions in this thread, in my case the issue was with the new version of Next.js (>13.2.4) installed on my environment.

You can read more on the issue and the solutions in this thread: vercel/next.js#49334

If that's not the case for you and you still have this issue, the 3 most possible explanations for a disconnection are:

The browser tab was minimized and heartbeat has failed
The client is not compatible with the version of the server
You are trying to send a huge payload

Hope this helps anyone out there ❤️

[nodecook-dev]

have the same problem. finally I resolve it. Nginx is my proxy server , but proxy_read_timeout of config is 60s , it indicates that if client or server doesnot emit any message in 60s , nginx will disconnect , so we can got that transport close errorMsg.

the solution:

1. increase the proxy_read_timeout to 600s or more
2. using setInterval to send some message at Front-end

Thanks! you save my life!

[darrachequesne]

@nodecook-dev I've added a note about proxy_read_timeout in the documentation: https://socket.io/docs/v4/troubleshooting-connection-issues/#something-between-the-server-and-the-client-closes-the-connection

For future readers:

Please check our troubleshooting guide: https://socket.io/docs/v4/troubleshooting-connection-issues/

[roy2651]

have the same problem. finally I resolve it. Nginx is my proxy server , but proxy_read_timeout of config is 60s , it indicates that if client or server doesnot emit any message in 60s , nginx will disconnect , so we can got that transport close errorMsg.

the solution:

1. increase the proxy_read_timeout to 600s or more
2. using setInterval to send some message at Front-end

in nginx config file

proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 300s;
proxy_send_timeout 300s;
proxy_connect_timeout 300s;

but when I use domian some times is disconnect ：transport close
howerver I connect my socket.io server via ip ，it is ok !
somebody can help me?