Latest Pre-release in branch 1.13 (Mainline)
1.13.12
Released 10 Apr 2018
(8 years ago)
SoftwareNGINX OSS
Version1.13 (Mainline)
Status
End of life
Initial release1.13.0
25 Apr 2017
(9 years ago)
Latest release1.13.12
10 Apr 2018
(8 years ago)
End of security fixes05 Jun 2018
(Ended 8 years ago)
Release noteshttps://nginx.org/en/CHANGES
Source codehttps://github.com/nginx/nginx/tree/release-1.13.0
Documentationhttps://nginx.org/en/docs/
NGINX OSS 1.13 (Mainline) ReleasesView full list

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.

Releases In Branch 1.13 (Mainline)

VersionRelease date
1.13.1210 Apr 2018
(8 years ago)
1.13.1103 Apr 2018
(8 years ago)
1.13.1020 Mar 2018
(8 years ago)
1.13.920 Feb 2018
(8 years ago)
1.13.826 Dec 2017
(8 years ago)
1.13.721 Nov 2017
(8 years ago)
1.13.610 Oct 2017
(8 years ago)
1.13.505 Sep 2017
(8 years ago)
1.13.408 Aug 2017
(8 years ago)
1.13.311 Jul 2017
(9 years ago)
1.13.227 Jun 2017
(9 years ago)
1.13.130 May 2017
(9 years ago)
1.13.025 Apr 2017
(9 years ago)