What’s the Real Difference Between NGINX keepalive and HTTP keep‑alive?

Explain that “keepalive” is a concept used in both NGINX and HTTP protocol but with different meanings. In HTTP, keep‑alive (or persistent connection) is a header that allows a TCP connection to be reused for multiple requests, reducing latency. In NGINX, keepalive refers to the connection‑pool settings for upstream servers, controlling how many persistent connections are kept and their timeout.

Lin is Dream
Lin is Dream
Lin is Dream
What’s the Real Difference Between NGINX keepalive and HTTP keep‑alive?

NGINX keepalive vs HTTP keep-alive: what’s the difference?

Explain that “keepalive” is a concept used in both NGINX and HTTP protocol but with different meanings. In HTTP, keep‑alive (or persistent connection) is a header that allows a TCP connection to be reused for multiple requests, reducing latency. In NGINX, keepalive refers to the connection‑pool settings for upstream servers, controlling how many persistent connections are kept and their timeout.

HTTP keep‑alive

In HTTP/1.0 connections close after each request unless the Connection: keep-alive header is used. In HTTP/1.1 persistent connections are default; the header Connection: keep-alive signals that the same TCP connection may handle multiple requests, improving performance.

Keeps the connection open to handle multiple requests, avoiding repeated TCP handshakes.

Improves performance, reduces latency and network load, especially under high concurrency.

Example request headers

HTTP/1.1 200 OK
Connection: keep-alive
Keep-Alive: timeout=5, max=100
Content-Type: text/html

The Connection: keep-alive header keeps the connection alive after the response, while Keep-Alive specifies timeout and maximum request count.

NGINX keepalive configuration

In NGINX the keepalive directive configures the upstream connection pool used by reverse proxy and load‑balancing. It works together with keepalive_timeout and keepalive_requests to limit idle time and the number of requests per connection. keepalive – size of the connection pool. keepalive_timeout – idle timeout for connections. keepalive_requests – maximum requests per connection.

Sample upstream block

http {
    upstream backend {
        server 192.168.1.101;
        server 192.168.1.102;
        keepalive 32; # connection pool size
    }
    server {
        location / {
            proxy_pass http://backend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
}

Comparison table

Feature

HTTP keep-alive NGINX keepalive Definition

HTTP header controlling TCP reuse between client and server.

NGINX directive controlling persistent upstream connections.

Purpose

Allow one connection to serve multiple HTTP requests.

Reduce upstream connection overhead and improve proxy performance.

Layer

Application layer (HTTP).

NGINX reverse‑proxy configuration layer.

Configuration

Set via request/response headers.

Set via keepalive directive in config file.

Example Connection: keep-alive and Keep-Alive: timeout=5, max=100. keepalive 32; in upstream block.

Both concepts aim at connection reuse, but HTTP keep‑alive works between client and web server, while NGINX keepalive works between NGINX and its upstream servers.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

PerformanceHTTPReverse ProxyKeepaliveupstreampersistent connections
Lin is Dream
Written by

Lin is Dream

Sharing Java developer knowledge, practical articles, and continuous insights into computer engineering.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.