Last checked and updated on 05 Jun 2026
What Is New in NGINX 1.23
NGINX 1.23 introduces several key updates focused on HTTP/2 performance, enhanced logging, and core improvements. This release continues to refine the proxy experience and streamline server operations.
| Category | Key Changes |
|---|---|
| New Features | Directive for HTTP/2 max concurrent streams, QUIC experimental module support |
| Improvements | SSL shutdown handling, more detailed SSL error logging, limit_req status code change
|
| Bug Fixes | Resolver, HTTP/2, SSL, and memory pool issues |
How does HTTP/2 performance get better in 1.23?
The new http2_max_concurrent_streams directive gives you precise control over concurrency within an
HTTP/2 connection. Before this, you could only set this limit globally at the OS level. This matters because it
allows for more granular tuning on a per-server or per-location basis, preventing a single client from
monopolizing connection resources and leading to a more balanced load distribution.
What logging enhancements were made?
SSL error logging is now significantly more detailed. The ssl_verify_client directive logs the
specific verification failure reason instead of just a generic error. In practice, this means you no longer have
to guess why a client certificate was rejected-you get the exact OpenSSL error code, which drastically cuts down
debugging time for mTLS and other secure client authentication setups.
Were there any changes to rate limiting?
Yes, the status code returned by the limit_req module upon rate limit failure has been changed from
503 (Service Unavailable) to 429 (Too Many Requests). This is a much more semantically correct response that
clients and APIs expect. It helps monitoring systems and client applications properly identify and handle rate
limiting without confusing it with a server-side failure.
What core improvements should I know about?
The handling of SSL shutdown operations was improved for better robustness. A fix was also implemented for a bug where memory pools might not be freed under certain conditions in the resolver subsystem, which could lead to gradual memory growth over time. These are the kind of deep, stability-focused fixes that improve long-term uptime.
Is QUIC/HTTP3 supported in this release?
NGINX 1.23 includes an experimental QUIC/HTTP3 implementation. It's important to understand this is not yet
production-ready and is provided for testing and evaluation purposes. You must compile NGINX with the
--with-http_v3_module configure option to enable it, as it's not included in the standard builds.
FAQ
Why did NGINX change the limit_req status code from 503 to 429?
Using 429 (Too Many Requests)
is the standard, correct HTTP response code for rate limiting. The old 503 code incorrectly suggested a server
error, which could mislead monitoring systems and client applications.
How do I use the new http2_max_concurrent_streams directive?
You can set it within a
http, server, or location block. For example:
http2_max_concurrent_streams 128;. This gives you more granular control than the system-level
http2_max_concurrent_streams setting.
What kind of SSL errors are now logged in more detail?
The enhanced logging specifically
applies to client certificate verification failures triggered by ssl_verify_client. You'll now see
the precise OpenSSL error code explaining why a certificate was rejected, such as a revoked cert or an invalid
CA.
Is it safe to use the experimental QUIC module in production?
No, the QUIC implementation is
explicitly marked as experimental. It's intended for development and testing environments only. Do not deploy it
on critical production systems expecting stability.
What was the memory pool issue fixed in the resolver?
A bug prevented memory from being freed
in certain scenarios when using the resolver directive. This fix prevents a potential slow memory
leak that could occur over an extended period of time under specific conditions.