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

By Greg Nowak. Updated 21 July 2026.

NGINX 1.30 changes an assumption that has sat quietly inside many reverse-proxy configurations for years. HTTP proxying now uses HTTP/1.1 and keeps upstream connections alive by default, instead of normally opening a fresh connection for each request.

For a modern application, connection reuse is usually a welcome improvement: fewer connection handshakes and less avoidable work between NGINX and the backend. But an apparently routine package update can expose old applications, connection-dependent authentication or configuration copied from an earlier NGINX era. That makes this a small compatibility project, not merely a package-manager task.

As of 21 July 2026, NGINX 1.30.4 is the current stable release. It also includes security fixes published on 15 July, so teams already running an earlier 1.30.x release should plan to move to the patched version rather than stopping at 1.30.0.

What changed in NGINX 1.30?

The change first appeared in mainline version 1.29.7 and reached the stable branch with 1.30.0. The default proxy protocol is now proxy_http_version 1.1. NGINX also enables an upstream keep-alive cache equivalent to keepalive 32 local: up to 32 idle connections per worker, kept local to the location using the upstream.

The number 32 is not a limit on total backend connections. It only controls how many idle connections each worker may retain. Active traffic can still create more. This distinction matters when estimating backend capacity or investigating a rise in open sockets.

Situation	Recommended starting point	Verify before rollout
Modern HTTP application	Use the new defaults	Error rate, response time and backend connection counts
Old or vendor-managed application	Test connection reuse in staging	Sessions, intermittent failures and stale responses
NTLM or Negotiate authentication	Review the upstream authentication configuration	Login, re-authentication and concurrent user journeys
Explicit `keepalive 32;` in a shared upstream	Decide whether sharing is intentional	Whether connections may be reused across locations
Backend requires a fresh connection	Downgrade only the affected location	That the exception does not spread to healthy routes

A practical decision matrix for an NGINX 1.30 upgrade review.

Audit the configuration NGINX actually loads

Do not begin with the one configuration file someone remembers editing. Includes, deployment templates and hosting control panels often make the effective configuration quite different. The -T option checks the configuration and prints all loaded files:

sudo nginx -T 2>/dev/null | grep -nE \
'proxy_http_version|proxy_set_header[[:space:]]+Connection|keepalive|ntlm'

sudo nginx -V
sudo nginx -t

The first command finds the directives most likely to affect this change. nginx -V records the installed version, build options and modules; nginx -t should be run again immediately before reloading.

Pay particular attention to proxy_set_header. These directives inherit from the parent context only when none are defined at the current level. Adding one header inside a location can therefore stop the complete parent set from being inherited. Review each block as a group rather than deleting a single line in isolation.

Challenge old keep-alive snippets

Before 1.29.7, administrators commonly enabled upstream reuse with:

proxy_http_version 1.1;
proxy_set_header Connection "";

Those lines are no longer required merely to obtain standard HTTP/1.1 keep-alive behaviour. They are not automatically harmful, but redundant configuration creates doubt about what is deliberate. Remove it through a tested change, especially if the same include serves several client sites.

An explicit keepalive 32; deserves closer attention. Under current NGINX behaviour, omitting the directive uses local connection caches. Writing it without the local parameter permits matching cached connections to be reused across locations that reach the same upstream address. If isolation is the intention, make it explicit:

upstream application_backend {
    server 127.0.0.1:8080;
    keepalive 32 local;
}

Do not tune keepalive_requests, keepalive_time or keepalive_timeout simply because they exist. Change them only in response to a documented backend constraint, measured socket pressure or a reproducible failure.

Give awkward backends a narrow exception

Legacy applications can make connection-scoped assumptions that ordinary browser testing misses. Exercise login and logout, parallel requests, file uploads, administrative actions, timeout recovery and requests made after an idle period. For NTLM or Negotiate authentication, confirm that the upstream uses NGINX's ntlm handling and test with realistic concurrent sessions.

If a backend genuinely requires HTTP/1.0 and closed connections, contain the exception to its location:

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

This sacrifices reuse only where necessary. A server-wide downgrade would hide the compatibility issue while discarding the benefit for every healthy application.

Make the rollout observable and reversible

Capture a baseline before upgrading: upstream response and connection times, 502 and 504 rates, authentication failures, backend connection counts and application logs. Then canary the routes most likely to expose trouble—authentication, administration and older line-of-business applications—rather than assuming the busiest public page is the best test.

Keep the previous package and configuration deployment path available, but prefer a narrow configuration exception when one backend fails. Record why that exception exists and who owns its removal. Otherwise, today's emergency line becomes tomorrow's unexplained infrastructure folklore.

For business owners and agency teams, the useful deliverable is not simply “NGINX upgraded.” It is an inventory of affected applications, a tested configuration, agreed monitoring and a rollback decision that somebody can execute. If your estate mixes inherited client configurations with older vendor systems, Greg can help turn that review into a controlled upgrade plan.