Ashraful’s Blog
Back to articles

ARTICLE / DEV COMMUNITY

How Reverse Proxies Actually Work (And Why Every Self-Hosted Server Needs One)

July 19, 2026 4 min read 0 reactions 0 comments #webdev #nginx #linux #proxy
How Reverse Proxies Actually Work (And Why Every Self-Hosted Server Needs One)

Imagine walking into a large office building. You don't know which department handles your request, so you first stop at the reception desk.

The receptionist asks what you need, checks your request, and directs you to the correct department.

A reverse proxy works exactly like that receptionist.

Instead of exposing every application directly to the internet, all traffic first reaches the reverse proxy. The reverse proxy then decides where that request should go.

If you're running a home server, VPS, or Kubernetes cluster, understanding reverse proxies is one of the most valuable networking concepts you can learn.

Let's dive in.

What Is a Reverse Proxy?

A reverse proxy is a server that sits between clients and your backend applications.

Instead of users connecting directly to your services, they connect to the reverse proxy first.

Internet
     │
     ▼
+--------------------+
|   Reverse Proxy    |
+--------------------+
        │
 ┌──────┼─────────┐
 │      │         │
 ▼      ▼         ▼
Jellyfin Immich  Nextcloud
Enter fullscreen mode Exit fullscreen mode

The client never talks directly to Jellyfin, Immich, or Nextcloud.

Everything passes through the reverse proxy.

Reverse Proxy vs Forward Proxy

People often confuse these two.

Forward Proxy

A forward proxy works for the client.

You
 │
 ▼
Forward Proxy
 │
 ▼
Internet
Enter fullscreen mode Exit fullscreen mode

Examples:

  • Corporate networks
  • School internet
  • VPNs
  • Anonymous browsing

The website sees the proxy—not you.

Reverse Proxy

A reverse proxy works for the server.

Internet
     │
     ▼
Reverse Proxy
     │
     ▼
Your Applications
Enter fullscreen mode Exit fullscreen mode

Clients don't know which server actually handled the request.

Why Not Just Open Every Port?

Suppose your server runs:

Application Port
Jellyfin 8096
Immich 2283
Nextcloud 8080
Grafana 3000
Portainer 9443

Without a reverse proxy, you'd access them like this:

https://example.com:8096
https://example.com:2283
https://example.com:8080
Enter fullscreen mode Exit fullscreen mode

That's messy.

Instead, a reverse proxy lets you use:

https://movies.example.com
https://photos.example.com
https://cloud.example.com
https://grafana.example.com
Enter fullscreen mode Exit fullscreen mode

Much cleaner.

How a Reverse Proxy Routes Requests

Imagine someone opens:

https://movies.example.com
Enter fullscreen mode Exit fullscreen mode

The request reaches your reverse proxy.

The reverse proxy checks:

Host: movies.example.com
Enter fullscreen mode Exit fullscreen mode

It finds a rule:

movies.example.com
      ↓
http://192.168.1.20:8096
Enter fullscreen mode Exit fullscreen mode

The request is forwarded to Jellyfin.

If someone instead visits:

https://photos.example.com
Enter fullscreen mode Exit fullscreen mode

The proxy routes it to:

http://192.168.1.20:2283
Enter fullscreen mode Exit fullscreen mode

which is your Immich server.

The client never notices this routing.

A Real Example

Suppose your home server hosts four services.

192.168.10.10

├── Jellyfin
├── Immich
├── Grafana
└── Portainer
Enter fullscreen mode Exit fullscreen mode

You install Nginx Proxy Manager.

DNS records:

movies.example.com
photos.example.com
grafana.example.com
portainer.example.com
Enter fullscreen mode Exit fullscreen mode

Routing table:

movies.example.com
    ↓
localhost:8096

photos.example.com
    ↓
localhost:2283

grafana.example.com
    ↓
localhost:3000

portainer.example.com
    ↓
localhost:9443
Enter fullscreen mode Exit fullscreen mode

Everything is now accessible using simple URLs.

HTTPS Becomes Easy

