An idle timeout is the period of inactivity after which a network device or server closes a connection. The clock resets whenever data moves in either direction, and the connection is dropped when it reaches zero.
Why it matters
Idle timeouts protect servers from piling up dead connections, but mismatched values cause baffling errors. If a load balancer closes idle connections after 60 seconds and your backend keeps them for 75, the backend may try to reuse a connection the balancer already dropped, producing intermittent 502 errors. Long-polling, WebSockets and slow report endpoints are the usual victims.
Example
A common rule is that the component closer to the client should have the shorter idle timeout, and the component behind it a longer one, so the backend never reuses a connection the front end has already closed. In nginx, for instance:
keepalive_timeout 65s;
Check the documented default for your load balancer and server, because they differ and change between versions. For long-lived streams, send periodic application-level pings or enable TCP keepalive so the connection never looks idle.
Common mistakes
- Setting the backend timeout shorter than the proxy's, so the backend closes first and the proxy hits a reset.
- Assuming an idle timeout limits request duration. It does not; the request timeout does.
- Forgetting NAT gateways and firewalls, which have their own idle limits.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.