The Practical Developer

Node.js Server Timeouts: The Settings That Stop Slow Clients from Holding Sockets Hostage

May 16, 2026 by The Practical Developer

Your memory stays flat but connection count climbs until new clients get refused. The culprit is almost never a leak. It is a slow client holding a socket forever because Node.js server defaults assume everyone plays nice. Here are the three timeout values that turn a slowloris attack or a runaway upload into a fast error, with the 40-line production config and the test that proves it works.

node.js

reliability

security

A laptop on a wooden desk with soft natural light, the kind of quiet workspace where a single misconfigured timeout can ruin a Tuesday morning

Your memory graph is flat. CPU is flat. But ss -s shows TCP connections climbing every Tuesday at 9 a.m., and eventually new clients get ECONNREFUSED while the pod still has plenty of RAM. The trigger is not a memory leak. It is a connection leak, and the root cause is almost always the same: a client that opens an HTTP connection, sends part of a request, and goes silent. Node.js waits. By default, it waits forever.

The Node.js HTTP server is fast, but its defaults are from an era where the internet was smaller and friendlier. server.timeout is 0, meaning a socket can sit idle indefinitely. server.requestTimeout did not exist before Node.js 18, and even now the default is measured in minutes, not seconds. server.headersTimeout is 60 seconds, which is generous to a fault. And server.keepAliveTimeout is 5 seconds, which seems conservative until your load balancer expects 60.

This post is the three server-side timeout values you actually need, what each one guards against, and the production-ready server setup that turns a slow client from a resource-eating ghost into a fast, clean error.

The shape of the failure

You notice it first as connection exhaustion. Under ss -s or netstat the ESTABLISHED counter climbs into the thousands. The Node.js process RSS stays flat because the kernel, not your application, holds the socket state. But the event loop latency spikes because the TCP backlog is full. New healthy clients sit in the SYN queue until they time out on their end, or they connect and get queued behind the zombies.

Or you notice it during a deploy. Kubernetes sends SIGTERM. The old pod enters graceful shutdown. But twenty sockets are still waiting for a request body that will never arrive. The pod stays in Terminating for the full termination grace period. The new pods are ready and serving traffic. The old pods refuse to die because Node.js will not close sockets that still have “active” requests, even when those requests are never going to finish.

The trigger is almost always one of three things. A mobile app on flaky 2G that sends the headers then loses signal. A third-party integration with a broken HTTP client that opens a connection and forgets about it. Or a scraper running a slowloris-style attack that sends one header byte every 59 seconds. Node.js defaults assume every client is well-behaved and fast. Production is not.

1. headersTimeout: how long a client has to finish the request line and headers

Before any body arrives, the client must send the HTTP method, path, protocol version, and all headers. In a healthy system this takes less than a millisecond. A malicious or broken client can send one byte per minute, keeping the socket open and the parser waiting. This is a classic slowloris attack, and it works against a default Node.js server because headersTimeout is set to 60 seconds.

An attacker can keep a socket busy for a full minute by sending data just frequently enough to avoid triggering idle timeouts. With a 1024 connection limit on a small instance, that is a denial of service from a single IP address. The fix is aggressive and simple:

import http from 'node:http';

const server = http.createServer(app);
server.headersTimeout = 10_000; // 10 seconds is generous

Ten seconds is enough for a genuine client on a slow network to send a few kilobytes of headers. It is not enough for an attacker to weaponize header parsing. If you run behind a CDN or load balancer that terminates TLS and injects large headers, measure the p99 header receipt time in your logs before tightening this. But for most API services, 10 seconds is correct and 60 seconds is a liability.

One detail most teams miss: headersTimeout was added in Node.js 11. Before that, there was no built-in protection against slow header sending at all. If you are on an ancient runtime, upgrade for this feature alone.

2. requestTimeout: how long a client has to send the entire request

headersTimeout fires if the headers take too long. What about the body? Before Node.js 18, there was no built-in timeout for the total request duration including body transfer. A client could send headers immediately, then dribble the body one byte per hour, and the server would wait. Node.js 18 added requestTimeout, which covers the entire request from the first byte to the end of the body.

