HAProxy vs. NGINX

Doba čtení: 16 minut

 Tak nějak obecně 🙂

HAProxy

• Primárně L4/L7 load balancer a reverse proxy s extrémním důrazem na spolehlivost, predikovatelné latence a pokročilé řízení provozu (ACL, stick-tables, retry/redispatch, health-checky).
• Silné stránky: přesné L7 routování, rate limiting a connection limiting, stick tables (sledování stavů/počítadel na klientech/URL), seamless reload/zero-downtime (master-worker, přenos soketů), velmi bohaté balancer algoritmy, observabilita.
• Slabé stránky: nativně neobsahuje plnohodnotný response cache jako NGINX (má jen omezené cache/HTX features), menší „webserverová“ výbava.

NGINX (open source / plus / unit)

• Původně HTTP server s vynikajícím statickým výkonem, dnes i reverse proxy a L7 balancer. Má silnou HTTP cache, modulární ekosystém, podporu mail proxy, stream (TCP/UDP), njs, a v dlouhodobém horizontu i HTTP/3/QUIC.
• Silné stránky: proxy_cache (včetně stale-if-error), velmi rychlé podávání statik, flexibilní architektura (master–worker), bohaté moduly (limit_req, map, sub_filter, realip, geo).
• Slabé stránky: složitější bezvýpadkový reload v některých scénářích (long-lived connections), méně specializovaných L7 LB funkcí než HAProxy (např. stick tables jsou v HAProxy výrazně vyspělejší).

Objektivní volba v kostce

• Potřebuji hyper-precizní L7 balancování, ochrany, limity a observabilitu: HAProxy.
• Potřebuji reverse proxy + webserver + robustní cache a podávání statiky: NGINX.
• Kubernetes Ingress / API Gateway: obě mají kvalitní Ingress controllery; volba podle požadovaných funkcí (rate-limit/stick-table vs. cache/caching tiers) a preferencí týmu.
• HTTP/3/QUIC na edge: obě podporují; výběr závisí na maturity/perf v konkrétních verzích a na feature setu okolo.

Historie a kontext vzniku

HAProxy

• Zrozeno v prostředí high-load webů (okolo 2000+) s cílem poskytnout extrémně rychlý a spolehlivý L4/L7 load balancer.
• Filosofie: determinismus, nízké latence, predikovatelné chování, extrémní stabilita pod tlakem (slowloris, SYN flood, connection floods).

NGINX

• Vznikl jako reakce na problém C10k (obsluha desítek tisíc paralelních spojení) — event-driven architektura pro HTTP server.
• Filosofie: rychlý HTTP server a reverse proxy, jednoduchý master–worker model, minimální paměťová stopa na spojení, vysoký výkon na statické soubory a proxying.

Dnes se oba projekty do značné míry překrývají v reverse proxy a balancování, ale DNA si drží: HAProxy = balancer & traffic brain, NGINX = webserver & reverse proxy & cache.

Architektura a model zpracování

Procesy a vlákna

• NGINX: master proces spravuje několik worker procesů (typicky 1–CPU). Každý worker je event-loop (epoll/kqueue). Reload (HUP) spustí nové workery, staré doběhnou. Dlouhé TCP/HTTP/WS/GRPC spojení mohou oddálit uvolnění starých workerů.
• HAProxy: dříve single-process event loop, dnes master–worker model, více procesů a/nebo vláken. Umí seamless reload s převzetím naslouchajících soketů a běžících spojení novými workery.

 Síťové I/O, buffery, backpressure

• Oba využívají jádrové event mechaniky (epoll/kqueue). HAProxy klade důraz na jemné řízení backpressure, limitů a front, což se hodí u API s proměnlivou latencí. NGINX exceluje v sendfile, AIO a efektivním podávání statiky.

L4 vs. L7

• L4 (TCP/UDP): Oba umí (NGINX v bloku stream {}, HAProxy přes mode tcp + UDP podpora v novějších verzích).
• L7 (HTTP): Oba jsou silní. HAProxy má bohaté ACL syntaxe, stick tables, http-request/http-response pravidla, vynikající retry/redispatch. NGINX nabízí bohaté moduly (map, try_files, proxy_cache, sub_filter, headers_more aj.).

