What is a reverse proxy? Self-hosting explained
Part 1 of 3 - Self-Hosting with OPNsense and HAProxy
Part 2: HAProxy on OPNsense - configuring your reverse proxy →
Part 3: HTTPS for self-hosted services - ACME, Let’s Encrypt & Cloudflare DNS →
YouFibre gives you a fast, symmetrical FTTP connection and, if you add the static IP option, a stable public address to point domain names at. That combination makes self-hosting from home genuinely practical. But once you start running more than one service, you hit a problem: a server can only listen on one port at a time for a given protocol. How do you host five different websites, or a web app alongside a Nextcloud instance, when you only have one public IP and one port 443?
The answer is a reverse proxy.
What a forward proxy does (briefly)
You may have come across the term “proxy” in the context of office networks or privacy tools: a forward proxy sits between your device and the internet, forwarding your requests outbound on your behalf. It's used to cache content, enforce policies, or mask your IP. That's not what we're talking about here.
What a reverse proxy does
A reverse proxy sits at the edge of your network, facing the internet, and routes incoming requests to the right server or service on the inside. It works in the opposite direction: instead of acting on behalf of a client going outbound, it acts on behalf of a server receiving inbound traffic.
The clearest way to picture it is this:
- A visitor's browser connects to your domain, say
blog.example.com, on port 443 (HTTPS). - The request arrives at your public IP address, which is your router.
- The reverse proxy inspects the hostname in the request header.
- Based on that hostname, it forwards the request to the correct internal server - for example, a Docker container running on port 8080.
- The server responds, and the reverse proxy sends that response back to the visitor.
The visitor never connects directly to the internal server. From their perspective, they connected to your domain and got a response. What sits behind the proxy is invisible to them.
Why this matters for home self-hosting
Without a reverse proxy, every service you want to expose to the internet needs its
own port number. You end up with visitors having to type addresses like
mysite.example.com:8443 or mysite.example.com:3000.
That's inconvenient, unprofessional for anything you want to share, and harder
to secure consistently.
With a reverse proxy, all HTTPS traffic comes in on port 443, the standard port that browsers use by default. The proxy routes each request to the right service based on the domain name. Visitors just use normal URLs. You handle TLS termination in one place, manage certificates once, and apply security rules centrally.
The role of HAProxy
HAProxy is a battle-tested, open-source load balancer and proxy that's been a fixture in production infrastructure for decades. It's capable of handling enormous traffic volumes, but it scales down just as well to a single home server. OPNsense includes HAProxy as a plugin, which means you can run your reverse proxy directly on the same machine as your firewall - no additional hardware required.
There are other reverse proxy options. Nginx Proxy Manager and Caddy are popular choices that are often easier to get started with. The reason I use HAProxy on OPNsense is consolidation: one machine, one configuration interface, one place to manage firewall rules and proxying together. For a home lab or small self-hosted setup, that's a significant advantage.
The role of HTTPS and TLS certificates
A reverse proxy handles routing, but modern web standards also require HTTPS for practically every public-facing site. Browsers will show security warnings for plain HTTP, and some features simply don't work without a valid TLS certificate.
The standard way to get free, automatically-renewing certificates for self-hosted services is Let’s Encrypt via the ACME protocol. OPNsense has a built-in ACME client that integrates directly with HAProxy. Rather than opening port 80 for HTTP validation, you can use a DNS challenge: the ACME client creates a temporary DNS record to prove you control the domain, without needing any inbound port exposed during the validation process. Cloudflare's DNS API makes this straightforward to automate.
What the rest of this series covers
This post explains the concepts. The next two posts cover the practical setup:
- Part 2: HAProxy on OPNsense - installing the HAProxy plugin, configuring frontends, backends, and ACLs to route traffic by hostname to the right internal services.
- Part 3: ACME, Let’s Encrypt, and Cloudflare DNS - using OPNsense's ACME client to issue and automatically renew Let’s Encrypt certificates using a Cloudflare DNS challenge, and wiring those certificates into HAProxy.
If you're already comfortable with the concepts and just want the setup steps, skip ahead to Part 2. If you're new to self-hosting or want to understand what you're actually configuring before you configure it, start here.
Prerequisites
Before working through Parts 2 and 3, you'll need:
- An OPNsense router (this series was written against OPNsense 24.x)
- A YouFibre connection with a static IP - see Adding a static IP to your YouFibre connection
- A domain name pointing at your static IP
- A Cloudflare account managing DNS for that domain
- At least one internal service to expose (a web server, a Docker container, a NAS web UI, or similar)
You don't need to be an expert in any of these. The follow-up posts will walk through each step in full.
If you're not yet on YouFibre and this has been useful, you can use my referral code KCR5KH when you sign up. A static IP combined with a fast symmetrical connection makes self-hosting from home genuinely practical.
Check Availability at YouFibre