Reverse Proxy: What It Is & Why Self-Hosted Apps Need One

A reverse proxy is a server that sits in front of your self-hosted applications and forwards client requests to the correct backend service. Instead of connecting directly to your app, a visitor connects to the proxy, which then relays the request and the app’s response. You enter your domain name, and the proxy handles the rest — routing to the right app, handling encryption, and shielding your internal network. This article explains exactly how a reverse proxy works and why it’s become a standard part of a secure, maintainable self-hosting setup.

What Exactly Is a Reverse Proxy?

A reverse proxy is a server that sits between clients (like web browsers) and backend servers (like your self-hosted apps). It intercepts requests from the internet, decides which backend should handle them, and forwards the request there. The backend’s response then travels back through the proxy to the client.

The term reverse distinguishes it from a forward proxy. A forward proxy is what you’d use to reach the internet from inside a private network — it represents the client to the outside world. A reverse proxy does the opposite: it represents the server to the outside world. Clients only ever talk to the proxy, never directly to your application.

This is standard terminology in networking and web infrastructure. The word proxy comes from the Latin proximus, meaning “nearest,” and has been used in English since the 15th century to mean a substitute or agent. In computing, it’s been in use since the 1980s for intermediary servers. The phrase “reverse proxy” is standard in the industry — it’s not slang or informal. You’ll find it in official documentation for Nginx, Apache, Caddy, and HAProxy.

Why Run One for Self-Hosted Apps?

When you self-host, you typically have several services running on different ports: a media server on 8096, a dashboard on 3000, a file sync tool on 8080, and so on. Without a reverse proxy, you’d have to remember each port and connect via http://your-server:8096. That’s clumsy and insecure.

A reverse proxy gives you three immediate benefits:

