What Is New in NGINX 1.13
NGINX 1.13 introduced several key updates focused on enhancing core functionality and modernizing its feature set. The main additions include a new stream module directive and improvements to SSL/TLS handling.
| Category | Key Changes |
|---|---|
| New Features | TCP/UDP load balancing with the ssl_preread directive, support for the PROXY protocol in the mail module. |
| SSL/TLS | Support for multiple certificates with different algorithms (RSA and ECDSA) for a single virtual server. |
| Core | New max_errors directive for logging rate limiting, improved hash table handling. |
| Bug Fixes | Fixes for issues in the stream module, HTTP/2, and memory handling. |
How did TCP/UDP load balancing get smarter?
The standout feature is the ssl_preread directive within the stream module. This lets you inspect the initial ClientHello message of a TLS connection without decrypting it, which is perfect for routing based on the SNI (Server Name Indication) or ALPN. In practice, this means you can direct different TLS services—like HTTPS, IMAPS, or a custom TLS service—to different backend server groups from a single load balancer port.
Before this, routing TCP/UDP traffic based on content required terminating the TLS connection first. This change keeps the load balancer lightweight and efficient, as it only reads the header information without the computational overhead of decryption.
What changed for SSL/TLS certificate management?
NGINX 1.13 added the ability to serve multiple certificates with different algorithms for the same virtual server. You can now configure both an RSA and an ECDSA certificate for a single listen directive. The server automatically presents the most appropriate certificate to the client based on the supported algorithms during the handshake.
This is a step forward for forward secrecy and performance. ECDSA certificates are smaller and faster for signing, while RSA maintains broader compatibility. Offering both lets you optimize for modern clients without breaking older ones.
Were there any logging improvements?
Yes, the new max_errors directive for error logging was introduced. This directive limits the rate at which repeated errors are logged to avoid filling up disk space when a specific error occurs frequently in a short period.
This is useful for suppressing noise in the error log. For example, if a client is repeatedly failing to authenticate, you'll still see the first few errors, but not an endless stream of identical messages, making it easier to spot new and different problems.
FAQ
What is the primary use case for the ssl_preread directive?
Its main use is for SNI-based routing in a TCP/UDP stream context. It allows you to route incoming encrypted TLS traffic to different backend pools based on the domain name the client is requesting, all without having to terminate the SSL connection on the load balancer.
Can I use both RSA and ECDSA certificates simultaneously?
Yes. You simply list both certificates in your server block's ssl_certificate and ssl_certificate_key directives. NGINX will automatically select the best one during the TLS handshake with the client.
Does the PROXY protocol support in mail module work for both v1 and v2?
The changelog specifies the addition of PROXY protocol support for the mail module but does not explicitly differentiate between versions. Typically, NGINX implements the widely used v1 of the PROXY protocol for such integrations.
Why would I need to limit error logging with max_errors?
This prevents your error logs from being overwhelmed by thousands of identical messages in a short time frame, which can happen during a network outage or a misconfigured client attack. It helps maintain log readability and conserves disk space.
Were there any notable HTTP/2 fixes in this release?
Yes, the release included bug fixes for HTTP/2, though the changelog notes are brief. One specific fix addressed potential issues with handling requests in certain edge-case scenarios to improve protocol stability.