The default in recent Node.js versions is 300 seconds. That is five minutes. For an API that mostly accepts JSON payloads under 100 KB, five minutes is not generous, it is dangerous. A client that drops connection after sending 50% of a file upload will hold a socket and any associated worker thread for five minutes.

Set it tight at the server level and override it only on routes that genuinely need large uploads:

server.requestTimeout = 30_000; // 30 seconds for the whole request

For a file-upload endpoint that accepts 100MB videos, you might bump that specific route:

app.post('/upload', (req, res) => {
  req.socket.server.requestTimeout = 120_000;
  // ... handle upload
});

But the global default should protect the 95% of your API that accepts small JSON. Do not let the exception become the default.

3. keepAliveTimeout: the idle window between requests on a persistent connection

keepAliveTimeout is not about a single request. It is about the silence between two requests on the same TCP connection. When a client finishes a request and keeps the connection open for reuse, Node.js waits keepAliveTimeout milliseconds for the next request before destroying the socket. The default is 5 seconds.

Five seconds sounds reasonable, but it is the single most common source of “random” 502 errors during deploys. Here is why. Your load balancer (AWS ALB, Nginx, HAProxy) also has a keepalive idle timeout. If the load balancer’s timeout is longer than Node.js’s timeout, the following race happens:

  1. Node.js closes the idle socket after 5 seconds.
  2. The load balancer has the same socket in its pool and sends a new request on it a fraction of a second later.
  3. The request hits a closed socket. The load balancer returns 502 to the client.
  4. The client retries and usually succeeds, but your error rate graph now has a baseline of 0.1% mysterious 502s that correlate with low-traffic periods, not high load.

The fix is to make Node.js’s keepAliveTimeout slightly longer than your load balancer’s idle timeout, not shorter. If your ALB is set to 60 seconds, set Node.js to 65 seconds:

server.keepAliveTimeout = 65_000;

This seems backwards. Most teams set the backend timeout shorter than the proxy timeout to “give the proxy a chance to retry.” That logic does not apply to idle keepalive sockets. The proxy cannot retry a request that was already sent on a socket the backend just closed. The proxy only knows the socket is dead after the request fails. Making the backend timeout longer gives the proxy time to reuse the connection safely.

If you do not know your load balancer’s timeout, find it. For AWS ALB it is 60 seconds by default. For Nginx with keepalive_timeout, check your config. Then add 5 seconds and set Node.js accordingly.

4. timeout: the socket inactivity safety net (and its limits)

server.timeout is the oldest of the four, and the most misunderstood. It sets the number of milliseconds of inactivity before a socket is presumed to have timed out. Default is 0, meaning disabled.

The key word is “inactivity.” If a client sends one byte every 5 seconds, the socket is not idle. timeout will not fire. This means timeout alone does not stop a slow body upload or a slowloris attack. It only catches sockets where nothing is sent at all, which headersTimeout and requestTimeout already handle more comprehensively.

Still, it is worth setting as a global safety net for connections that somehow slip past the other timers, or for protocols where the other timers do not apply:

server.timeout = 120_000; // 2 minutes of absolute silence

Do not rely on timeout as your primary defense. Rely on headersTimeout and requestTimeout. Use timeout as the backup plan.

The production-ready server setup

Here is the 40-line module you drop into your service. It wires the three critical timeouts plus keepAliveTimeout tuned for your load balancer:

// lib/server.js
import http from 'node:http';
import { app } from './app.js';

export function createServer() {
  const server = http.createServer(app);

  // Prevent slowloris-style header attacks
  server.headersTimeout = 10_000;

  // Prevent runaway body uploads
  server.requestTimeout = 30_000;

  // Safety net for completely idle sockets
  server.timeout = 120_000;

  // Must exceed load balancer idle timeout to avoid 502 races
  // Adjust this to (loadBalancerTimeout + 5000)
  server.keepAliveTimeout = 65_000;

  return server;
}

Start it with a deliberate graceful shutdown that respects in-flight requests but does not wait for zombies:

// index.js
import { createServer } from './lib/server.js';

const server = createServer();
const PORT = process.env.PORT ?? 3000;

server.listen(PORT, () => {
  console.log(`Listening on ${PORT}`);
});

