Firewall Compare
Server room patch panel with structured cabling, representing reverse-proxy traffic routing
Comparisons

HAProxy vs nginx Reverse Proxy for a Home Firewall

Both OPNsense and pfSense can run a reverse proxy on the firewall itself. HAProxy and nginx solve the same homelab problem differently. A practical comparison for routing multiple internal services behind one public IP.

By Firewall Compare Editorial · · 8 min read

If you run more than one self-hosted service at home, you eventually hit the same wall: one public IP, ports 80 and 443, and several backends that all want them. The fix is a reverse proxy that terminates TLS and routes requests to the right internal service by hostname. On a homelab firewall you can run that proxy on the firewall itself, and the two mature options are HAProxy and nginx. Both are available as plugins/packages on OPNsense and pfSense.

This is a practical comparison for the homelab use case — not a benchmark shootout. At home traffic volumes, raw performance is a non-issue for either; what differs is the model each tool gives you and how it fits onto a firewall.

First: should the proxy live on the firewall at all?

A fair question before HAProxy vs nginx. Running the reverse proxy directly on the firewall is convenient — one box, no extra VM — and both OPNsense (os-haproxy, the Caddy/Nginx plugins) and pfSense (HAProxy, nginx packages) support it. The tradeoffs:

  • Pro: One fewer machine; the proxy sits naturally at the network edge; integrates with the firewall’s certificate handling.
  • Con: It couples a security-critical box (the firewall) with an application-facing service. A reverse proxy parses untrusted input from the internet; some admins prefer to keep that off the firewall and on a dedicated internal host.

Both placements are defensible at home. If you’re security-conscious, a separate internal proxy host (running either tool, or Caddy/Traefik) is the more conservative design. This article assumes you’ve decided to run it on the firewall.

The conceptual difference

The two tools come from different lineages and it shows:

  • nginx is a web server first, reverse proxy second. Its config is server/location-block oriented and reads naturally if you think in terms of “this hostname serves this content / proxies to this upstream.” It also does static file serving, caching, and acts as a general-purpose web server.
  • HAProxy is a load balancer/proxy first, full stop. It does not serve files. Its model is built around frontends, backends, ACLs, and health checks. It is exceptionally good at TCP and HTTP load balancing, connection handling, and routing logic.

For the common homelab job — “send app1.example.com to 10.0.0.11 and app2.example.com to 10.0.0.12, with HTTPS” — both do it well. The difference shows up at the edges.

On OPNsense

HAProxy is the more established first-party story on OPNsense via the os-haproxy plugin. It exposes HAProxy’s frontend/backend/condition model through the UI: you define backend “real servers,” create conditions (e.g. host header matches), and bind a public frontend with TLS. Once you understand the HAProxy mental model, the UI is powerful and the resulting setup is robust, with real health checking and load-balancing if you ever need it.

For nginx, OPNsense has an Nginx plugin (os-nginx) that exposes a lot of nginx’s capability — upstreams, locations, TLS, even some WAF/ModSecurity-style features depending on the build. It’s capable but the UI surface is large, and mapping nginx’s flexibility into form fields can feel busier than HAProxy’s more constrained model.

Many OPNsense users also reach for Caddy (a separate plugin) specifically because of its automatic Let’s Encrypt handling — worth knowing about even though it’s outside this comparison.

On pfSense

HAProxy is the well-trodden path on pfSense too, available as a package with a UI that mirrors the frontend/backend concepts. It’s a common recommendation in the pfSense community precisely because the package is mature and the routing-by-hostname workflow is well documented.

nginx is also available as a pfSense package but is less commonly used as the reverse proxy of choice there; HAProxy tends to be the default suggestion. If you specifically want nginx’s web-server features on pfSense, the package exists, but you’ll find more community guidance for HAProxy.

TLS / certificates

This is where homelab setups get fiddly, and it’s worth being precise:

  • Both tools terminate TLS using certificates you provide. On the firewall, you typically manage certs through the firewall’s own certificate manager (OPNsense and pfSense both have ACME/Let’s Encrypt plugins/packages that obtain and renew certificates).
  • HAProxy on the firewall consumes those certificates for its frontends; the ACME plugin can be configured to restart/reload HAProxy on renewal.
  • nginx likewise references certificate files; renewal handling depends on the plugin/package wiring.

Neither tool obtains certificates by itself in these integrations — that’s the ACME component’s job. If you want a proxy that handles certificate issuance natively with the least configuration, that’s the argument for Caddy specifically, not for HAProxy or nginx.

Which to pick

Your priorityPick
Hostname routing + load balancing + health checksHAProxy
Most community guidance on pfSenseHAProxy
You also want a web server / static serving / caching on the same boxnginx
You think in “load balancer” termsHAProxy
You think in “web server / location blocks” termsnginx
Simplest possible auto-HTTPS(Consider Caddy instead)

For most homelabbers routing several services behind one IP on a firewall, HAProxy is the pragmatic default, especially on pfSense where it’s the community-standard answer and on OPNsense where the plugin is mature. Its frontend/backend/ACL model maps cleanly onto “route by hostname, check health, terminate TLS,” and it scales gracefully if you later add load balancing or a second backend instance.

Choose nginx when you want the proxy box to also be a web server — serving static content, caching responses, or handling more complex location-based rewriting. If your needs are purely “split one IP across many internal services,” nginx works but you’re using a web server to do a load balancer’s job.

A note on keeping it sane

Whatever you pick, two homelab habits prevent most pain:

  1. Use host-based routing, not port forwarding sprawl. One frontend on 443, routing by Host header, beats a dozen NAT port-forwards. Both tools make this easy.
  2. Keep the proxy config in version control or documented. Firewall UIs hide the underlying config; export or note your backend definitions so a rebuild isn’t archaeology.

Bottom line

At home traffic levels, both HAProxy and nginx are massively over-spec’d for the job, so pick on model fit, not performance. HAProxy is the cleaner conceptual match for “route and balance traffic to internal services” and is the better-supported choice on both OPNsense and pfSense for that task. Reach for nginx when you also want web-server behavior on the same host. And if your real goal is the least-effort automatic HTTPS, look at Caddy before either.

Further reading

Subscribe

Firewall Compare — in your inbox

OPNsense vs pfSense vs UniFi — side-by-side firewall comparisons for homelabs — delivered when there's something worth your inbox.

No spam. Unsubscribe anytime.

Related

Comments