Protokoly a moderní web

• TLS: obě zvládají moderní TLS (SNI, OCSP stapling, session resumption, preferované šifry). HAProxy má detailní TLS parametry na frontend/backendech, NGINX zase širokou podporu modulů a snadnou integraci s ACME (certbot, lego, atd.).
• HTTP/2: podporováno oběma; pozor na prioritu streamů a ladění windowing u gRPC.
• HTTP/3/QUIC: podporováno v nových verzích obou; nasazení obvykle na edge, s fallbackem na H2/H1.
• WebSocket: obě zvládají (upgrade/connection headers).
• gRPC: obě zvládnou L7 routovat; v NGINX pozor na grpc_pass vs grpc_web, v HAProxy pečlivé timeouty a option http-buffer-request u některých workflow.
• Mail proxy: NGINX má nativní SMTP/IMAP/POP3 proxy; HAProxy lze použít na L4, ale nemá dedikovaný mail-proxy stack.

Load-balancing algoritmy a session sticky

Běžné algoritmy: roundrobin, leastconn, source/ip_hash, random, hash na klíč (cookie, URL, header), consistent hashing.

• HAProxy: velmi bohatá sada — leastconn, first, source, uri, hdr, rdp-cookie, static-rr, váhy, dynamické váhy, consistent hashing s granularitou, rozšířená kontrola přes stick-table a balance ... direktivy.
• NGINX: open-source edice: round_robin (implicitně), least_conn, ip_hash, hash (na libovolný klíč). Komerční Plus přidává další.

Session sticky

• HAProxy: cookie sticky + stick tables – lze trackovat IP, cookie, headers, path, spojovat s rate-limit, ban/greylist.
• NGINX: sticky přes ip_hash nebo modulární přístup (hash na cookie/header). V open-source méně „stateful“ feature setu než v HAProxy.

Health-checky, obnova a odolnost

• HAProxy: pokročilé active checks (HTTP, TCP, SSL hello), agent-check, http-check send/expect, on-marked-down ..., rise/fall prahy, out-of-band server-state soubory, server-template, dynamic backendy.
• NGINX: v open-source základní pass-through (považován za up, dokud socket přijímá). Aktivní HTTP health-checky jsou komfortní v NGINX Plus; v OSS lze obejít přes třetí strany či externí checkery s fail_timeout, max_fails.

Observabilita, logování, metriky

• Logy: oba podporují detailní logformáty. HAProxy má HTX/HTTP log s mnoha poli (Tq, Tw, Tc, Tr, Tt, status, captured headers), NGINX má log_format s proměnnými ($request_time, $upstream_response_time, …).
• Stats/UI: HAProxy má stats socket a stats uri (web UI), NGINX má stavové endpointy (stub_status, v Plus rozšířené API).
• Prometheus: exportéry existují pro oba (HAProxy exporter, NGINX/nginx-vts/nginx-prometheus-exporter), v K8s standard.

Bezvýpadkové reloady a nasazování

• HAProxy: seamless reload – nový proces převezme naslouchací sokety a běžící spojení. V praxi velmi blízko zero-downtime i s long-lived spojeními.
• NGINX: reload přes HUP; nové workery dostanou sokety, staré doběhají. Long-lived spojení (např. WS) mohou držet staré workery déle; lze řešit worker_shutdown_timeout, drain strategie, phased reload, případně vnější connection draining (LB před NGINXem).

Caching a akcelerace

• NGINX: plnohodnotná proxy_cache (disk, cache_valid, stale-if-error, cache_purge – modul), ETag/If-Modified-Since, gzip, brotli (modul), sendfile, aio.
• HAProxy: nemá ekvivalent robustní response cache jako NGINX. Umí však header normalization, small object tuning, HTX transformace, kompresi (compression algo gzip), cache pro malé objekty se v minulosti objevila v omezené formě — typicky se však HAProxy páruje s Varnish/NGINX, pokud je cache klíčová.

