Guide to reducing TLS latency in Nginx: optimize handshakes, OCSP stapling and ciphers on low‑CPU VPS

By Kevin Marcondes · Published on Oct 28, 2026 · 8 min read

This guide shows practical steps to reduce TLS latency in Nginx by optimizing handshakes, OCSP stapling and cipher choices on VPS with limited CPU. You’ll see compatibility trade‑offs, example configs and how to measure improvements. The focus is saving CPU cycles without sacrificing security, emphasizing TLS 1.3, connection reuse, efficient curves, certificate choices and a compact cipher set.

Why the handshake is costly on low‑CPU VPS

The TLS handshake performs expensive cryptographic operations: ephemeral key exchange, certificate verification and secret derivation. On VPS with few vCPUs, each new connection consumes time and CPU. We lower that pressure in three ways: reduce the number of handshakes, make each handshake cheaper and avoid unnecessary external validations.

The practical strategy combines: TLS 1.3 + carefully selected 1.2 fallback, ECDSA with RSA fallback, fast curves, correct OCSP stapling, session and connection reuse, and a compact cipher list. Measurements guide further tuning.

If you don’t yet have certificate automation, see how to get a free SSL certificate with Let's Encrypt (plain reference, not linked).

• Reduce the number of handshakes: keep‑alive and session resumption.
• Make each handshake cheaper: ECDHE with X25519 and ECDSA.
• Avoid external validations: OCSP stapling with local caching.
• Measure and iterate: watch appconnect times and OCSP errors.

TLS 1.3, elliptic curves and certificates (ECDSA + RSA fallback)

TLS 1.3 reduces round trips and simplifies cipher suites. Keep TLS 1.2 for compatibility. Prefer X25519 and P‑256, which are fast. ECDSA typically delivers lighter handshakes than RSA. Loading an ECDSA certificate plus an RSA certificate lets the server negotiate the best option per client.

The configuration below enables TLS 1.3 and 1.2, sets efficient curves and loads both ECDSA and RSA certificates. Use your real file paths and ensure the certificate full chain is provided.

ssl_protocols TLSv1.3 TLSv1.2;
ssl_ecdh_curve X25519:P-256;
# ECDSA (principal)
ssl_certificate     /etc/ssl/certs/site_ecdsa_fullchain.pem;
ssl_certificate_key /etc/ssl/private/site_ecdsa.key;
# RSA (fallback)
ssl_certificate     /etc/ssl/certs/site_rsa_fullchain.pem;
ssl_certificate_key /etc/ssl/private/site_rsa.key;

OCSP stapling to cut validation latency

Without stapling, the client queries the CA, adding unpredictable latency. With OCSP stapling the server delivers the proof of validity during the handshake. That reduces wait on first access and improves reliability.

For stapling to work, Nginx needs the trusted root/intermediate chain. Without ssl_trusted_certificate, stapling silently fails. Also configure a reliable resolver so the server can download OCSP responses.

• Check Nginx error logs when enabling stapling.
• Renew certificates and monitor OCSP response validity.
• Avoid very slow resolvers; they affect OCSP refresh.

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/certs/ca_chain.pem;
resolver 1.1.1.1 1.0.0.1 valid=300s;
resolver_timeout 5s;

Reducing new handshakes: keep‑alive and session resumption

Keeping connections alive and reusing TLS sessions saves CPU. On resource‑heavy sites this reduces usage spikes and improves average TTFB. Rotate ticket keys carefully to avoid invalidating all sessions at once.

Tune keep‑alive, session cache and session tickets. In multi‑instance environments, share the ticket key across nodes so resumption survives deployments.

• Keep‑alive reduces new handshakes during sequential navigation.
• Session cache and tickets allow resuming a TLS session.
• Rotate tickets periodically and use overlap when rotating.

# HTTP keep‑alive
keepalive_timeout 60;
keepalive_requests 1000;

# TLS session resumption
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets on;
# Gere e rotacione esta chave com segurança
ssl_session_ticket_key /etc/nginx/ticket.key;

Lean ciphers and ordering that favors the client's CPU

For TLS 1.2 keep only modern AEADs. ChaCha20‑Poly1305 is great on CPUs without AES‑NI. AES‑GCM is excellent when hardware acceleration exists. A short list speeds negotiation and avoids compatibility pitfalls.

Let the client decide preference when possible. That lets devices with AES‑NI use AES‑GCM and those without pick ChaCha20. If your measurements show ChaCha20 is consistently better for your audience, enable server preference and put ChaCha20 first.

• Remove DHE and legacy ciphers (CBC/RC4).
• Keep ECDHE for forward secrecy.
• TLS 1.3 already defines secure cipher suites by default.

# Para TLS 1.2
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:
             ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
