HAProxy: one door, many rooms

All the web services share a single public IP, so something has to look at each incoming request and send it to the right backend. That's HAProxy, running on pfSense, routing by hostname:

https://git.example.com        ->  GIT-Server      10.100.100.2:3000
https://docs.example.com       ->  Docs-Server     10.100.100.3:80
https://monitoring.example.com ->  Monitoring      10.100.100.4:3000
https://registry.example.com   ->  Registry        10.100.100.6:5000
https://kong-admin.example.com ->  Kong proxy      10.100.100.100:80

One frontend on :443, many backends, chosen by the Host header. Port 80 just redirects to 443. Each backend has a health check so HAProxy stops sending traffic to something that's down.

A detail that matters for the backends: HAProxy preserves the Host header when it forwards. Services like Kong route based on hostname, so if the proxy rewrote the host, routing would break. (This is also why, in the Networking book, Kong is happy to serve plain HTTP — HAProxy hands it a clean, host-preserving HTTP request.)

Why we use this: host-based reverse proxying is how you run a dozen services on one IP and one certificate. It's the same pattern as a Kubernetes ingress — and seeing it at the edge and inside the cluster (Kong) is a nice way to internalise that "ingress" is just a reverse proxy with a fancier config language.