Bezpečnostní funkce a WAF

• Rate/conn limiting:
  • HAProxy: stick tables + http-request deny/allow if { sc_http_req_rate gt X }, granularita per IP/cookie/URL.
  • NGINX: limit_req_zone (token bucket), limit_conn_zone, geo/map pro segmentaci.
• WAF:
  • NGINX: ModSecurity v kombinaci (OSS/Plus), NAXSI (alternativa), komerční WAF integrace.
  • HAProxy: SPOE (Stream Processing Offload Engine) k integraci ModSecurity/externích inspektorů, komerční WAF produkty s HAProxy před/drain.
• DDoS/L7 flood: oba umí connection throttling, time-outy, header/body limity, reqdeny/deny. HAProxy se často volí jako první „brána“ kvůli velmi jemným ACL a statistikám.

Typické vzory nasazení

1. Edge TLS terminace + L7 routing
   • HAProxy: detailní ACL (Host/Path/Headers, SNI), SNI multi‑cert, preferováno u API s náročnou kontrolou provozu.
   • NGINX: kdykoliv chcete zároveň cache statiky/dynamic HTML, nebo potřebujete rewriting a webserverové featury.
2. API Gateway
   • HAProxy: pokročilé limity, retry/backoff, per‑route pravidla, gRPC/H2, precise timeouts.
   • NGINX: open-source + njs (skriptování) + cache; NGINX Plus přidá bohaté upstream features.
3. Kubernetes Ingress
   • Obě mají stabilní controllery; volba často dle požadovaného rate-limit/stick-table vs. cache/features a týmu.
4. Statika + CDN origin
   • NGINX vítězí díky sendfile/AIO/cache; HAProxy může být předřazen jako L7 shield a rate-limiter.
5. Mail proxy / STARTTLS
   • NGINX má přímo SMTP/IMAP proxy; HAProxy řeší L4 (TCP) vrstvě.

Výkonové ladění (Linux)

• Kernel: net.core.somaxconn, net.ipv4.ip_local_port_range, net.core.rmem_max/wmem_max, tcp_tw_reuse (moderní jádra), tcp_fin_timeout, fs.file-max.
• Ulimit: nofile (100k–1M dle potřeby), nproc.
• TLS: session reuse, preferované křivky (X25519), OCSP stapling, ssl_session_tickets (rotace), ssl_buffer_size (NGINX) – opatrně.
• HAProxy: tune.bufsize, maxconn, pečlivé timeouty (client, server, http-keep-alive, http-request), nbthread, cpu-map.
• NGINX: worker_processes auto;, worker_connections, multi_accept off, keepalive_timeout, sendfile on; aio on;, proxy_buffering (zap/vyp dle použití), proxy_busy_buffers_size.

Konfigurační příklady (prakticky)

Pozn.: hodnoty jsou ilustrativní; dolaďte pro své prostředí.

HAProxy — jednoduchá TLS terminace + L7 routing podle Host

NGINX — reverse proxy s cache (stale-if-error) a HTTP/2

HAProxy — rate limiting s stick tables (per IP)

NGINX — limit_req (token bucket) na /api/

HAProxy gRPC (H2) — pečlivě nastavit timeouts a h2 alpn na bindu.

HLAVIČKY a „forwarded“ informace

• X-Forwarded-For/Proto/Host:
  • NGINX: proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; atd.
  • HAProxy: option forwardfor if-none, http-request set-header X-Forwarded-Proto https.
• PROXY protocol: když je před nimi L4 LB (např. metal LB, cloud LB) a chcete zachovat klientskou IP. Oba podporují jako listener i upstream (soulad na obou stranách!).

HTTP/3/QUIC nasazení

• Edge pouze na H3, fallback H2/H1.
• Pozor na MTU/PMTUD, UDP buffering a firewall (QUIC běží nad UDP/443).
• Vysoké RTT a mobilní sítě z H3 benefitují (0‑RTT/connection migration), ale sledujte metriky — ne všude je H3 rychlejší.

Bezpečnostní zásady

