nginx 1.20

1.20 released 20 April 2021, latest 1.20.2.

nginx 1.20 reached end of life on 24 May 2022.

What changed

NGINX 1.20 is the stable branch that consolidated the preceding 1.19 development-series work, so its change set is substantial relative to the earlier 1.18 stable line. It added controls including proxy_cookie_flags for setting cookie security attributes, ssl_reject_handshake for deliberately rejecting TLS handshakes on selected virtual servers, and ssl_conf_command for passing supported TLS settings to OpenSSL. It also expanded upstream TLS configuration, including variable support for proxy and gRPC client-certificate settings. The branch contained experimental QUIC and HTTP/3 support; that implementation should not be treated as equivalent to the later production HTTP/3 implementation. As with other NGINX upgrades, configuration syntax, module behavior, TLS-library interaction, and any third-party dynamic modules need validation in the target build.

What staying costs

NGINX 1.20 has reached end of life and upstream no longer supplies fixes for this branch. Remaining on it leaves the deployment without upstream corrections for subsequently discovered security issues, HTTP and TLS defects, request-processing bugs, and compatibility problems with newer operating-system and cryptographic-library environments. The practical impact depends on exposure and local mitigations, but internet-facing reverse proxies are particularly sensitive because they process untrusted requests and TLS handshakes. A distribution or appliance vendor may backport selected patches, but those patches are vendor-specific and do not make upstream 1.20 maintained. Staying also increases migration cost over time as configuration assumptions, observability integrations, and third-party modules diverge from supported NGINX releases.

What to do

Plan a move to a currently supported NGINX branch, selecting the stable or mainline track according to the organization’s update policy and required features. First inventory the running binary, build options, packaged versus self-built provenance, OpenSSL linkage, loaded dynamic modules, included configuration files, and any Lua or other third-party extensions. Build the chosen target in a non-production environment and run nginx -t against the full rendered configuration. Test TLS negotiation, HTTP/1.1 and HTTP/2 behavior, upstream proxying, WebSocket or gRPC traffic, request limits, cache behavior, logging, reloads, and any stream configuration. Rebuild or replace third-party dynamic modules for the target version rather than reusing old binaries. If QUIC or HTTP/3 is in use, treat it as a separate migration test because the experimental 1.20 configuration and behavior should not be assumed compatible with current HTTP/3 support. Roll out with monitoring and a tested rollback path, then remove the obsolete 1.20 packages and binaries after the replacement is verified.

We can tell you what moving off nginx 1.20 involves.

What it takes to move off nginx 1.20 depends on what you built on it — the version you are on, how much depends on it, and how much of the work is mechanical. Leave your email with this version and we can tell you what that looks like for you.

Not sure yet? Get my plan