$ guides / traefik / traefik-tls-handshake-latency ▌

Operations Guides

Traefik TLS handshake latency: RSA cost, session resumption, and CPU

Clients report slow first page loads or high connect times, but backend latency looks fine and error rates are flat. When the delay shows up before the first byte of the request is processed, the TLS handshake at the Traefik entrypoint is the prime suspect.

Handshakes are the largest per-connection CPU cost for a terminating proxy, and they add latency to every new connection before any routing, middleware, or backend work happens. Traefik exposes no dedicated handshake-latency metric, so you have to infer it from latency decomposition and process CPU.

This guide covers how to confirm the symptom, the three causes that account for almost every case (certificate key type, session resumption rate, TLS version mix), and what to change.

What this means

A full TLS handshake involves asymmetric cryptography on the server: with an RSA certificate, Traefik performs an RSA private-key operation per full handshake; with ECDSA, an ECDSA signature. RSA 2048 signing is roughly 10-20x more expensive than ECDSA P-256. On top of the crypto, TLS 1.2 costs two round trips before the client can send a request, while TLS 1.3 costs one.

Two mechanisms avoid paying full price repeatedly:

Session resumption (tickets or session IDs) lets a returning client skip the asymmetric operation and most of the round trips. A low resumption rate means every connection pays full handshake cost.
TLS 1.3 saves a round trip versus TLS 1.2 even for full handshakes, and resumed TLS 1.3 connections are cheaper still.

When handshakes can’t keep up, CPU saturates, handshakes queue, and connect latency climbs. The signature pattern: handshake time spiking alongside Traefik process CPU means the box is crypto-bound. Handshake time spiking while CPU is idle points elsewhere (certificate chain size, client-side negotiation fallback, network RTT).

Common causes

Cause	What it looks like	First thing to check
RSA certificate under high new-connection rate	CPU dominated by crypto, handshake latency scaling with connection rate	Certificate key type: `openssl s_client` and inspect the cert
Low session resumption rate	Every connection pays full cost; CPU high even with mostly returning clients	TLS 1.3 vs 1.2 mix in `traefik_entrypoint_requests_tls_total`; `disableSessionTickets` setting
Mostly TLS 1.2 clients	Extra round trip on every connection, higher baseline handshake latency	`tls_version` label distribution on the TLS request counter
Multi-instance deployment without shared ticket keys	Resumption works against one pod, fails against others; effective resumption rate collapses	Number of Traefik replicas behind the load balancer
Overly broad curve preferences	Handshake CPU roughly doubled without any visible misconfiguration error	`curvePreferences` in TLS options

Quick checks

# Measure TLS handshake time directly from a client.
# time_appconnect - time_connect = TLS handshake duration.
curl -w "time_appconnect: %{time_appconnect}\ntime_connect: %{time_connect}\n" \
  -o /dev/null -s https://your-traefik-host/

# Inspect the served certificate's key type and chain length.
echo | openssl s_client -servername your.domain.com -connect your-traefik-host:443 2>/dev/null | \
  openssl x509 -noout -text | grep -E 'Public Key Algorithm|Public-Key'

# TLS version and cipher distribution actually being negotiated.
# Adjust host/port to wherever your metrics entrypoint listens.
curl -s http://localhost:8080/metrics | grep traefik_entrypoint_requests_tls_total

# Process CPU (rate this counter over a minute).
curl -s http://localhost:8080/metrics | grep process_cpu_seconds_total

# Entrypoint vs service duration, to isolate Traefik-side overhead.
curl -s http://localhost:8080/metrics | grep traefik_entrypoint_request_duration_seconds
curl -s http://localhost:8080/metrics | grep traefik_service_request_duration_seconds

Reference points for curl timing from a same-datacenter client: under ~10ms of handshake time is normal, consistently above ~50ms is concerning, and a sudden 3x jump from baseline warrants investigation regardless of absolute value. Internet clients are variable; compare against your own baseline, not a fixed number.

How to diagnose it

Confirm the latency is in the handshake, not the backend. Compare traefik_entrypoint_request_duration_seconds with traefik_service_request_duration_seconds. If entrypoint latency is elevated while service latency is normal, the overhead is on Traefik’s side: TLS, middleware, or connection handling. If both are elevated, you have a backend problem instead; see the 504 guide linked below.
Confirm with an external probe. Run the curl -w timing check from a client that sees the symptom. time_appconnect - time_connect is the handshake. If that delta is large while time_starttransfer - time_appconnect (server processing after handshake) is small, the handshake is the cost.
Check whether CPU is the constraint. Rate process_cpu_seconds_total and compare with the rate of traefik_entrypoint_requests_tls_total. CPU climbing in lockstep with new TLS session rate is the crypto-bound signature. If CPU is saturated and dominated by TLS, you are at the hardware limit for this configuration.
Identify the certificate key type. RSA certs make every full handshake expensive. If the cert is RSA 2048 (or worse, 4096), that is your primary lever.
Estimate resumption effectiveness. Traefik does not expose a resumption-rate metric directly. Indirect evidence: if your traffic is dominated by returning clients (browsers, API clients that reconnect instead of using keep-alive) yet CPU per connection stays at full-handshake levels, resumption is not working. Check for disableSessionTickets: true in TLS options, and count your replicas.

flowchart TD
  A[Slow connects reported] --> B{curl time_appconnect - time_connect high?}
  B -- No --> C[Not a handshake problem - check backend or network]
  B -- Yes --> D{Traefik CPU high and tracking TLS session rate?}
  D -- Yes --> E[Crypto-bound]
  E --> F{RSA cert?}
  F -- Yes --> G[Switch to ECDSA cert]
  F -- No --> H{Resumption broken?}
  H -- Yes --> I[Fix tickets / replica topology]
  H -- No --> J[Scale horizontally or offload TLS]
  D -- No --> K[Check cert chain size, client negotiation fallback, RTT]