• Striktní timeouty (read, send, headers), limity na velikosti hlaviček a těla.
• Rate limiting/blokace podle IP/cookie/AS (HAProxy stick tables, NGINX geo/map + limit moduly).
• OCSP stapling, rotace session tickets, pravidelné obnovy certifikátů.
• CORS politika na reverse proxy, aby nebyla příliš široká.
• WAF pouze tam, kde dává smysl — pečlivě měřit latence a false positives.

Kubernetes/Cloud naráz

• Ingress:
  • NGINX Ingress Controller (community) + NGINX Plus Ingress (komerční) — široká adopce, annotations, CRD (VirtualServer/VSr).
  • HAProxy Ingress: výborný výkon, bohaté L7 řízení, stick tables i v K8s světě, Prometheus metriky.
• Service mesh: Pokud již máte Istio/Linkerd/… zvažte roli L7 proxy na edge (HAProxy/NGINX) vs. Envoy uvnitř.

Kdy co zvolit – „decision matrix“

Zvolím spíše HAProxy, když:

• potřebuji jemnozrnný rate-limit/conn-limit s per‑klient/pattern evidencí (stick tables),
• chci seamless reload s minimálním rizikem odpojování long-lived spojení,
• API heavy provoz, složité L7 ACL, routing podle kombinací hlaviček, cookie, metod,
• potřebuji precizní health-checky a reakce na stavy backendů.

Zvolím spíše NGINX, když:

• chci výkonnou cache s stale-if-error a akceleraci statik,
• potřebuji zároveň webserver s rewrite, try_files, gzip/brotli, sub_filter,
• hodí se mi mail proxy nebo široký ekosystém modulů a njs skriptování,
• hledám jednoduché „vše v jednom“ pro web + reverse proxy.

Hybrid (častý vzor): HAProxy na hraně (rate-limit, shielding, SNI routing) a NGINX/Varnish za ním pro cache a webserverové funkce.

Běžné pasti a jak se jim vyhnout

• Zapomenuté X-Forwarded-Proto → zpětné generování http:// URL.
• Nesoulad PROXY protocolu mezi předním LB a backendem → spojení padá.
• Nevyvážené timeouty (client < server) → zbytečné 504/502.
• Příliš agresivní keepalive na upstreamu → přetížené backendy connection thrashingem.
• Reload v NGINX bez worker_shutdown_timeout a drainu → staré workery „visí“.
• Špatně nastavená cache key v NGINX → cache poisoning nebo nízký HIT.

Migrační poznámky (z NGINX ⇄ HAProxy)

• Headers a mapping: přepište proxy_set_header na http-request set-header / option forwardfor v HAProxy.
• Rate limit: limit_req_zone ⇄ stick tables (nutné navrhnout klíč a TTL).
• Health-checky: NGINX OSS → externí checker nebo přejít na HAProxy active checks.
• Caching: pokud odcházíte z NGINX s cache, zvažte ponechat NGINX/Varnish jako cache tier.

Minireference – často používané direktivy

HAProxy

• acl, use_backend, http-request/response, stick-table, balance, option httpchk, server-template, ssl-default-bind-options, nbthread, cpu-map, log-format.

NGINX

• proxy_pass, upstream {} s least_conn ip_hash hash, proxy_cache*, limit_req*, map, rewrite, real_ip_*, listen ... http2 quic, grpc_pass, stream {}.

Vývoj a trend do budoucna

• Konsolidace funkcí: oba projekty přidávají HTTP/3/QUIC, vylepšují observabilitu a bezpečnostní prvky.
• Edge compute a API: tlak na L7 řízení (HAProxy) a na caching/acceleration (NGINX) poroste. Hybridní architektury zůstávají pragmatickou volbou.
• Kubernetes: CRD‑based konfigurace a GitOps řízení budou standard — dbejte na konzistenci generované konfigurace a bezpečné reloady.

Rozšířené konfigurační ukázky

 HAProxy – mTLS na frontend + routování dle JWT claimu (SPOE)

Ukázka patternu: validace JWT mimo proces přes SPOE agenta a výsledné ACL.

NGINX stream (TCP) s PROXY protocol