A reverse proxy bottleneck happens when your proxy, like Nginx or HAProxy, hits a hard throughput limit before your app does, commonly from TLS work, buffering behavior, or upstream constraints. On a Dedicated Server, this is especially visible because you control the full stack and can compare proxy and backend capacity directly.

In this guide from PerLod Hosting, you will learn how reverse proxies become throughput bottlenecks due to TLS, buffering, or backend limits, and how to detect and fix them safely.

Symptoms of Reverse Proxy Bottleneck

A reverse proxy bottleneck leaves a clear footprint on your system metrics. If your Dedicated server has powerful backends that are sitting idle while users experience delays, the problem is likely at the traffic management layer.

You will see a reverse proxy bottleneck when these patterns happen together:

• The proxy CPU is high while backends are idle.
• High request Latency under load.
• Also, increasing backend capacity doesn’t help throughput.

You can use the following commands to confirm the proxy hits the limit and see where it saturates.

1) For a fast health check under load, you can use the following ss command:

ss -s

It displays the socket summary, which is useful when you have many sockets during a load test.

2) Find listening TCP sockets with the command below and watch for accept queues and backlog pressure:

ss -ltnp

This helps detect growing queues that represent the proxy can’t accept process connections quickly enough.

3) Look for short-lived upstream TCP connections with the command below:

ss -tn state established

• If connection counts and queues grow mainly on the proxy side, the proxy is the bottleneck, not the backend.
• If CPU spikes on the proxy during HTTPS load, TLS termination is likely the bottleneck.

Tip: Before starting proxy-specific configurations, ensure your hardware is configured to handle the load by reviewing our Best Tips For Tuning High Traffic Dedicated Servers.

Why Your Proxy Slows Down: TLS, Buffering, and Connection Limits

To improve the throughput of your server, you must find the root causes. Most reverse proxy bottlenecks happen because of TLS termination, memory buffering, or the overhead of managing upstream connections.

TLS termination: TLS termination can cap throughput because each handshake, encryption, and decryption cycle consumes CPU, and performance improves when clients can resume sessions.

Buffering: Buffering can become a bottleneck when your proxy’s response buffers are too small or mis-sized, which forces inefficient buffering behavior per connection. For example, Nginx uses proxy_buffers to read data from the backend, but the default size, 4K or 8K, is frequently insufficient.

Backend limits: When the proxy can’t efficiently reuse upstream connections or when upstream capacity is lower than what the proxy can accept, these can cause a proxy bottleneck. For HTTP upstream keepalive, NGINX documents that you should set proxy_http_version to 1.1 or 2 and clear the Connection header to enable keepalive to upstream servers.

Now that you have discovered the symptoms and root causes of the reverse proxy bottleneck, you can proceed to the next step to apply the best fixes and optimizations.

Fix Reverse Proxy Bottleneck: Tuning TLS, Buffers, and Keepalives

At this point, you can optimize the TLS, Buffers, and Keepalives configurations for max throughput and fix the reverse proxy bottleneck.

Reduce TLS overhead

You can enable the TLS session reuse so repeat clients can avoid expensive full handshakes. Using a shared session cache reduces overhead and improves performance.

For example, for Nginx:

server {
  listen 443 ssl;

  # Shared cache across workers (reduces full handshakes on repeat connections)
  ssl_session_cache shared:SSL:20m;
  ssl_session_timeout 4h;
}

Configure Upstream Keepalive

You must configure upstream keepalive correctly so the proxy reuses TCP connections to backends instead of opening new ones repeatedly.

Example for Nginx:

upstream app_backend {
  server 127.0.0.1:8080;
  keepalive 64;
}

server {
  location / {
    proxy_pass http://app_backend;

    # Required to make upstream keepalive work properly for HTTP
    proxy_http_version 1.1;
    proxy_set_header Connection "";
  }
}

Size Proxy Buffers Correctly

Size proxy buffers to match your typical response sizes and concurrency, and avoid invalid combinations.

Nginx uses proxy_buffers and proxy_busy_buffers_size. The proxy_busy_buffers_size must be less than the total proxy_buffers space minus one buffer.

location / {
  proxy_pass http://app_backend;

  proxy_buffer_size 8k;
  proxy_buffers 8 8k;
  proxy_busy_buffers_size 16k;
}

The proxy_buffers sets the memory used to read backend responses. You must limit proxy_busy_buffers_size relative to your total buffer count to prevent configuration and buffering errors.

Prevent Queue Saturation

If the proxy can’t accept fast enough under load, you must check the kernel backlogs. Linux uses somaxconn as the limit of the socket listen() backlog and tcp_max_syn_backlog as the max remembered half-open requests.​

Check current values with the command below:

sysctl net.core.somaxconn net.ipv4.tcp_max_syn_backlog

For example, change the values like this and then reboot:

sudo sysctl -w net.core.somaxconn=4096
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=8192

These sysctls directly affect how many incoming connections can queue before your application accepts them, and increasing them is a common mitigation when a server suffers from overload.

Tip: For more detailed analysis of system-wide limits, including advanced sysctl parameters and BBR congestion control, you can check this guide on Best Linux Kernel Network Tuning.

Benchmark Reverse Proxy Bottleneck

By benchmarking your Dedicated server backend directly and comparing it to the proxy, you can determine if the traffic layer is capping your performance.

You can use the wrk command:

# Backend direct (HTTP example)
wrk -t4 -c200 -d30s http://BACKEND_IP:8080/

# Through reverse proxy (HTTPS example)
wrk -t4 -c200 -d30s https://PROXY_DOMAIN/

In wrk, -t is threads, -c is open connections, and -d is benchmark duration; keeping these identical makes the comparison meaningful.

While the test runs, watch the socket pressure with the command below:

watch -n1 'ss -s'

This provides a summary of socket states, which helps you find throughput drops with connection queue pressure during the load window.

FAQs

Conclusion

A reverse proxy bottleneck usually comes from these main causes, including TLS overhead, buffering issues, or backend connection limits. To fix them safely, first confirm the problem by testing your backend directly versus through the proxy. Then, apply fixes like enabling TLS session reuse or tuning buffers, and retest after each step. If throughput improves and latency drops, you’ve solved it; if not, undo the change and try the next solution.

We hope you enjoy this guide. Subscribe to our X and Facebook channels to get the latest articles and updates.

For further reading:

High-Performance Reverse Proxy Setup with HAProxy

NVMe Optimization for Linux Servers