Reverse proxy on a VPS — nginx vs Traefik for one Linux host

For people running one Linux VPS with one or more apps who need a single public front door for HTTP(S) — and keep hitting TLS, Host header, or "wrong upstream" problems.

Key takeaway

On a single host, both nginx and Traefik can work well. Pick the one you can operate confidently: nginx if you want explicit config files; Traefik if Docker label-driven routing is already how you deploy. The lead goal is one clear public entry on 80/443 — not collecting proxies.

What the reverse proxy is for

• Terminate TLS (Let's Encrypt or similar)
• Route by hostname/path to the right app
• Keep app and database ports off the public internet
• Give you one place to reason about access logs and headers

nginx — when it fits

Choose nginx when:

• You prefer a static config you can read end-to-end
• The stack is simple (a few vhosts)
• You already know certbot / ACME with nginx
• You want minimal moving parts

Watch-outs: config drift across files; forgetting to reload after edits; upstream still published publicly "for testing."

Traefik — when it fits

Choose Traefik when:

• Apps are Docker Compose services and you like label-based routes
• You want automatic certificate handling wired into the proxy
• Services come and go and you do not want to hand-edit a big nginx file each time

Watch-outs: labels become the source of truth (document them); dashboard/API must not be public; mislabelled routers expose the wrong service.

Caddy — brief note

Caddy is a strong third option for automatic HTTPS with a short Caddyfile. If your team already standardised on nginx or Traefik, switching proxies mid-incident rarely helps — fix routing first, rethink later.

Common failure modes (any proxy)

• DNS A/AAAA not pointing at this VPS
• App bound only to localhost but proxy pointing at the wrong port
• HTTP→HTTPS redirect loops
• Docker publishing the app port and the proxy (two public doors)
• Stale certificates / wrong certificate for the Host header

When a £150 session is enough

If the problem is "one site won't route / TLS won't issue / wrong upstream" on a reachable host, a bounded troubleshooting session is often the right first step. If the public surface is a mess of published ports and SSH risk, you may need hardening after the immediate outage is clear.

Practical next step

Stuck on nginx, Traefik, or TLS on one VPS? Start with a £150 troubleshooting session, or book a free 15-minute intro call.