NGINX 1.30 changed upstream connection reuse by default: what to check before you upgrade

By Greg Nowak. Last updated 2026-06-18.

As of June 17, 2026, NGINX lists 1.30.3 as the current stable release. The behavior change that matters here arrived earlier: mainline 1.29.7 on March 24, 2026 switched HTTP proxying to HTTP/1.1 with upstream keep-alive by default, and stable 1.30.0 brought that into the long-lived branch on April 14, 2026. That is good news for latency and time to first byte. It is also the point where a routine package update becomes a small compatibility review.

If you run client sites, legacy apps, vendor platforms, or a mixed agency estate, the main risk is not that NGINX suddenly became unreliable. The risk is that old backends and inherited config were quietly built around fresh TCP connections for each request. Reused upstream connections can expose brittle authentication flows, connection-scoped assumptions, or copied directives that nobody has reviewed in years.

If your setup looks like this	Default move	What to verify
Standard HTTP web app	Keep the new default	Latency, error rate, and backend connection counts
Shared upstream block across several locations	Review explicit keepalive settings	Whether reuse should stay local or be shared
NTLM or Negotiate authentication	Test before rollout	Whether auth context depends on a stable upstream connection
Legacy app expects fresh connections	Use a narrow HTTP/1.0 downgrade	That only the affected path loses keep-alive
Interest in Early Hints	Ship separately	That only capable clients receive 103 responses

A quick decision matrix for planning an NGINX 1.30 upgrade.

What actually changed

NGINX's own release notes are clear: 1.29.7 changed the default proxy HTTP version to 1.1 with keep-alive enabled, and 1.30.0 carried that into stable. The current proxy module docs show proxy_http_version 1.1 as the default, while the upstream module now documents keepalive 32 local as the default cache of idle upstream connections per worker. In plain English, connection reuse is now normal behavior, not an optional tuning trick.

That does not mean every old keep-alive snippet is wrong. It means you should stop treating inherited snippets as automatically correct. The same upstream docs note that an explicit keepalive 32 behaves differently from the new default keepalive 32 local: without local, cached connections can be shared across locations that hit the same upstream address. In a shared estate, that deserves deliberate review.

Where teams usually get caught

Legacy vendor apps or older in-house services that behave differently when several requests arrive over one TCP connection.
Authentication paths, especially NTLM or Negotiate flows, where NGINX documents that the upstream connection can be bound to the client connection to preserve authentication context.
Shared upstream blocks reused by public pages, admin paths, or APIs with different expectations.
Old snippets such as proxy_http_version 1.1; and proxy_set_header Connection ""; that were copied years ago and never revisited after the default changed.
Blind tuning of keepalive as if it were a hard connection cap. NGINX explicitly warns that it only limits idle cached connections per worker, not total upstream connections.

Audit first, then change config

Start with the effective configuration, not just the files you remember editing. On estates with includes, templates, or generated config, nginx -T is the fastest way to see what is really live.

nginx -T 2>/dev/null | rg -n 'proxy_http_version|proxy_set_header Connection|keepalive|ntlm|early_hints'
rg -n 'proxy_http_version|proxy_set_header Connection|keepalive|ntlm|early_hints' /etc/nginx

Any proxy_set_header line is worth reading carefully because those directives are only inherited when the current block defines none. One copied override can change more than teams expect.

From that inventory, answer five practical questions before you schedule the maintenance window:

Which upstreams are HTTP proxy targets, and which are FastCGI, uwsgi, or SCGI paths with different rules?
Where are you still forcing proxy_http_version 1.0 or 1.1 explicitly?
Which shared upstream blocks declare keepalive without local?
Which routes carry awkward authentication, old vendor software, or long-running admin tasks?
What will you watch during canary rollout: 502s, auth retries, backend connection counts, idle socket growth, and response time changes?

What to change, and what to leave alone

If an old snippet was added only to enable HTTP/1.1 keep-alive on pre-1.29.7 NGINX, it may now be redundant. Do not mass-delete it in production without testing, but do challenge it. The goal is a config that reflects present intent, not a copied habit from an older NGINX era.

If a backend genuinely requires the older behavior, keep the downgrade narrow and local to that path:

location /legacy-app/ {
    proxy_pass http://legacy_backend;
    proxy_http_version 1.0;
    proxy_set_header Connection "Close";
}

For modern backends, the default behavior is usually the right one. Where you do need explicit tuning, work with the current upstream controls: keepalive, keepalive_requests, keepalive_time, and keepalive_timeout. If you keep an explicit keepalive directive on shared upstream blocks, choose local-only reuse or broader sharing on purpose, not by accident.

The same release train also brought Early Hints into stable. Treat that as a separate feature flag. NGINX's Early Hints guidance says proxying 103 responses is off by default and shows a pattern for limiting them to likely-capable clients, commonly HTTP/2 and HTTP/3 first. Older HTTP/1.1 clients can misparse an unexpected 103 response, so it is better not to bundle that experiment into the same rollout unless you have time to test it properly.

A safe rollout looks boring, and that is the point

The sensible path is to upgrade to the latest stable 1.30.x release, not 1.30.0 specifically, stage the config cleanup, and canary the traffic that is most likely to break first. For most teams that means admin routes, authentication paths, and older line-of-business apps before high-volume brochure pages. If the estate spans client work, vendor software, and multiple inherited NGINX patterns, this is exactly the kind of change that benefits from a short audit and a written rollout plan.

If you want a second set of eyes on that review, Greg can map the effective proxy path, identify the places that should stay on older behavior, and help you remove stale config without losing the performance upside NGINX intended. Talk to Greg about an NGINX upgrade review.