Metrics and signals to monitor

Signal	Why it matters	Warning sign
`process_cpu_seconds_total` (rate)	TLS handshake computation dominates Traefik CPU	Rising in lockstep with new TLS session rate
`traefik_entrypoint_requests_tls_total` by `tls_version`	Shows the 1.2 vs 1.3 mix, which sets the round-trip floor	Large TLS 1.0/1.1 share (security issue) or unexpected 1.2 dominance
`traefik_entrypoint_requests_tls_total` by `tls_cipher`	Cipher distribution; weak or unusual ciphers stand out	Sudden shift in cipher mix without a config change
`traefik_entrypoint_request_duration_seconds` vs `traefik_service_request_duration_seconds`	The gap is Traefik-side overhead: TLS plus middleware	Gap grows while service latency stays flat
External probe: `time_appconnect - time_connect`	Only direct handshake measurement available	p50 handshake time 3x above baseline
`traefik_open_connections`	New-connection churn drives handshake load	Connections churning fast (short-lived clients) with high CPU

Fixes

Switch from RSA to an ECDSA certificate

This is the single largest win. ECDSA P-256 signing is roughly 10-20x cheaper than RSA 2048, which directly cuts per-handshake CPU and latency. With ACME (Let’s Encrypt), request an ECDSA cert via the resolver’s key type setting; with static certs, issue an ECDSA certificate from your CA. Tradeoff: very old clients may lack ECDSA cipher suite support. If you must serve both, some deployments run RSA and ECDSA certs side by side and let the client negotiate, but verify client compatibility before removing RSA entirely. With an EC certificate, TLS 1.2 clients can fail to negotiate if no ECDSA-capable cipher suites are configured for 1.2; test with a TLS 1.2 client before rolling out.

Restore session resumption

Session tickets are enabled by default. The disableSessionTickets TLS option, introduced in v3.4, exists for strict forward-secrecy requirements and forces a full handshake on every connection. If it is set to true and you don’t have a compliance reason for it, remove it.

The harder case is multi-instance deployments. Traefik supports session tickets only (no session-ID cache), and there is no Traefik mechanism to configure or synchronize ticket keys across instances (upstream enhancement issue #4550 remains open). Ticket keys use the Go crypto/tls default key-generation/rotation path, so a ticket issued by pod A cannot be resumed by pod B. Behind a load balancer with N replicas, most resumption attempts fail. Mitigations:

Use client affinity at the load balancer so returning clients hit the same replica (partial fix, breaks on pod churn).
Reduce replica count where capacity allows, or accept the full-handshake cost and compensate with ECDSA certs and horizontal scale.
If clients hold connections (HTTP/2, keep-alive), resumption matters less; the cost is per connection, not per request.

Let TLS 1.3 do its work

TLS 1.3 saves a round trip over 1.2 and Traefik negotiates it by default when the client supports it. Don’t cap maxVersion at 1.2. TLS 1.3 cipher suites are not configurable in Traefik (they come from Go’s crypto/tls), and Traefik does not support 0-RTT, so the 1.3 gain is the round-trip reduction, not early data. If the tls_version label shows a large 1.2 share, the cause is almost always the client population, not Traefik; check for a legacy client you can upgrade.

Check curve preferences

Explicitly setting curvePreferences with CurveP521 first roughly doubles handshake CPU cost compared to P-384 or auto-negotiation, per community reports under high concurrency. Prefer X25519 and P-256, or leave the setting unset unless you have a specific requirement.

Scale or offload

If the certificate is already ECDSA, resumption is as good as it can be, and CPU is still saturated by handshakes, you are at hardware capacity. Options: add replicas (accepting the resumption penalty above), or terminate TLS at an upstream layer (cloud load balancer or CDN) and run plain HTTP or lighter TLS between that layer and Traefik. Offloading moves the problem rather than removing it, but dedicated TLS termination at a CDN edge is often cheaper than scaling proxy pods.

Prevention

Baseline handshake latency. Run the curl -w probe on a schedule from a fixed location and alert on deviation from your own baseline, not a static threshold.
Watch CPU against TLS session rate. The ratio of process_cpu_seconds_total rate to traefik_entrypoint_requests_tls_total rate is your cost-per-handshake. A rising ratio after a cert renewal or config change means someone shipped an RSA cert or disabled resumption.
Pin certificate key type in automation. If ACME or your internal CA issues certs, fix the key type to ECDSA in the issuing configuration so a re-issue doesn’t silently revert to RSA.
Track TLS version distribution via traefik_entrypoint_requests_tls_total. It tells you both your security posture and your round-trip floor.

How Netdata helps

Netdata charts process_cpu_seconds_total as per-second CPU usage next to Traefik’s entrypoint request and TLS counters, so the crypto-bound signature (CPU tracking new TLS sessions) is visible in one view without manual correlation.
The latency decomposition this guide relies on, entrypoint duration versus service duration, is charted side by side per entrypoint and per service, making Traefik-side overhead obvious when backend latency is flat.
TLS version and cipher distribution from traefik_entrypoint_requests_tls_total is broken out by label, so a shift toward TLS 1.2 or a resumption-breaking config change shows up as a visible distribution change.
Anomaly detection on CPU and connect-rate metrics flags a handshake-cost regression (for example after a certificate re-issue) even when absolute utilization stays below static alert thresholds.