I doubt this will solve the issue. It's a different type of keepalive check, which operates at the TCP socket level, not HTTP. Setting socket.setKeepAlive doesn't prevent the agent from closing the socket when keepAlive isn't activated.
P.S. We don't have any tests that could cover this issue or your change.

I doubt this will solve the issue. It's a different type of keepalive check, which operates at the TCP socket level, not HTTP. Setting socket.setKeepAlive doesn't prevent the agent from closing the socket when keepAlive isn't activated. P.S. We don't have any tests that could cover this issue or your change.

Thanks — you’re right that TCP keep-alive (socket.setKeepAlive) and the Agent’s keep-alive/pooling behavior are different things. To be explicit:

agent.keepAlive controls whether the Agent keeps sockets open and reuses them (HTTP-level pooling).
socket.setKeepAlive(true) turns on TCP-level keepalive probes on a socket (OS-level probes), which is independent from whether the Agent will put the socket back into its pool.
The change in this PR does not attempt to change Agent pooling behavior. Its purpose is simply to avoid unconditionally enabling TCP keepalive probes when a user explicitly configured their Agent with keepAlive: false. Previously axios always called socket.setKeepAlive(true) on the socket, overriding a user intent to disable any keep-alive-related behavior. That mismatch can make some Node+server combinations behave poorly (the ECONNRESET seen in the report).

In short: the change aligns axios with the user-provided agent setting (don’t turn on TCP keepalive if the user set keepAlive: false — it doesn’t change how the agent pools or closes sockets.

Next step: I can add a focused unit test that:

Mocks a socket object and verifies socket.setKeepAlive is NOT called when http.Agent({ keepAlive: false }) is provided, and IS called when keepAlive is true or no agent is provided, and
(optional) Adds a small integration test that reproduces the original ECONNRESET scenario (server that closes sockets / aborts) to demonstrate the regression is resolved.

Mocks a socket object and verifies socket.setKeepAlive is NOT called when http.Agent({ keepAlive: false }) is provided, and IS called when keepAlive is true or no agent is provided

Enabling keep-alive enables socket.setKeepAlive, but that doesn't mean disabling keep-alive should disable socket.setKeepAlive.
socket.setKeepAlive is designed to enable socket testing mode at the OS level and keep the connection open through proxies and other network infrastructure when there's no user data transfer for a long time, to determine socket health.
The user can implement long intervals between data transfers when streaming, for example, opening a connection and waiting for a message from the server (long-polling) or rarely sending an event to the server. This has almost nothing to do with the timeout between HTTP connections over TCP socket.

In short: the change aligns axios with the user-provided agent setting (don’t turn on TCP keepalive if the user set keepAlive: false — it doesn’t change how the agent pools or closes sockets.

socket.setKeepAlive should be used regardless of keep-alive if the socket may be long-lived with long intervals between data transfers to detect connection failures and to prevent proxy servers from closing such connections due to lack of actual data transfer. That is why socket.setKeepAlive is always on.
As I already said, socket.set KeepAlive does not prevent the agent from closing it, it only enables system pings while the socket is open, but user data does not pass through it for a long time.