function shutdown() {
  console.log('SIGTERM received, closing server');
  server.close(() => {
    console.log('Server closed, exiting');
    process.exit(0);
  });

  // Force exit after 30 seconds even if sockets remain
  setTimeout(() => {
    console.error('Forced exit after graceful shutdown timeout');
    process.exit(1);
  }, 30_000);
}

process.on('SIGTERM', shutdown);
process.on('SIGINT', shutdown);

The server.close() call stops accepting new connections and waits for existing keepalive sockets to close naturally. The 30-second hard limit ensures that a pod with zombie sockets does not stay in Terminating forever. This combination is what makes Kubernetes rolling updates actually roll.

Testing it with curl

You do not need a load test to verify these settings. You need curl and the ability to send data slowly.

Test headersTimeout by sending one header byte per second:

# Send the request line, then sleep. Node should kill this after 10 seconds.
(echo -n 'GET / HTTP/1.1
'; sleep 20) | curl telnet://localhost:3000

Test requestTimeout by sending headers immediately, then a very slow body:

curl -X POST http://localhost:3000/api/data \
  -H 'Content-Type: application/json' \
  -d '{"slow": true}' \
  --limit-rate 1B/10s

With requestTimeout: 30_000, the server should close the connection after 30 seconds even though data is still trickling in.

Test keepAliveTimeout by making a request, waiting, and making another:

curl -v http://localhost:3000/health && sleep 70 && curl -v http://localhost:3000/health

The second request should open a new TCP connection because the first was closed by keepAliveTimeout at 65 seconds.

If any of these tests surprise you, your production server is currently vulnerable.

The interaction with load balancers and proxies

The timeout values above are for the Node.js server. But your Node.js server probably does not face the internet directly. It faces a load balancer, a sidecar proxy, or a CDN. Those intermediaries have their own timeouts, and they interact with yours in non-obvious ways.

Load balancer idle timeout > backend keepAliveTimeout: Causes 502s on low-traffic connections, as described above. Fix: raise keepAliveTimeout.

Load balancer request timeout < backend requestTimeout: The load balancer returns 504 to the client and may or may not close the backend connection. If it keeps the backend connection open, your Node.js handler may continue processing a request whose result nobody wants. Fix: set the load balancer request timeout slightly longer than your slowest legitimate endpoint, or implement request deadlines as described in the request deadlines post.

Proxy buffering hides backpressure: If your proxy buffers the entire response before sending it to the client, the client sees fast response times while your Node.js process is blocked waiting for the proxy to drain the buffer. This is not a timeout issue, but it makes timeout tuning harder because the metrics lie. Fix: disable proxy buffering for streaming endpoints, or account for it in your latency budgets.

The takeaway

Node.js server defaults are designed for development, not production. A server with no request timeout, a 60-second header window, and a 5-second keepalive window is a server that invites slow clients to consume resources indefinitely.

Set headersTimeout to 10 seconds to stop slowloris attacks. Set requestTimeout to 30 seconds to stop runaway uploads. Set keepAliveTimeout to slightly exceed your load balancer’s idle timeout to stop random 502s. Set timeout to 2 minutes as a last-ditch safety net.

Then test it with curl, verify it with ss -s under load, and make sure your graceful shutdown has a hard ceiling so Kubernetes can actually replace your pods.

The cost is four lines of configuration. The benefit is that the next time a client goes silent mid-request, your server gives up in seconds instead of minutes, and the sockets go back into the pool for requests that actually finish.

A note from Yojji

The difference between a service that handles a Tuesday morning traffic spike and one that melts down is often not the application code, but the boundary configuration that decides how long to wait for misbehaving clients. Tuning server timeouts, matching them to load balancer behavior, and verifying them with deliberate tests is the kind of infrastructure discipline that Yojji’s teams treat as standard practice in every production deployment.

Yojji is an international custom software development company founded in 2016, with offices in Europe, the US, and the UK. Their teams specialize in the JavaScript ecosystem (React, Node.js, TypeScript), cloud platforms (AWS, Azure, Google Cloud), and the resilient backend architecture that keeps services running when clients, networks, or upstreams stop cooperating.