• Single entry point: You access everything through one domain (e.g., https://apps.example.com/media) instead of remembering IP addresses and ports.
• Centralized TLS/SSL: The proxy handles HTTPS certificates for all your apps, so each one doesn’t need its own certificate setup.
• Security layer: Your backend apps are never directly exposed to the internet, reducing the attack surface.

It also enables advanced features like load balancing (distributing traffic across multiple instances), request logging, and rate limiting. For a home lab, the most practical reason is simply that it makes your services feel like proper web applications instead of a collection of port numbers.

How a Reverse Proxy Works (Request Flow)

Here’s the step-by-step path a request takes when you have a reverse proxy in place:

1. A user types https://media.example.com into their browser.
2. DNS resolves that domain to your server’s public IP address.
3. The request reaches your server on port 443 (HTTPS). The reverse proxy (e.g., Nginx or Caddy) is listening on that port.
4. The proxy reads the domain name from the request’s Host header and matches it against its configuration rules.
5. It forwards the request to the correct backend — for example, http://localhost:8096 for Jellyfin.
6. The backend processes the request and sends its response back to the proxy.
7. The proxy relays that response to the user’s browser, making it look like the proxy itself is the app.

This is why you can host multiple apps on one server and give each its own subdomain. The proxy acts as a traffic cop, directing each request to the right place.

Choosing a Reverse Proxy: Nginx vs. Caddy vs. HAProxy

The three most common choices for self-hosters are Nginx, Caddy, and HAProxy. Each has its own strengths:

• Nginx — The most widely used. It’s fast, stable, and highly configurable. The downside is that its configuration syntax can be intimidating for beginners. You’ll need to manually set up SSL certificates with Certbot or similar.
• Caddy — Designed for simplicity. It automatically obtains and renews HTTPS certificates from Let’s Encrypt with zero configuration. Its Caddyfile is much easier to read than Nginx’s config. This makes it an excellent choice for home users who want to get things running quickly.
• HAProxy — Primarily a load balancer. It excels at distributing traffic across multiple servers but lacks some of the HTTP-level features like URL rewriting that Nginx and Caddy offer. It’s overkill for most home setups but useful if you run a cluster.

For a beginner, Caddy is often the best starting point because of its automatic HTTPS. If you need more control or plan to run many complex rules, Nginx is a solid long-term choice. HAProxy is only necessary when you’re doing serious load balancing.

Common Problems and How to Avoid Them

Setting up a reverse proxy isn’t difficult, but there are a few pitfalls that trip people up:

• WebSocket connections not working. Many self-hosted apps (like live chat or real-time dashboards) use WebSockets. Your proxy must be configured to forward the Upgrade and Connection headers. In Nginx, this requires explicit proxy_set_header directives. Caddy handles this automatically.
• IP address logging shows the proxy’s IP. The backend sees the request coming from the proxy, not the client. You need to forward the X-Forwarded-For header and configure your app to trust it. Otherwise, your logs and rate-limiting will be wrong.
• Large file uploads timing out. If you host a file sharing app, the proxy may have a default request body size limit (Nginx’s default is 1 MB). Increase client_max_body_size to accommodate your files.
• SSL certificate renewal failures. If you’re using Certbot, ensure the HTTP challenge port (80) is reachable. Some home ISPs block port 80, which breaks the renewal process. In that case, use a DNS challenge instead.

Most issues come down to missing headers or port conflicts. A good troubleshooting approach is to check the proxy’s error logs and the backend app’s logs side by side to see where the request is getting stuck.

Security Considerations

Using a reverse proxy improves security, but it’s not a magic bullet. Here are some important points:

• Only expose the proxy. Your backend apps should listen on localhost or a private network interface only. If they’re bound to 0.0.0.0, they’re accessible directly — bypassing the proxy’s protection. Always set your app to listen on 127.0.0.1 or use firewall rules to block external access.
• Use HTTPS everywhere. The proxy should handle TLS, and the connection between the proxy and your backend can be plain HTTP since it’s on a trusted network. However, if your backend is on a different machine, consider using HTTPS or a VPN.
• Keep your proxy updated. Like any software, reverse proxies have vulnerabilities. Regular updates are essential.
• Be careful with headers. Forwarding headers like Host and X-Forwarded-For can be spoofed if your proxy isn’t configured correctly. Make sure your proxy overwrites these headers rather than passing them through from the client.

A reverse proxy also lets you add extra security layers like IP allowlisting, basic authentication, or even a Web Application Firewall (WAF). This is much harder to do when each app is exposed separately.

Alternatives to a Reverse Proxy

If you don’t want to set up a reverse proxy, you have a few alternatives:

• Direct port forwarding. Simply forward each port on your router to the corresponding app. This works but exposes each app to the internet and requires remembering ports. It also means managing SSL certificates for each app individually.
• VPN. Access your self-hosted apps only through a VPN like WireGuard or OpenVPN. This is very secure because nothing is exposed to the public internet, but it’s inconvenient for sharing apps with others.
• Cloudflare Tunnel. This runs a daemon on your server that connects outbound to Cloudflare’s network, which then serves your apps over HTTPS. You don’t need to open any ports on your router. It’s a form of reverse proxy, but managed by Cloudflare.
• Tailscale Funnel. A similar approach using Tailscale’s network. It’s easy to set up but requires the Tailscale client on your server.

Each alternative has trade-offs. Direct port forwarding is simplest but least secure. VPNs are secure but not shareable. Tunnels are convenient but rely on a third party. A self-hosted reverse proxy gives you full control and is a valuable skill to learn.

Frequently Asked Questions

Does a reverse proxy slow down my apps?

In practice, the performance impact is negligible. The proxy adds a single network hop, but on a local network or modern hardware, this is measured in microseconds. The benefits of centralized TLS and routing far outweigh the tiny overhead. If you’re worried, you can run benchmarks, but for typical self-hosted apps, you won’t notice a difference.

Can I use a reverse proxy with Docker?

Yes, absolutely. In fact, Docker Compose setups often include a reverse proxy container (like Nginx Proxy Manager or Traefik) that automatically discovers other containers and routes to them. This is a very common pattern. The proxy container needs to be on the same Docker network as your apps, and it should publish ports 80 and 443 to the host.

Do I need a domain name for a reverse proxy?

Technically, no. You can use an IP address and set the Host header manually, but it’s awkward. To get automatic HTTPS certificates from Let’s Encrypt, you need a domain name that points to your server. You can get a free subdomain from services like DuckDNS or use a cheap domain you own. Without a domain, you’d have to use self-signed certificates, which browsers will warn about.

What’s the difference between a reverse proxy and a load balancer?

A load balancer distributes traffic across multiple backend servers to spread the load and provide redundancy. A reverse proxy can do this, but its primary job is to act as a gateway for multiple apps. In practice, many tools (like Nginx) can do both. A load balancer is a specific use case of a reverse proxy. If you have only one instance of each app, you don’t need load balancing — you just need routing.

Is it safe to expose my reverse proxy to the internet?

Yes, if it’s properly configured and kept up to date. The proxy is designed to be exposed. The key is to ensure your backend apps are not directly accessible and that you’re using HTTPS. It’s also wise to enable fail2ban or similar intrusion prevention to block brute-force attempts on the proxy itself.

Related

• Safe to Disable Windows 11 Startup Processes?
• Fix Hard Disk I/O Device Error in Windows: Safe Steps
• Run a Guest OS Alongside Apps in a VM