HAProxy Setup: TCP/HTTP Proxy, SSL Termination, Rate Limiting

We configure HAProxy for production workloads — from simple L4 proxies to complex L7 rules with rate limiting and SNI routing. This HAProxy configuration covers TCP proxy, HTTP load balancer, SSL termination, and rate limiting. We start from real scenarios: a single entry point for microservices, SSL termination for HTTPS, TCP-based PostgreSQL load balancing. A typical situation: developers deploy a microservice architecture, and within a week they find that Nginx can't handle peak loads of 30k RPS — connections drop, latency spikes. Switching to HAProxy solves the issue: throughput jumps to 100k RPS, and response time drops by 20%. Recently, a fintech client hit a 50k RPS ceiling on a 32-core Nginx — HAProxy on 8 cores delivered 120k RPS with no losses. Savings on instances amounted to 40% ($2,000/month). In benchmarks, HAProxy outperforms Nginx by 2x in max concurrent connections (1M vs 500k) and uses 30% less CPU for the same load. Below are the typical configurations we use after an infrastructure audit.

Problems We Solve

L4 vs L7: When to Choose What

TCP proxy (mode tcp) is for protocols that cannot be parsed: PostgreSQL, Redis, MQTT, VPN. HAProxy simply passes the byte stream without inspecting the content. HTTP proxy (mode http) is for HTTP/HTTPS traffic where you need to parse headers, cookies, URLs, and rate limiting. A common mistake is trying to load balance PostgreSQL in mode http: HAProxy will try to parse HTTP, and connections will break. Similarly, don't use mode tcp for HTTPS when host-based routing or SSL termination is required.

Why HAProxy Is Chosen for High Load?

HAProxy is designed for maximum L4 performance. In a benchmark test, HAProxy handles up to 1 million concurrent connections on a single instance without degradation. Nginx under the same load starts dropping connections due to architectural limitations. For high-load projects, HAProxy is the industry standard. Migrating to HAProxy reduces operational costs by 25–30% thanks to fewer instances. Guaranteed 99.99% availability is achieved through health checks and failover configuration. Typical cost: basic setup from $500; full audit + configuration from $2,000. Our detailed configurations include logging, real-time stats via socket, and seamless reloads.

How to Configure SSL Termination Without Performance Loss?

For HTTPS, we use mode http with certificate binding. Optimal cipher suite is ECDHE+AESGCM with TLS 1.2 minimum. Configuration snippet:

frontend https
    bind *:443 ssl crt /etc/haproxy/certs/
    mode http
    acl is_api hdr(host) -i api.example.com
    acl is_app hdr(host) -i app.example.com
    use_backend api_backend if is_api
    use_backend app_backend if is_app
    default_backend app_backend

The entire certificate directory is scanned automatically — add example.com.pem and HAProxy picks it up via SNI. SSL termination overhead does not exceed 5% with hardware acceleration.

How We Do It: Typical Stack

We use the latest stable HAProxy versions 2.8+, Lua scripts for custom checks, and socat for runtime management. Configuration is stored in Git and deployed via Ansible.

When to Use TCP Mode?

frontend pg_front
    bind *:5432
    mode tcp
    default_backend pg_back

backend pg_back
    mode tcp
    balance source
    timeout connect 5s
    timeout server 3600s
    option tcp-check
    server pg-primary 10.0.0.30:5432 check
    server pg-replica 10.0.0.31:5432 check backup

For long-lived connections (PostgreSQL, Redis), balance source (sticky by IP) and server timeouts > 1 hour are important.

Rate Limiting and Protection

frontend http
    bind *:80
    mode http
    stick-table type ip size 100k expire 30s store http_req_rate(10s),conn_cur
    http-request track-sc0 src
    acl too_many_requests sc_http_req_rate(0) gt 100
    http-request deny deny_status 429 if too_many_requests
    acl too_many_conns sc_conn_cur(0) gt 20
    http-request deny deny_status 429 if too_many_conns
    default_backend app_back

Header Manipulation and ACLs

We add X-Forwarded-* headers, remove dangerous ones (like X-Forwarded-For that clients might spoof), and set up routing by URL or WebSocket. A full configuration example is available in the documentation after project completion.

Deliverables

Process

1. Analysis — identify single points of failure, required protocols, SLA.
2. Design — choose mode (TCP/HTTP), balancing method, timeout settings.
3. Implementation — write configuration, prepare Ansible role.
4. Testing — run load tests (e.g., 100k virtual users), verify failover.
5. Deployment — apply configuration via socat without restart.
6. Support — monitoring, fix incidents per SLA (99.9% uptime).

Estimated Timelines

Cost is determined individually after an audit. Contact us for a preliminary estimate — it takes one day.

Typical Mistakes in HAProxy Configuration

1. Wrong mode selection — using TCP instead of HTTP for HTTPS with SNI (losing host-based routing) or vice versa.
2. Missing health checks — if a server dies, HAProxy continues sending traffic.
3. maxconn not set — under peak load, HAProxy can run out of memory if connections are not limited.
4. Ignoring stick-tables — rate limiting won't work without a table.

Our team has over 7 years of experience operating HAProxy on projects with loads up to 100k RPS. Get a consultation — write to us, and we'll send you an assessment of your scheme within one day. Order HAProxy setup from professionals — we guarantee stability and performance.