Nginx 1.30 Changed the Upstream Defaults—Test Before You Upgrade
By Greg Nowak. Last updated 2026-08-17.
Nginx 1.30 changes something more consequential than a feature list might suggest: the way reverse-proxy connections behave by default. Upstream HTTP traffic now uses HTTP/1.1, and each worker can cache up to 32 idle keepalive connections.
For many systems, that will reduce repeated connection setup and make a few old configuration lines redundant. It can also leave more backend connections open, increase socket use and expose assumptions buried in inherited configuration.
So this upgrade deserves a realistic staging run. HTTP/1.1 and connection reuse are usually sensible choices; the practical issue is whether your application servers, connection limits and traffic patterns are ready for the new baseline.
What changed in Nginx 1.30?
Nginx 1.30.0 was released on 14 April 2026 and brought changes from the 1.29.x mainline branch into the stable release. Coverage naturally focused on larger additions such as HTTP/2 to backends, Multipath TCP and Encrypted ClientHello. For day-to-day operations, however, the upstream defaults may have the more immediate effect.
Since 1.29.7, proxy_http_version has defaulted to 1.1 instead of 1.0. The upstream module also enables keepalive caching by default with keepalive 32 local.
That 32 is not a cap on every connection a worker can open. It is the maximum number of idle upstream connections kept in each worker process's cache. Active connections sit outside that figure, and the Nginx documentation explicitly warns against treating the keepalive value as a total connection limit.
Recalculate the connection budget
A useful starting estimate is 32 cached idle connections multiplied by the worker count for each relevant cache context. Then account for active requests, multiple upstream groups and locations with separate scoping. This is capacity-planning arithmetic, not a hard limit enforced by Nginx.
With four workers, for example, one applicable cache context could retain 128 idle upstream connections before any busy connections are counted. Add several upstreams or separately configured locations and the footprint can rise quickly. Whether that is comfortable depends on the backend's worker pool, file-descriptor allowance and connection policy.
Existing max_conns values do not remove the need to measure. The upstream documentation notes that the combination of multiple workers, shared memory and idle keepalive connections can push active and idle connections beyond max_conns. Backend observations are the reliable test of the real aggregate load.
| Check | What to inspect or replay | What good evidence looks like |
|---|---|---|
| Effective configuration | Inherited and generated proxy_http_version, keepalive, max_conns, Host and Connection settings |
The exact staging configuration, with redundant or conflicting overrides identified |
| Connection capacity | Worker count, upstream groups, location scoping and backend limits | Idle, active and peak upstream connections for each backend |
| Ordinary HTTP | Representative request rates, payload sizes and concurrency | Before-and-after latency, connection churn, errors and backend saturation |
| Streaming traffic | Long responses, buffering behaviour and relevant timeouts | Completion rates, disconnects, held connections and memory pressure |
| WebSockets | Upgrade handling, long-lived sessions and reconnect behaviour | Successful upgrades, session duration, unexpected closures and backend distribution |
| Rollback | The previous package and configuration, plus explicit post-upgrade settings | A rehearsed reversal path with clear go or no-go thresholds |
Review the configuration Nginx actually loads
Established Nginx installations rarely depend on one tidy, handwritten file. Package defaults, control panels, deployment templates and included snippets can all contribute directives. The useful inventory is therefore the fully assembled configuration loaded by the workers.
Look for explicit proxy_http_version 1.1 declarations, upstream keepalive values and changes to the Connection header. In the keepalive example, the documentation now describes the explicit HTTP/1.1 and cleared-Connection lines as requirements for versions before 1.29.7. Those lines may now be harmlessly redundant, but they can also obscure differences between locations and make the intended behaviour harder to read.
Do not delete an override just because it appears to match the new default. Find out why it exists and check how inheritance affects it. The proxy module inherits proxy_set_header directives only when none are defined at the current level. A local header rule that looks unrelated can therefore change the complete effective header set.
There are also legitimate reasons to retain the old behaviour. Some backends may still require HTTP/1.0 or handle reused connections poorly. NGINX Plus upgrade guidance tells operators in those cases to set proxy_http_version 1.0 or disable upstream keepalive with keepalive 0. An explicit compatibility choice is easier to maintain than an accidental dependency on an old default.
Test the awkward traffic too
A benchmark full of short, successful requests will miss much of what matters here. Connection lifetime becomes more visible with slow responses, streaming traffic and WebSocket sessions, so include those paths whenever production uses them.
Run the existing release and the intended 1.30 point release against the same representative traffic mix. Compare upstream connection creation and reuse, active and idle socket counts, latency, application queueing, errors and backend saturation. Faster connection reuse is useful only if it does not consume capacity that the backend needs for incoming work.
Give long-lived traffic its own observation period. WebSocket proxying has specific configuration requirements, while streaming behaviour depends on buffering and timeouts. Check that upgrades succeed, sessions remain stable, expected disconnects are handled correctly and clients recover after a backend restart. Results from ordinary page requests cannot answer those questions.
Upgrade to the point release you will actually run
The official 2026 news record shows that 1.30.1 through 1.30.4 followed the initial stable release with security fixes. The changed defaults are a reason to test carefully, not a reason to remain on 1.30.0. Stage the current approved point release that is intended for production.
The upgrade record should make the final choices plain: the upstream protocol, whether keepalive remains enabled, the intended idle-cache size, the capacity assumptions and the metrics used to approve rollout. Leaving the new defaults in place is perfectly reasonable when the evidence supports them. It should still be a conscious, documented decision.
Greg can help untangle inherited and generated Nginx configuration, model the per-worker connection footprint and replay representative HTTP, streaming and WebSocket traffic in staging. That work turns an upgrade from a package change into a decision backed by observed latency, socket use and backend saturation, with explicit settings and rollback criteria ready for production.
Related on GrN.dk
- SEO Trends for 2026: What Actually Changed Since 2024
- Shorter TLS certificates expose every renewal you never automated
- A stray Set-Cookie can waste your CDN: audit the cache at the edge
Need help with this kind of work?
Plan your Nginx upgrade review Get in touch with Greg.