# Deixe o cliente decidir (bom para diversidade de hardware)
ssl_prefer_server_ciphers off;

0‑RTT (TLS 1.3): when to use and how to mitigate replays

0‑RTT saves a round‑trip on resumptions but allows replay. Use it only for idempotent operations like GET for static content. Never accept 0‑RTT on endpoints that change state.

The example below enables 0‑RTT and returns 425 when non‑safe methods arrive with early data. Adjust the list if you have explicit idempotent endpoints.

# Bloqueie early data em métodos não idempotentes
map "$request_method:$ssl_early_data" $early_reject {
    "~^(POST|PUT|PATCH|DELETE|OPTIONS):1$" 1;
    default 0;
}
server {
    ssl_early_data on;
    if ($early_reject) { return 425; }
}

Other quick wins: HSTS, HTTP/2 and deployment nuances

HSTS prevents HTTP→HTTPS redirects after the first visit. It doesn’t change the handshake cost, but it eliminates extra round trips. HTTP/2 multiplexes requests on a single connection and reduces new handshakes for pages with many resources.

During deployments, rotate ticket keys with overlap. Monitor stapling errors after certificate renewals. For TLS termination outside Nginx, see the HAProxy example in the HAProxy + Let's Encrypt guide and healthchecks at HAProxy + Let's Encrypt for Docker on a VPS.

• Enable HSTS carefully on primary domains.
• Plan ticket rollback windows during low traffic.
• Watch Nginx logs for OCSP and handshake errors.

# HSTS (comece com um max‑age conservador)
add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;

# HTTP/2
listen 443 ssl http2;

How to measure: handshake times, stapling and compatibility

Measure before and after. Observe appconnect with curl. Verify the OCSP stapling response is being served by the server. Check your Nginx/OpenSSL build and support. In production run tests from multiple locations and devices.

For deeper reading on TLS in Nginx and PKI, see mTLS between Nginx and services at mTLS with Nginx and smallstep in Docker Compose and the VPS security checklist at VPS Linux Security Checklist Before Go‑Live.

• Run multiple samples and discard outliers.
• Test clients with and without AES‑NI (desktop vs mobile).
• Validate that RSA fallback serves older clients.

# Tempo até appconnect (handshake concluído)
curl -sS -o /dev/null -w 'connect=%{time_connect} appconnect=%{time_appconnect}\n' https://seusite.com

# Verificar OCSP stapling
openssl s_client -connect seusite.com:443 -status < /dev/null 2>/dev/null | sed -n '/OCSP response:/,/-----END/,/-----END/p'

# Conferir build
nginx -V 2>&1 | tr ' ' '\n' | egrep 'nginx|OpenSSL'

Prioritization checklist: impact vs risk

Use this table to decide the order of changes. Start with items that yield the biggest CPU/latency improvements with low risk. Then move to items that need more testing and observability. Document a rollback plan for each step.

Frequently asked questions

Does TLS 1.3 always reduce handshake latency?

Generally yes: TLS 1.3 simplifies negotiation and can remove a round‑trip. Keep TLS 1.2 for compatibility. Real gains depend on the client, the network and how well connections and sessions are reused in your traffic profile.

Should I prioritize ChaCha20‑Poly1305 or AES‑GCM in the cipher list?

It depends on client hardware. On devices with AES‑NI, AES‑GCM is very fast. Without AES‑NI, ChaCha20 often wins. Letting the client choose is a safe default; measure against your audience to decide.

Does OCSP stapling replace the client's check with the CA?

Stapling supplies the validity proof during the handshake and reduces client queries, but the client still decides how to validate. Configure ssl_trusted_certificate and monitor OCSP updates.

Is 0‑RTT safe for APIs?

0‑RTT permits replay attacks. Avoid it for state‑changing endpoints. If you enable it, limit to idempotent methods and consider rejecting early data by default (return 425) unless explicitly allowed.

Session tickets or session cache: which to use?

Use both. Shared session cache is useful for single Nginx processes; tickets enable stateless resumption and are handy in scaled environments. Plan ticket key rotation and test compatibility after renewals.

Does HSTS reduce TLS latency?

HSTS doesn’t change the handshake cost, but it eliminates HTTP→HTTPS redirects on subsequent visits. That reduces extra round trips and improves the perceived load time after the first visit.

See also

• Practical guide: active‑passive failover between two VPS with Keepalived, HAProxy & lsyncd for synchronized uploads
• Guide: technical checklist to prepare a Debian VPS with Docker Compose for PHP apps in production
• Practical guide to VPS sizing and PHP‑FPM tuning for Magento/OpenMage stores with seasonal peaks: from sizing to load testing
• Practical guide: rebuild PostgreSQL indexes in production using CREATE INDEX CONCURRENTLY and partial indexes (safe step‑by‑step)