A reverse proxy in front
One process should face the internet and hand requests to everything behind it. A reverse proxy gives you TLS in one place, clean routing to many applications, and a single front door to secure.
Behind almost every well-run server is a reverse proxy: nginx, HAProxy or Caddy taking every request on 80 and 443 and passing it to the right application. It is the single most useful piece of plumbing you can add.
What it does for you
- Terminates TLS once, so your apps speak plain HTTP behind it — see TLS certificates
- Routes by hostname or path to many backends on one IP
- Adds caching, rate limiting and compression without touching the app
- Gives you one place to add security headers and block bad requests
Pass the client’s real address
Once a proxy is in front, your application sees the proxy’s address, not the visitor’s, unless you forward it. Set X-Forwarded-For and X-Forwarded-Proto, and tell the application to trust them — otherwise every log line and rate limit sees one IP. Get this wrong and you can also be tricked into trusting a spoofed header, so trust it only from the proxy.
Websockets need help through
Live features — chat, dashboards, notifications — use websockets, and a proxy drops them unless you forward the Upgrade and Connection headers. This is the most common “it works until it needs to be live” bug. See a self-hosted team chat.
Health checks, if you have more than one backend
HAProxy and nginx can check each backend and stop sending traffic to a dead one. If you run two application servers for resilience, this is what makes a failure invisible rather than a 502 for half your users. See spreading traffic across two servers.
It is now the front door
Everything enters through the proxy, which makes it the thing to harden and keep patched — see hardening TLS — and to monitor, because if it is down, everything behind it is unreachable.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base