Reverse Proxy Explained: One Domain, Many Containers

A reverse proxy is one program that answers every request to your server and hands each one to the right app behind it. That single sentence is why one small VPS can run your analytics, your automations, and your whiteboard at once, each on its own domain, each with HTTPS. To prove it, I booted a fresh DigitalOcean droplet, started three containers, and put all three on the internet behind one nginx. Every config and every number on this page came off that server.

I have run this pattern in production for years. It is also the first thing my Self Hosting 2.0 course quietly sets up for you when you install Coolify: its proxy does exactly what this page teaches, just automatically. Understanding the manual version is what makes the automatic one debuggable.

What is a reverse proxy?

A reverse proxy is a server program that sits in front of your apps and answers every request on their behalf. It reads which domain the visitor asked for, forwards the request to the right app on an internal port, and carries the answer back. The visitor never talks to the app directly. They only ever talk to the proxy.

The analogy that made it click for me is a hotel front desk. Guests do not wander the corridors knocking on room doors. Everyone comes through one entrance, tells the desk who they are here for, and the desk routes them. The rooms do not need street addresses. The building needs one.

Here is that sentence as an actual request, using one of the demo apps you will build below:

"Reverse" only describes which side the proxy works for. A regular (forward) proxy works for clients going out. A reverse proxy works for servers receiving traffic in. More on that below.

The problem it solves: one IP, many apps

Say you self-host three apps on one VPS. Uptime monitoring, a whiteboard, whatever comes next month. Each runs in its own container, each listens on its own port. Without a proxy, your options look like this:

The deeper constraint: browsers assume port 80 for http:// and 443 for https://. A URL without a port number only ever reaches those two. And a certificate for a bare IP with a port is somewhere between painful and impossible to get. So the app that owns 443 gets a clean URL and a padlock, and every other app gets :8082 stapled to its name. With three apps, nobody wins that fight.

The reverse proxy dissolves it. nginx takes 80 and 443 once, and every app becomes a name. Adding a fourth app next month costs one DNS record and one small config file. No new open ports, no new certificates to think about, as you will see below.

Reverse proxy vs forward proxy

Both are middlemen. The difference is which side they work for, and which side they hide.

One name from that last row worth a sentence: when you put a site behind Cloudflare, you are using a reverse proxy you rent instead of run. Their edge answers for your domain and forwards to your server, the same mechanic as the nginx you are about to configure, at planetary scale.

Reverse proxy vs load balancer

These get mixed up because the same software does both. The difference is the shape of the routing:

• A reverse proxy sends different requests to different apps. kuma.* to the monitor, draw.* to the whiteboard.
• A load balancer spreads identical requests across copies of the same app, so no single copy drowns.

nginx does both, sometimes in the same config file. For self-hosting a handful of different apps on one box, the reverse proxy behavior is the one you need. Load balancing starts to matter when one app outgrows one machine. Different problem, different guide.

The tools people actually use

Every tool below does the job on this page. The differences are in how much they automate:

I am teaching nginx here because it hides nothing. After you have written one server block by hand, every other tool on this list becomes readable: you know what the label, the Caddyfile line, or the UI form is generating for you.

The proof: an nginx reverse proxy for three Docker apps

Enough concept. I booted a fresh Ubuntu 24.04 droplet and built the exact picture from the diagrams above. Three real apps:

My demo ran on the lab domain lab.selfhostschool.com, which is what you will see in the screenshots and terminal output. Swap in your own domain (the personalize card above does it for you in every command).

Step 1: point three subdomains at the server

In your DNS provider's panel, create one A record per app, all pointing at the same server IP:

kuma.yourdomain.com     A    203.0.113.42
draw.yourdomain.com     A    203.0.113.42
whoami.yourdomain.com   A    203.0.113.42

Three names, one IP. This looks wrong the first time you do it. It is the point: DNS gets every visitor to the building, and the Host header gets them to the right room.

Step 2: run the containers, invisible to the internet

SSH into the server and start the three apps. The part that matters is 127.0.0.1: in every -p flag:

docker run -d --name kuma --restart unless-stopped \
  -p 127.0.0.1:8081:3001 -v kuma-data:/app/data louislam/uptime-kuma:1

docker run -d --name draw --restart unless-stopped \
  -p 127.0.0.1:8082:80 excalidraw/excalidraw:latest

docker run -d --name whoami --restart unless-stopped \
  -p 127.0.0.1:8083:80 traefik/whoami

-p 127.0.0.1:8081:3001 means: publish the container's port 3001 on the server's loopback address only. The app runs, the server can talk to it, and the internet cannot see it at all. Here is the server's view after all three started:

