nginx 1.21

NGINX 1.21 advanced the mainline 1.19 series and, most notably, added experimental QUIC and HTTP/3 support. That implementation was explicitly experimental, so its configuration, protocol behavior, and operational expectations were not a stable long-term interface. The cycle also accumulated smaller HTTP, stream, TLS, proxying, logging, and bug-fix changes typical of a mainline release line. Teams using third-party dynamic modules should note that NGINX module binaries are tied to the NGINX build and compatibility settings; a module built for an older line cannot be assumed to load unchanged after an upgrade.

NGINX 1.21 has reached end of life. Remaining on it means newly discovered defects and security issues in that release line will not receive upstream fixes. This is particularly material for an Internet-facing reverse proxy, where TLS handling, request parsing, HTTP protocol behavior, caching, and upstream proxying are exposed to untrusted traffic. Its experimental HTTP/3 and QUIC implementation adds a separate risk: it should not be treated as equivalent to the later, maintained HTTP/3 implementation. Staying also increases migration effort over time because configuration, package repositories, operating-system dependencies, and third-party modules continue to move forward while the deployed NGINX line does not.

Plan a move to a currently supported NGINX release line supplied by the chosen vendor or operating-system channel. First inventory the exact NGINX binary, build flags, installed static and dynamic modules, included configuration files, certificates, upstream dependencies, and any QUIC or HTTP/3 listeners. Review the intervening NGINX change logs and the target release documentation for directives whose behavior or syntax affects the deployed configuration. Rebuild or obtain target-version packages for every third-party dynamic module, rather than copying existing module binaries. Test the upgrade in a representative environment with real TLS policies, HTTP/1.1 and HTTP/2 traffic, proxy and cache paths, access controls, rate limits, logging, reloads, and failure handling. If HTTP/3 is enabled, validate it independently on the target version and retain a tested TCP-based HTTP fallback. Deploy through a staged rollout with configuration backups, health checks, and a rollback path.