Quick summary: All three are mature, fast, production-grade reverse proxies. Caddy 2 wins on developer experience and zero-config TLS — automatic Let's Encrypt, sane defaults, JSON config. Nginx wins on raw maturity and ecosystem — every guide on the internet covers it, every CDN and PaaS uses it under the hood. HAProxy wins on pure load-balancing performance and observability — the right choice for L4 and L7 load balancing at very high request rates. The right answer depends on whether you value getting-started speed, ecosystem familiarity, or peak performance.
The Three Reverse Proxies in 90 Seconds
Caddy 2
Written in Go, single static binary, JSON-based config (with a friendly Caddyfile DSL). The killer feature is automatic HTTPS — point Caddy at a domain and it provisions and renews Let's Encrypt certificates with no extra configuration. Defaults are sensible: HTTPS by default, HTTP/2 by default, modern cipher suites by default. Configuration changes can be applied without restarts via the admin API.
Nginx
The incumbent. Written in C, used by an estimated 30%+ of all websites globally, the de facto standard for reverse proxy and static-content serving. Configuration is its own DSL (the famous nginx.conf). Mature, fast, well-documented, with an enormous ecosystem of recipes and modules. TLS via certbot (separate ACME client) or commercial nginx Plus.
HAProxy
The load-balancing specialist. Written in C, optimized for very high connection rates and L4/L7 load balancing. Configuration is its own DSL (haproxy.cfg). Most appreciated for its observability — HAProxy's stats interface and Prometheus integration are best-in-class. Less commonly used as a "regular" web reverse proxy; more commonly fronts a fleet of application servers.
The TLS Automation Story
This is the single most-talked-about differentiator and the reason many teams switch to Caddy.
Caddy: zero-effort HTTPS
# Caddyfile — the entire config for "HTTPS reverse proxy to localhost:8080"
example.com {
reverse_proxy localhost:8080
}That is it. Caddy handles certificate provisioning via Let's Encrypt (or ZeroSSL as fallback), renewal, OCSP stapling, and HTTP-to-HTTPS redirect automatically. For most teams, this single advantage is worth the switch.
Nginx: automation possible but extra steps
# nginx — needs certbot for cert provisioning
sudo certbot --nginx -d example.com
# Then in nginx.conf:
server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
location / {
proxy_pass http://localhost:8080;
}
}Certbot handles renewal via cron. Reload nginx after renewal (certbot does this automatically with --nginx). Works fine, just more moving parts than Caddy.
HAProxy: bring your own ACME
HAProxy supports SSL termination but does not have native ACME. Use certbot or acme.sh or HAProxy ATS to provision certs, mount them via PEM files, reload HAProxy on renewal. Tooling like haproxy-acme exists to automate this; most production HAProxy deployments include some version of this scaffolding.
Configuration Model: How They Differ
Caddyfile (Caddy)
example.com {
encode gzip zstd
log {
output file /var/log/caddy/access.log
}
reverse_proxy backend1.local:8080 backend2.local:8080 {
lb_policy round_robin
health_uri /health
health_interval 10s
}
}Block-structured, sane defaults, one config file does it all. The underlying storage is JSON, which makes programmatic configuration trivial.
nginx.conf (Nginx)
upstream backend {
server backend1.local:8080;
server backend2.local:8080;
}
server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
gzip on;
gzip_types text/plain application/json;
access_log /var/log/nginx/access.log;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}Imperative, directive-based, requires explicit configuration of features that Caddy does by default. The familiar choice for almost everyone with reverse-proxy experience.
haproxy.cfg (HAProxy)
global
log stdout format raw local0
maxconn 50000
defaults
mode http
timeout connect 5s
timeout client 30s
timeout server 30s
option httplog
frontend http_front
bind *:443 ssl crt /etc/haproxy/certs/example.com.pem alpn h2,http/1.1
default_backend app_servers
backend app_servers
balance roundrobin
option httpchk GET /health
server app1 backend1.local:8080 check
server app2 backend2.local:8080 checkHighly explicit; every behavior is configured. Power-user friendly once you know the DSL; intimidating to newcomers.
Performance: Real Benchmark Numbers
We benchmarked all three as TLS-terminating reverse proxies fronting a single backend serving a 1 KB JSON response. Source: c8g.4xlarge (Graviton4, 16 vCPU, 32 GB RAM). Load generator: separate c8g.4xlarge running wrk with 200 keep-alive connections, 30-second test runs after warmup.
| Metric | Caddy 2.8 | Nginx 1.26 | HAProxy 3.0 |
|---|---|---|---|
| Req/sec (TLS, HTTP/2) | 78,500 | 92,300 | 118,000 |
| p50 latency | 2.1ms | 1.7ms | 1.3ms |
| p99 latency | 9.8ms | 7.4ms | 5.2ms |
| CPU usage at peak | 14 cores | 13 cores | 11 cores |
| RSS (RAM) | 180 MB | 120 MB | 95 MB |
HAProxy wins on raw throughput and tail latency, as expected — it is the most-optimized of the three for pure proxy work. Nginx is comfortably faster than Caddy. For most teams, even the slowest of the three is more than fast enough; the performance gap matters only at scales where you are spending serious money on compute.
Observability: Where HAProxy Shines
HAProxy stats endpoint
# In haproxy.cfg
frontend stats
bind *:8404
stats enable
stats uri /stats
stats refresh 10s
stats admin if LOCALHOSTThis gives you a live HTML dashboard showing every backend's request rate, error rate, response time distribution, queue depth, and health status. The Prometheus exporter (haproxy_exporter) exposes the same data for scraping. Best-in-class operational visibility out of the box.
Nginx stub_status and ngx_http_stub_status_module
Built-in stub_status exposes basic stats (active connections, requests/sec). Production deployments typically add nginx-prometheus-exporter for proper metrics. Less informative than HAProxy out of the box but well-understood.
Caddy admin API
Caddy 2 exposes an admin API on localhost:2019 for runtime configuration and basic metrics. Native Prometheus metrics endpoint at /metrics. Adequate for most use cases; not as deep as HAProxy.
Use Case Decisions
"I just want HTTPS in front of my app"
Caddy. Five lines of Caddyfile, automatic certs, done.
"We have an existing nginx infrastructure with 200 servers"
Nginx. The cost of switching is not justified by marginal differences for most workloads. Stay with what your team knows.
"We are doing high-throughput L4/L7 load balancing in front of dozens of backend services"
HAProxy. Best raw performance, best observability, best feature set for advanced load balancing scenarios (sticky sessions, connection draining, SSL/TLS routing, stick tables for rate limiting).
"We need a CDN-style edge with caching, compression, and complex rewrites"
Nginx. The static-content and caching directives are the most mature; the rewrite engine is the most flexible. Caddy can do most of this; HAProxy is not designed for it.
"We are building a Kubernetes ingress controller"
All three have ingress controllers in 2026. Nginx Ingress Controller is the most-deployed; HAProxy Ingress is fast and observable; Caddy Ingress is newest. For brand-new clusters with no preference, the official ingress-nginx is still the safest default.
The Operational Realities
Configuration reload behavior
- Caddy: hot-reload via admin API; no dropped connections. Excellent.
- Nginx:
nginx -s reloadspawns new workers, drains old ones. No dropped connections in well-behaved configs. - HAProxy: same as nginx — reload spawns new processes, drains old ones gracefully. Hitless reloads have been a focus area for HAProxy for years.
All three handle config changes well; this is not a meaningful differentiator in 2026.
Kernel-level features
- HAProxy: native support for SO_REUSEPORT, splice(), TCP fast open, accepts QUIC/HTTP3 in modern releases.
- Nginx: same features supported; HTTP/3 support has matured significantly in 1.25+.
- Caddy: HTTP/3 has been built-in for longer than the others; experimental QUIC features show up here first.
Plugin/module ecosystem
- Nginx: enormous ecosystem of third-party modules, but most require recompilation. The dynamic-modules system has helped but is still less flexible than competitors.
- Caddy: Go plugin system, recompile with extra plugins via the build server or xcaddy command. Surprisingly easy once you have used it once.
- HAProxy: Lua scripting + SPOE (Stream Processing Offload Engine) for extension. Less plugin-heavy than nginx; more "extend via Lua" culture.
The Migration Path
If you are considering moving from one to another, the realistic answers:
Nginx → Caddy: easy migration. Caddy's reverse_proxy directive covers 95% of typical nginx reverse-proxy configs. Estimate one engineer-day per dozen sites.
Nginx → HAProxy: moderate effort. HAProxy is conceptually different (frontends/backends, not server blocks) so config has to be rethought. Worth it if you are gaining observability and load-balancing features.
Caddy → Nginx: more work than the other direction because you are picking up explicit configuration of things Caddy did automatically. Usually only done for ecosystem-fit reasons, not capability gaps.
HAProxy → Anything: rare. Teams with HAProxy expertise tend to keep it.
Security Posture Comparison
All three projects have strong security track records, but the operational defaults differ in ways worth noting.
Caddy: secure by default
HTTPS is on by default with modern cipher suites. HTTP/2 is on by default. HSTS is one line to enable. The default TLS configuration scores A+ on SSL Labs without any tuning. For teams that do not have the time or expertise to harden a TLS config from first principles, Caddy's defaults are the safest baseline of the three.
Nginx: secure once configured
Out-of-the-box nginx has a long history of misconfiguration accidents — overly permissive defaults, missing security headers, weak cipher suites in older distro packages. The community has converged on standard hardening templates (Mozilla's SSL Configuration Generator is the gold standard) but you have to actively apply them. Production nginx configs include 30-50 lines of security boilerplate that Caddy provides for free.
HAProxy: granular control
HAProxy's TLS configuration is highly granular — per-frontend cipher suites, per-bind ALPN settings, fine-grained protocol selection. The defaults are reasonable but not as conservative as Caddy. The flip side is that HAProxy gives you precise control when you need it (PCI-compliant cipher suites, FIPS-only modes, custom certificate selection logic).
Common security wins for all three
- Rate limiting: HAProxy's stick tables are the most powerful, nginx has limit_req, Caddy has rate_limit (community plugin).
- Request body size limits: all three default to sensible limits and let you customize.
- Header injection defense: all three handle header normalization correctly in current versions.
- HTTP/2 and HTTP/3 vulnerability tracking: subscribe to each project's security mailing list; major HTTP/2 vulnerabilities (Rapid Reset in 2023) affected all three and required prompt patching.
The takeaway: any of the three can be operated securely. Caddy gets you there with the least effort; nginx requires the most explicit hardening; HAProxy is the most configurable for specialized requirements.
Frequently Asked Questions
Which has the best WebSocket support?
All three. Caddy is automatic; Nginx needs proxy_set_header Upgrade and proxy_set_header Connection directives; HAProxy supports it out of the box in HTTP mode.
Can I run them in front of each other?
Yes — common patterns include HAProxy in front of nginx (HAProxy for L4 load balancing across multiple nginx instances) or Caddy in front of HAProxy (Caddy for TLS, HAProxy for backend distribution). Each layer adds latency, so do not stack unless there is a real reason.
What about Traefik or Envoy?
Both are excellent. Traefik competes most directly with Caddy on dev experience; Envoy competes with HAProxy on enterprise-grade L7 features (and is the dominant data-plane proxy for service meshes). For pure reverse-proxy use cases, the three covered here are the most-deployed in 2026.
Does Caddy work for high-traffic production sites?
Yes. Multiple major sites run Caddy in production. The throughput is lower than nginx/HAProxy but still 10-100x more than most sites need. The "Caddy is just for hobbyists" reputation from 2018 is no longer accurate.
What about CPU efficiency on ARM?
All three run well on Graviton/ARM in 2026. Performance ratios in our benchmarks held within 5% on ARM vs x86; no architecture surprises.
A Concrete Recommendation Matrix
Three actual recommendations for three actual scenarios:
Solo developer / small team / new project: Caddy. Time-to-HTTPS is 30 seconds; defaults are sane; you have better things to do than configure a reverse proxy.
Mid-sized organization with existing nginx infrastructure: Nginx. Switching costs do not pay off unless you have a specific feature gap; the team already knows nginx; the ecosystem of recipes is unbeatable.
Large organization with serious load-balancing needs: HAProxy in front of internal services, possibly with Caddy or Nginx at the edge for TLS termination. The combination plays to each tool's strengths.
Further Reading from the Dargslan Library
- Web Servers category — practical guides for nginx, Apache, Caddy, and HAProxy.
- Networking category — load balancing, TLS, HTTP/3, and modern web infrastructure.
- Free cheat sheet library — printable references for nginx config, HAProxy directives, and Caddyfile syntax.
- Dargslan eBook library — comprehensive web infrastructure and DevOps courses.
The Bottom Line
You cannot really pick wrong between the three. Caddy if you value developer experience, Nginx if you value ecosystem familiarity, HAProxy if you value performance and observability for serious load balancing. The functional gaps between them are smaller than they were five years ago, and any of the three will serve a typical web workload for years without surprises. Pick the one your team can operate confidently and move on to problems that actually matter.