root@cf-reverse-proxy:~# docker ps --format 'table {{.Names}}\t{{.Ports}}\t{{.Status}}'
NAMES     PORTS                      STATUS
whoami    127.0.0.1:8083->80/tcp     Up About a minute
draw      127.0.0.1:8082->80/tcp     Up About a minute (healthy)
kuma      127.0.0.1:8081->3001/tcp   Up About a minute (healthy)
root@cf-reverse-proxy:~# ss -tlnp | grep -E ':(8081|8082|8083)'
LISTEN 0  4096  127.0.0.1:8081  0.0.0.0:*  users:(("docker-proxy",pid=2779,fd=8))
LISTEN 0  4096  127.0.0.1:8082  0.0.0.0:*  users:(("docker-proxy",pid=2952,fd=8))
LISTEN 0  4096  127.0.0.1:8083  0.0.0.0:*  users:(("docker-proxy",pid=3068,fd=8))

And here is the internet's view. I probed those ports from my laptop, with port 22 as the control that proves the probe works:

you@laptop:~$ bash probe.sh 178.128.194.165
port 22:   OPEN  (the control: SSH answers, so the probe works)
port 8081: CLOSED/FILTERED  (no TCP connect within 5s)
port 8082: CLOSED/FILTERED
port 8083: CLOSED/FILTERED

Step 3: install nginx and write one server block per app

Now the front desk. Install nginx:

apt update && apt install -y nginx

Then give each app one file in /etc/nginx/sites-available/. Here is /etc/nginx/sites-available/kuma, the fullest of the three because Kuma's live dashboard also needs websocket support (the two Upgrade lines at the end):

