How to Cut Nginx HTTPS Latency by 30%: Practical TLS Tuning Guide

Nginx is commonly used as a load balancer, reverse proxy, and gateway. A well‑configured Nginx instance should handle 50K–80K requests per second while keeping CPU load manageable. For instant‑search scenarios, however, the critical metric is end‑to‑end latency: each search request must return within 100 ms–200 ms, making request latency the primary optimization target.

TLS Handshake and Latency

Optimizing network latency often means reducing the number of round‑trips between client and server. Physical distance (e.g., Beijing to Yunnan) already adds ~20 ms per round‑trip; additional TLS handshakes can quickly exceed the latency budget.

Understanding basic TLS and Nginx latency helps identify where round‑trips can be eliminated. For deeper details, see "High Performance Browser Networking".

The diagram shows that before any data is transferred, three round‑trips have already occurred, costing roughly 224 ms if each round‑trip takes 28 ms.

Nginx TLS Settings

Below are the TLS‑related Nginx parameters that can reduce latency.

Enable HTTP/2

HTTP/2 multiplexes many requests over a single connection, dramatically cutting round‑trips compared to HTTP/1.1. Enabling it is as simple as adding the http2 flag.

listen 443 ssl;<br/># change to<br/>listen 443 ssl http2;

If a client does not support HTTP/2, the connection gracefully falls back to HTTP/1.1.

Verify HTTP/2 is active

In Chrome DevTools, check the "Protocol" column for h2. Alternatively, use curl:

➜  ~ curl --http2 -I https://kalasearch.cn<br/>HTTP/2 403<br/>server: Tengine<br/>...

Adjust Cipher Preference

Prefer modern, fast ciphers to reduce handshake time:

# enable server‑preferred ciphers<br/>ssl_prefer_server_ciphers on;<br/>ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';

Enable OCSP Stapling

OCSP stapling removes an extra round‑trip for certificate validation, which is especially beneficial when using Let’s Encrypt certificates that may have slow OCSP responders.

ssl_stapling on;<br/>ssl_stapling_verify on;<br/>ssl_trusted_certificate /path/to/full_chain.pem;

Check status with OpenSSL:

openssl s_client -connect test.kalasearch.cn:443 -servername kalasearch.cn -status -tlsextdebug < /dev/null 2>&1 | grep -i "OCSP response"

Adjust ssl_buffer_size

Smaller buffers can lower latency for REST APIs or web pages, though large file transfers may benefit from the default 16k.

ssl_buffer_size 4k;

Enable SSL Session Cache

Caching SSL sessions avoids repeated handshakes, saving a round‑trip per connection. A 50 MB cache can store ~4000 sessions.

# Enable SSL cache to speed up repeat visits<br/>ssl_session_cache   shared:SSL:50m;<br/>ssl_session_timeout 4h;

Kalasearch Case Study: Reducing 30% Request Latency

Kalasearch, a domestic Algolia‑like service, aims for sub‑200 ms end‑to‑end search. Measurements showed TLS processing in Nginx consuming >300 ms on some iOS devices due to Let’s Encrypt OCSP delays.

After applying the TLS tweaks above, average SSL handshake time dropped from ~140 ms to ~110 ms nationwide, and the first‑visit slowdown on iOS disappeared. Overall search latency fell to ~150 ms across China.

Conclusion

Optimizing Nginx TLS settings can significantly improve HTTPS service latency. This article covered TLS‑related parameters, their impact on round‑trips, and concrete configuration examples. Future posts will explore HTTP/2 advantages for REST APIs in more depth.