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

By Greg Nowak. Updated 29 August 2026.

NGINX 1.30 quietly changes an important relationship between your reverse proxy and its HTTP backends. Instead of normally creating a fresh HTTP/1.0 connection for each request, NGINX now uses HTTP/1.1 and keeps upstream connections available for reuse by default.

That is a sensible default for most modern applications. It reduces connection setup and avoidable work between NGINX and the backend. However, it can expose old applications, connection-scoped authentication and configuration inherited from an earlier NGINX era. Treat the update as a small compatibility project, particularly when one server hosts several client or vendor-managed systems.

As of 29 August 2026, NGINX 1.30.4 is the current stable release; 1.31.4 is the current mainline release. Version 1.30.4 also contains security fixes published on 15 July. Check your operating-system vendor’s package history too, because distributions may backport fixes without matching the upstream version number.

What actually changed in NGINX 1.30?

The behavior first appeared in mainline release 1.29.7 and entered the stable branch with 1.30.0. For HTTP proxying, proxy_http_version now defaults to 1.1. Upstream keep-alive caching is enabled by default, equivalent to keepalive 32 local.

The value 32 is the maximum number of idle upstream connections retained per worker process. It is not a cap on active or total backend connections. Under load, a worker can open more. Multiply the idle allowance by the number of workers when estimating the potential socket footprint, then compare that with the backend’s limits.

Backend situation	Starting decision	Evidence to collect
Modern HTTP application	Keep the new defaults	Latency, 5xx responses and backend connection counts
Old or vendor-managed system	Test connection reuse before production	Login, uploads, idle recovery and application logs
NTLM or Negotiate authentication	Review connection-scoped authentication	Concurrent login and re-authentication journeys
Explicit `keepalive 32;`	Decide whether cross-location reuse is intentional	Which locations resolve to the same upstream address
Backend requires fresh connections	Create a narrow location-level exception	A reproducible failure and successful retest

A practical decision matrix for reviewing an NGINX 1.30 upgrade.

Audit the configuration NGINX really loads

Do not limit the review to the file someone remembers editing. Includes, deployment templates, control panels and configuration-management systems can all change the effective result. Start by recording the installed build and searching the complete loaded configuration:

sudo nginx -V

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

sudo nginx -t

nginx -V reports the version, compiler options and included modules. nginx -T tests and prints the loaded configuration, including included files. Treat that output as sensitive: configurations can contain internal addresses, credentials or certificate paths. Run nginx -t again immediately before reloading.

Review proxy_set_header directives as a set. They inherit from the parent level only when the current level defines none of its own. Adding a single header inside a location can therefore prevent the complete parent set from being inherited.

Remove old keep-alive boilerplate carefully

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 solely to obtain standard HTTP/1.1 keep-alive behavior. They are not automatically harmful, but redundant directives make future reviews harder. Remove them through a tested configuration change rather than as casual housekeeping, especially when a shared include serves multiple applications.

An explicit keepalive 32; deserves more attention. Without the local parameter, a matching cached connection may be reused across locations that reach the same upstream address. If isolation between locations is intended, make that choice explicit:

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

Avoid tuning keepalive_requests, keepalive_time or keepalive_timeout simply because the settings are available. Change them only for a documented backend constraint, measured socket pressure or a reproducible fault.

Contain exceptions for awkward backends

Legacy failures are often intermittent. Test login and logout, simultaneous requests, administrative actions, large uploads, timeout recovery and the first request after an idle period. For NTLM or Negotiate authentication, verify the upstream authentication configuration and exercise realistic concurrent sessions.

If a backend genuinely requires HTTP/1.0 and a closed connection, limit the downgrade to its route:

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

A server-wide downgrade may disguise one compatibility problem while removing connection reuse from every healthy application. Document any exception with its reason, owner and removal condition.

Roll out with evidence and a way back

Before upgrading, capture upstream response and connection times, 502 and 504 rates, authentication failures, backend connection counts and relevant application logs. Canary the routes most likely to reveal problems—authentication, administration and older line-of-business applications—rather than testing only the busiest public page.

Keep the previous package and configuration deployment path available. Define who can stop the rollout and what triggers that decision. For a business owner or agency team, the useful deliverable is not merely “NGINX upgraded”; it is an application inventory, a reviewed effective configuration, recorded tests, agreed monitoring and a rollback path.

If your estate combines inherited client configurations with older vendor systems, Greg can help turn the technical review into a controlled upgrade plan that developers, operations teams and stakeholders can all act on.

Related on GrN.dk

Need help with this kind of work?

Plan your NGINX upgrade with Greg Get in touch with Greg.

Sources

Last modified

2026-08-29