server {
    listen 80;
    server_name kuma.yourdomain.com;

    location / {
        proxy_pass http://127.0.0.1:8081;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Read it top to bottom and it says exactly what the diagram said: server_name is the Host header to match, proxy_pass is where to forward. The proxy_set_header lines pass the visitor's real address through to the app; without them every visitor would look like 127.0.0.1. That is measurable, below.

The blocks for the other two apps are the same shape minus the websocket lines. Only the name and port change. /etc/nginx/sites-available/draw:

server {
    listen 80;
    server_name draw.yourdomain.com;

    location / {
        proxy_pass http://127.0.0.1:8082;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

And /etc/nginx/sites-available/whoami:

server {
    listen 80;
    server_name whoami.yourdomain.com;

    location / {
        proxy_pass http://127.0.0.1:8083;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

One more file, and it is my favorite detail of the whole setup. Replace the contents of /etc/nginx/sites-available/default with a catch-all that answers requests matching no app, including anyone poking the bare IP:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 444;
}

444 is an nginx special: close the connection without answering at all. A scanner sweeping IP ranges gets silence. Only visitors who asked for one of your domains by name get anything back.

Enable the three sites, test the config, reload:

ln -s /etc/nginx/sites-available/kuma   /etc/nginx/sites-enabled/kuma
ln -s /etc/nginx/sites-available/draw   /etc/nginx/sites-enabled/draw
ln -s /etc/nginx/sites-available/whoami /etc/nginx/sites-enabled/whoami
nginx -t && systemctl reload nginx

Does the Host header really decide everything? Easy to prove. Ask the same IP three ways:

you@laptop:~$ curl http://178.128.194.165/
curl: (52) Empty reply from server          # bare IP, no Host match: 444, silence

you@laptop:~$ curl http://kuma.lab.selfhostschool.com/
Found. Redirecting to /dashboard            # same IP, Kuma answers

you@laptop:~$ curl -H "Host: whoami.lab.selfhostschool.com" http://178.128.194.165/
Hostname: 44232a95e32f
GET / HTTP/1.1
Host: whoami.lab.selfhostschool.com
X-Forwarded-For: 203.0.113.7              # bare IP + a Host header: routed anyway

Step 4: HTTPS on all three apps with one command

Here is where the pattern pays off hardest. Because nginx is the only thing facing the internet, HTTPS is the proxy's problem, once, not each app's problem three times. The apps keep speaking plain HTTP on loopback and never know encryption exists.

apt install -y certbot python3-certbot-nginx

certbot --nginx \
  -d kuma.yourdomain.com \
  -d draw.yourdomain.com \
  -d whoami.yourdomain.com --redirect

certbot proves to Let's Encrypt that you control the three names, gets one certificate covering all of them, rewrites the three server blocks to use it, and adds the HTTP to HTTPS redirect. On the demo box the whole thing took under a minute:

Requesting a certificate for kuma.lab.selfhostschool.com and 2 more domains

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/kuma.lab.selfhostschool.com/fullchain.pem
This certificate expires on 2026-11-09.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

Deploying certificate
Successfully deployed certificate for kuma.lab.selfhostschool.com to /etc/nginx/sites-enabled/kuma
Successfully deployed certificate for draw.lab.selfhostschool.com to /etc/nginx/sites-enabled/draw
Successfully deployed certificate for whoami.lab.selfhostschool.com to /etc/nginx/sites-enabled/whoami
Congratulations! You have successfully enabled HTTPS on https://kuma.lab.selfhostschool.com,
https://draw.lab.selfhostschool.com, and https://whoami.lab.selfhostschool.com

Renewal is not your job either. certbot installed a systemd timer that checks twice a day and renews when under 30 days remain. I verified both halves on the box: systemctl list-timers certbot.timer showed the next run scheduled the same night, and certbot renew --dry-run came back "all simulated renewals succeeded".

That is the build done. Three apps, live, each on its own padlocked subdomain:

What the proxy sees (and what it adds)

This is where the whoami container earns its place in the demo. Its whole job is to print the request it receives, so it shows you exactly what your app sees from behind the proxy. I asked it twice, once directly on loopback and once through nginx from the internet:

root@cf-reverse-proxy:~# curl 127.0.0.1:8083
Hostname: 44232a95e32f
RemoteAddr: 172.17.0.1:38880
GET / HTTP/1.1
Host: 127.0.0.1:8083
User-Agent: curl/8.5.0
Accept: */*

root@cf-reverse-proxy:~# curl https://whoami.lab.selfhostschool.com/
Hostname: 44232a95e32f
RemoteAddr: 172.17.0.1:38886
GET / HTTP/1.1
Host: whoami.lab.selfhostschool.com
User-Agent: curl/8.5.0
Accept: */*
Connection: close
X-Forwarded-For: 178.128.194.165
X-Forwarded-Proto: https
X-Real-Ip: 178.128.194.165

The proxy also gives you something quieter: one access log for everything. Every request to every app lands in /var/log/nginx/access.log, one file to watch, one file to feed fail2ban.

And that log taught me something I did not plan to put in this guide. Requesting the certificate announced my subdomains. Let's Encrypt publishes every certificate it issues to public Certificate Transparency logs (an append-only public record designed to catch bad certificates), and scanners watch those logs. The first third-party request to the new subdomains, by name, arrived about three minutes after certbot finished. A crawler identifying itself as "RecordedFuture Global Inventory Crawler" showed up four minutes in. Nobody typed those names anywhere public. The certificate was the announcement.

The demo server lived 85 minutes. In that time its access log recorded 516 requests from 75 different IP addresses. One internet-scanning service, leakix.net, sent 186 of them by itself. My own tests and the Let's Encrypt validation checks account for under 200; most of the rest was the background noise every public HTTPS site gets. None of it reached an app port, because there was nothing else listening.

Does it slow things down? I measured it

Every request now takes an extra hop, so it must cost something. I measured how much on the demo box: 20 requests to whoami direct on loopback, then 20 through nginx with HTTPS, from the server itself so network jitter stays out of the numbers.

Read that middle row again. With the connection kept alive, which is what every browser does, going through nginx plus encryption cost the same 1.5 ms as skipping both. The proxy hop itself is a rounding error, around a tenth of a millisecond. The only real cost is the TLS handshake, and that is the price of HTTPS, not of the proxy. You would pay it with the app exposed directly too, if the app could even do TLS.

My first measurement said something different: 70 ms per request through the proxy. That number was real but it was measuring a fresh TLS handshake on every single request, which no browser does. If you benchmark your own proxy and get scary numbers, check whether your tool is reusing connections before you blame nginx.

Do you have to hand-write this?

No. And after this page, you can evaluate the automations honestly, because you know what they generate.

Caddy collapses Steps 3 and 4 into a two-line config with automatic HTTPS. Nginx Proxy Manager puts a web UI over exactly what you just wrote. Traefik watches Docker and builds the routes itself from container labels.

And if you want the whole pattern managed, this is literally what Coolify does: it runs Traefik as the front desk, and every time you deploy an app and type a domain, it writes the routing rule and gets the certificate. The reverse proxy from this page is running under every Coolify server, including mine. You now know exactly what it is doing and where to look when it misbehaves.

That trade is the honest pitch for my Self Hosting 2.0 course: we use Coolify so the proxy work is automatic, but you learn what is underneath, which is what makes a 2 AM debugging session short.

Questions people actually ask

• Updated August 2026
• Ubuntu 24.04.4
• nginx 1.24.0
• Docker 29.6.2
• certbot 2.9.0
• Time ~30 minutes
• Difficulty Beginner-friendly

Related

• Zero-Downtime Deployments on Coolify what Traefik does to your visitors during a deploy, measured at 10 req/s and fixed to zero
• Secure a Coolify VPS without breaking Coolify the firewall half of this story, measured on a live server
• Install Coolify in 2026 the managed version of everything on this page
• Self-Host Plausible Analytics a real app to put behind the proxy you just understood
• Self Hosting Hub every self-hosting guide on the site

One entrance. Many rooms.

Hasan Aboul Hasan builds open-source tools and teaches solo developers how to build, host, and sell AI-powered products. Founder of LearnWithHasan.com, creator of SimplerLLM and PyRunner.