nginx 1.19

NGINX 1.19 was a mainline development cycle rather than a long-term stable branch. It added more runtime configurability for traffic shaping, including variable support in rate-limit directives such as limit_rate, limit_rate_after, and upstream-module rate limits. It also expanded PROXY-protocol and TLS-related variables and added experimental HTTP/3/QUIC support in later 1.19 builds. That HTTP/3 support was explicitly experimental and required a compatible TLS library and build configuration; it should not be treated as equivalent to the mature HTTP/1.1 and HTTP/2 paths. The cycle also accumulated the usual fixes and protocol, proxying, caching, and TLS improvements that were subsequently carried into later branches.

This cycle has reached end of life, so upstream no longer provides fixes for newly discovered security issues, correctness defects, or interoperability problems in NGINX 1.19. Remaining on it leaves internet-facing proxy, TLS termination, and request-processing behavior dependent on an unmaintained upstream code line. The risk rises when operating-system, OpenSSL, browser, upstream-service, or client behavior changes, because there is no upstream maintenance path for regressions. Distribution vendors may independently backport selected fixes, but that is package-specific and is not the same as support for the upstream 1.19 line. Teams also retain the operational burden of old experimental HTTP/3/QUIC configuration if they enabled it.

Move to a currently supported NGINX release line, using the vendor or distribution package whose maintenance policy matches the deployment. First inventory the running binary, build options, dynamic and third-party modules, included configuration files, TLS libraries, and any locally patched packages. Compare the target release's configuration and module compatibility notes, then test the full configuration with nginx -t and run representative traffic through a staging environment. Validate TLS negotiation, HTTP/2 behavior, proxy headers, PROXY protocol handling, cache behavior, rate limiting, reloads, logging, and upstream failover. If HTTP/3/QUIC was enabled under 1.19, re-evaluate it against the target release's documented implementation rather than carrying the old experimental setup forward unchanged. Deploy with a rollback-tested package and configuration path, and monitor error logs, connection failures, upstream status, latency, and cache outcomes after the change.