How does Nginx handle keepalive connections?
Learn how Nginx handles keepalive connections: client and upstream reuse, keepalive_timeout, keepalive_requests, connection pooling, and config examples.
Expected Interview Answer
Nginx handles keepalive by keeping a TCP connection open after a request completes so the same client can send more requests over it, avoiding the cost of a new TCP handshake each time. It manages this separately on the client side (keepalive_timeout and keepalive_requests) and on the upstream side (the keepalive directive inside an upstream block).
For client connections, keepalive_timeout sets how long an idle connection stays open and keepalive_requests caps how many requests one connection may serve before it is closed. For backend connections, adding keepalive N inside an upstream block, together with proxy_http_version 1.1 and clearing the Connection header, lets Nginx maintain a pool of reusable connections to the backend. Reusing connections cuts latency and CPU from repeated handshakes, but connections still consume worker slots, so the timeouts and limits balance reuse against resource usage.
- Avoids repeated TCP and TLS handshakes
- Lowers latency for successive requests
- Reduces CPU and network overhead
- Reuses backend connections via connection pooling
- Improves throughput under high request rates
AI Mentor Explanation
Keepalive is like keeping the same batting pair at the crease between overs instead of sending them back to the pavilion after every ball. They stay padded up and ready, so play resumes instantly. But the umpire still enforces limits — an over count and a fatigue point — much as Nginx caps idle time and requests per connection before retiring it.
Step-by-Step Explanation
Step 1
Understand the goal
Keepalive reuses one TCP connection for multiple requests to skip repeated handshakes.
Step 2
Tune client keepalive
Set keepalive_timeout for idle duration and keepalive_requests for the max requests per connection.
Step 3
Enable upstream keepalive
Add keepalive N inside the upstream block to maintain a pool of reusable backend connections.
Step 4
Use HTTP/1.1 to backend
Set proxy_http_version 1.1 and clear the Connection header so backend keepalive actually works.
Step 5
Balance reuse vs resources
Pick limits that maximize reuse without keeping too many idle connections consuming worker slots.
What Interviewer Expects
- Explaining keepalive as TCP connection reuse
- Distinguishing client-side from upstream keepalive
- Knowing keepalive_timeout and keepalive_requests
- Requiring proxy_http_version 1.1 for upstream reuse
- Discussing the latency vs resource trade-off
Common Mistakes
- Forgetting proxy_http_version 1.1 and Connection header reset for upstream keepalive
- Confusing keepalive_timeout with proxy_read_timeout
- Thinking keepalive keeps connections open forever
- Setting keepalive_requests or timeout so high that idle connections exhaust resources
- Assuming HTTP/1.0 clients benefit from keepalive by default
Best Answer (HR Friendly)
“Keepalive lets Nginx reuse the same open connection for several requests instead of building a new one each time. This is faster and cheaper, like keeping a phone line open for a few questions rather than redialing for every one, with limits on how long and how much a connection is reused.”
Code Example
http {
# Client-side keepalive
keepalive_timeout 65s;
keepalive_requests 1000;
upstream backend {
server 10.0.0.10:8080;
# Pool of reusable connections to the backend
keepalive 32;
}
server {
location /api/ {
proxy_pass http://backend;
# Required for upstream keepalive to work
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}
}Follow-up Questions
- Why must proxy_http_version be 1.1 for upstream keepalive?
- What is the difference between keepalive_timeout and keepalive_requests?
- How does keepalive interact with load balancing across upstreams?
- How does HTTP/2 change the picture compared to keepalive in HTTP/1.1?
- When could keepalive hurt performance or resource usage?
MCQ Practice
1. Which directive enables a pool of reusable connections to a backend?
The keepalive N directive inside an upstream block maintains a pool of reusable backend connections.
2. What is required for upstream keepalive to actually work?
You must set proxy_http_version 1.1 and clear the Connection header so connections to the backend are reused.
3. What does keepalive_requests control?
keepalive_requests caps how many requests a single keep-alive connection may serve before it is closed.
Flash Cards
What is a keepalive connection? — A TCP connection kept open after a request so subsequent requests reuse it, avoiding new handshakes.
What does keepalive_timeout do? — Sets how long an idle client keep-alive connection stays open before Nginx closes it.
How do you enable backend keepalive? — Add keepalive N in the upstream block, set proxy_http_version 1.1, and clear the Connection header.
What does keepalive_requests limit? — The maximum number of requests a single keep-alive connection can serve before closing.