Without a reverse proxy, every application must:

  • Generate certificates
  • Renew certificates
  • Configure HTTPS
  • Handle redirects

That's a lot of work.

Instead:

Internet
    │ HTTPS
    ▼
Reverse Proxy
    │ HTTP
    ▼
Applications
Enter fullscreen mode Exit fullscreen mode

The reverse proxy handles:

  • SSL certificates
  • Let's Encrypt
  • Automatic renewal
  • HTTPS redirects

Your backend applications can remain on HTTP inside your trusted local network.

Security Benefits

A reverse proxy isn't just about convenience.

It adds another security layer.

It can:

  • Hide internal IP addresses
  • Block malicious requests
  • Limit request rates
  • Require authentication
  • Restrict countries
  • Filter bad bots
  • Prevent direct access to services

Your applications become much harder to attack.

Load Balancing

Suppose one server isn't enough.

Instead of one backend:

App Server 1
App Server 2
App Server 3
Enter fullscreen mode Exit fullscreen mode

The reverse proxy distributes traffic.

Client 1 → Server 1

Client 2 → Server 2

Client 3 → Server 3
Enter fullscreen mode Exit fullscreen mode

Benefits:

  • Higher availability
  • Better performance
  • Fault tolerance

Large websites rely heavily on this.

Caching

Imagine your homepage receives thousands of requests.

Instead of asking your application every time:

User
  │
  ▼
Reverse Proxy
  │
Cache Exists?
  │
 Yes ─────► Return Cached Page
  │
 No
  ▼
Application
Enter fullscreen mode Exit fullscreen mode

Static content like:

  • Images
  • CSS
  • JavaScript
  • Fonts

can be served directly from the reverse proxy.

This greatly reduces application load.

Compression

Modern reverse proxies can compress responses.

Instead of sending:

HTML
CSS
JavaScript
Enter fullscreen mode Exit fullscreen mode

uncompressed, they use:

  • Gzip
  • Brotli

Smaller responses mean:

  • Faster websites
  • Lower bandwidth usage
  • Better user experience

WebSockets and Streaming

Applications like:

  • Jellyfin
  • Home Assistant
  • Immich
  • VS Code Server

use persistent connections.

Reverse proxies understand WebSockets and keep these connections alive while still handling routing and HTTPS.

Popular Reverse Proxy Software

Software Best For
Nginx High performance and flexibility
Nginx Proxy Manager Easy web interface for beginners
Traefik Docker and Kubernetes integration
HAProxy High-performance load balancing
Caddy Automatic HTTPS with minimal configuration
Envoy Large-scale microservices and cloud-native deployments

Each has its strengths, but for many self-hosters, Nginx Proxy Manager provides an excellent balance of simplicity and features.

Common Mistakes

Many beginners accidentally:

  • Expose application ports directly to the internet.
  • Skip HTTPS entirely.
  • Open unnecessary firewall ports.
  • Forget to configure X-Forwarded-For and X-Forwarded-Proto headers.
  • Leave administrative interfaces like Portainer publicly accessible without authentication.
  • Mix internal and external DNS records in ways that create routing issues.

Taking time to configure your reverse proxy correctly can prevent these problems.

When Do You Need a Reverse Proxy?

You probably need one if you:

  • Host more than one web application.
  • Want friendly domain names instead of port numbers.
  • Need HTTPS certificates.
  • Run Docker containers.
  • Self-host services at home.
  • Want a central place to manage routing, security, and access control.

For many self-hosted environments, a reverse proxy quickly becomes an essential part of the stack rather than an optional extra.

Conclusion

A reverse proxy is much more than a traffic router. It acts as the front door to your infrastructure, deciding where requests go, protecting your applications, managing HTTPS, balancing traffic, and improving performance through caching and compression.

Whether you're running a single Raspberry Pi with a few services or a rack of servers in a data center, the underlying concept is the same:

Clients talk to the reverse proxy, and the reverse proxy talks to your applications.

Once you understand this pattern, you'll notice it everywhere—from home labs and Docker setups to cloud platforms and some of the world's largest websites. It is one of the foundational building blocks of modern web infrastructure.

View on dev.to