Reverse Proxy Explained: One Domain, Multiple Apps

Imagine that you host an uptime monitor, an automation platform, an internal dashboard, and a private AI tool on a single VPS. You could expose every application using a different port number. Technically, that works. It quickly becomes difficult to maintain, however, and it exposes more services directly to the public internet.

A reverse proxy gives you a cleaner architecture. Visitors connect to one front-facing service. That service decides which application should handle each request.

Reverse Proxy Terminology for Beginners

Before configuring nginx, it helps to understand a few terms that appear throughout nearly every self-hosting tutorial.

What Is a Reverse Proxy?

A reverse proxy is a server that accepts incoming connections before they reach your backend applications. It receives the visitor’s request, chooses the appropriate destination, sends the request to that application, receives its response, and then returns the response to the visitor.

From the visitor’s perspective, the reverse proxy is the website. Your underlying application may actually be listening privately on 127.0.0.1:8081, but the visitor only sees a normal address such as https://status.example.com.

Think of it as the reception desk of an office building. Everyone enters through the lobby. The receptionist identifies which business the visitor needs and sends them to the correct room. Individual rooms do not need their own entrances from the street.

How a Reverse Proxy Works

DNS first directs the visitor toward your server’s IP address. Once the request reaches nginx, nginx reads information including the requested hostname. A matching configuration rule tells nginx where to send that request.

For example:

status.example.com  →  127.0.0.1:8081
draw.example.com    →  127.0.0.1:8082
tools.example.com   →  127.0.0.1:8083

All three domains can point to exactly the same public IP address. nginx is responsible for separating their traffic after it reaches the server.

The Problem a Reverse Proxy Solves

Suppose three Docker applications run on one VPS. Without a reverse proxy, you might publish all three ports directly.

Browsers naturally expect standard HTTP and HTTPS services on ports 80 and 443. A reverse proxy can occupy those ports and distribute requests to any number of backend ports.

Adding another application later can be as simple as creating another DNS record and another routing configuration.

Forward Proxy vs Reverse Proxy

The words sound similar because both systems act as intermediaries. The important difference is which side of the connection they represent.

Reverse Proxy vs Load Balancer

Reverse proxies and load balancers overlap because software such as nginx can perform both jobs. Their purposes are nevertheless different.

A reverse proxy commonly routes different destinations to different applications:

crm.example.com      → CRM application
status.example.com   → monitoring application
api.example.com      → API server

A load balancer instead distributes requests for the same application among multiple copies of it:

api.example.com
        ↓
Load Balancer
   ↙     ↓     ↘
API #1  API #2  API #3

Load balancing becomes useful when one application needs redundancy or more capacity than a single instance can provide.

Popular Reverse Proxy Tools

nginx is far from your only option. The best reverse proxy depends on how much manual control and automation you want.

Build an nginx Reverse Proxy for Three Docker Apps

Now we can turn the concept into an actual server layout.

status.example.com    A    203.0.113.10
draw.example.com      A    203.0.113.10
whoami.example.com    A    203.0.113.10

Notice that every hostname points to the same server IP. DNS gets the visitor to the correct server. nginx determines which application should receive the request after it arrives.

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


docker run -d \
  --name excalidraw \
  --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

The first mapping, for example, connects the container’s port 3001 to port 8081 on the server’s loopback address. nginx can communicate with it locally.

Confirm that the containers are running:

docker ps

You can also inspect listening ports:

ss -tlnp

sudo apt update
sudo apt install -y nginx

Confirm that nginx is running:

sudo systemctl status nginx

Create:

/etc/nginx/sites-available/status.example.com

Add:

server {
    listen 80;
    listen [::]:80;

    server_name status.example.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";
    }
}

Two directives explain most of the reverse proxy:

server_name status.example.com;

proxy_pass http://127.0.0.1:8081;

The first identifies requests nginx should match. The second identifies the backend application that should receive them.

Configure Excalidraw

server {
    listen 80;
    listen [::]:80;

    server_name draw.example.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;
    }
}

Configure Whoami

server {
    listen 80;
    listen [::]:80;

    server_name whoami.example.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;
    }
}

Create a Default Catch-All

You can also configure a default nginx server that does not expose a normal website when somebody requests an unknown hostname or browses directly to the server IP.

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name _;

    return 444;
}

The nginx-specific status 444 closes the connection without returning a normal HTTP response.

sudo ln -s /etc/nginx/sites-available/status.example.com /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/draw.example.com /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/whoami.example.com /etc/nginx/sites-enabled/

Then test the configuration:

sudo nginx -t

If the test succeeds, reload nginx:

sudo systemctl reload nginx

How nginx Makes the Routing Decision

Add HTTPS With Let’s Encrypt and Certbot

The reverse proxy can also handle TLS for all of your backend applications. The containers themselves can continue communicating with nginx over a local HTTP connection.

Install Certbot and its nginx integration:

sudo apt install -y certbot python3-certbot-nginx

Then request certificates:

sudo certbot --nginx \
  -d status.example.com \
  -d draw.example.com \
  -d whoami.example.com

Follow Certbot’s prompts. Once configured successfully, visitors can reach:

https://status.example.com
https://draw.example.com
https://whoami.example.com

You can inspect Certbot’s renewal timer with:

systemctl list-timers | grep certbot

And perform a simulated renewal test using:

sudo certbot renew --dry-run

What Are X-Forwarded-For and Other Proxy Headers?

Once nginx sits between the visitor and the application, the backend’s direct network connection comes from the proxy rather than directly from the original visitor.

Proxy headers preserve important information about the original request.

That is why nginx configurations frequently contain:

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;

Some applications require you to explicitly mark your proxy as trusted before they will rely on forwarded headers. Always follow the application’s documentation when enabling this behavior.

Does a Reverse Proxy Make a Server More Secure?

A reverse proxy can improve your architecture by reducing how many application ports need to be publicly reachable and by giving you one controlled layer for TLS, logging, access rules and rate limiting.

However, installing nginx does not automatically secure a VPS. You still need proper application authentication, software updates, firewall rules, SSH hardening, backups, monitoring and sensible container configuration.

Useful Security Practices

• Keep backend application ports private when direct access is unnecessary.
• Require strong passwords or single sign-on for administrative tools.
• Use HTTPS everywhere for browser-facing services.
• Patch nginx, Docker, Ubuntu and your applications regularly.
• Review nginx access and error logs.
• Back up application data before upgrades.
• Do not expose databases directly to the internet unless absolutely necessary.
• Add rate limiting where automated abuse is a concern.

Centralized nginx Logging

Another advantage of having a central web entry point is visibility. nginx can record requests passing through the proxy.

Common log locations include:

/var/log/nginx/access.log
/var/log/nginx/error.log

For example:

sudo tail -f /var/log/nginx/access.log

This is extremely useful when a container appears healthy but visitors are receiving a 404, 502 or another unexpected response.

What Does 502 Bad Gateway Mean?

A 502 Bad Gateway error commonly means nginx accepted the visitor’s request but could not successfully communicate with the backend service.

Check:

• Is the Docker container running?
• Is the port in proxy_pass correct?
• Is the application actually listening on that port?
• Did the container restart or fail?
• Does nginx have the correct protocol: HTTP versus HTTPS?

Useful commands include:

docker ps
docker logs CONTAINER_NAME
curl http://127.0.0.1:8081
sudo nginx -t
sudo tail -n 100 /var/log/nginx/error.log

Does a Reverse Proxy Slow Down a Website?

Technically, a reverse proxy adds another processing step. In a properly configured local setup, however, the forwarding operation itself is normally very small compared with application processing, database queries, network latency, image transfer and other work involved in serving a modern page.

HTTPS connection setup can also affect benchmarks. Be careful when comparing a new TLS connection against an already-established local HTTP connection. Browsers normally reuse connections rather than performing an entirely new TLS handshake for every asset.

Measure Your Own Server

For a meaningful comparison, benchmark both the direct application and the proxied endpoint under equivalent conditions.

# Backend from the VPS
curl -o /dev/null -s \
  -w 'total=%{time_total}\n' \
  http://127.0.0.1:8083


# Public reverse-proxied endpoint
curl -o /dev/null -s \
  -w 'total=%{time_total}\n' \
  https://whoami.example.com

For serious testing, use repeated requests and a proper benchmarking tool rather than drawing conclusions from a single request.

Subdomains vs Path-Based Reverse Proxy Routing

You do not always need a different subdomain for every application. nginx can also route according to URL paths.

For example:

example.com/status/
example.com/draw/
example.com/tools/

An nginx configuration might include:

location /status/ {
    proxy_pass http://127.0.0.1:8081/;
}

The challenge is that some applications assume they are installed at the root of a domain. They may generate JavaScript, CSS, redirects, WebSocket addresses, cookies or API URLs that do not work correctly beneath a path prefix.

For that reason, subdomains are frequently simpler for independent self-hosted applications:

status.example.com
draw.example.com
tools.example.com

Reverse Proxies and WebSockets

Applications that maintain persistent browser connections may use WebSockets. In nginx, WebSocket applications commonly require HTTP/1.1 and upgrade headers.

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

If an application works partially but live updates or real-time connections fail, check its reverse-proxy documentation for WebSocket requirements.

Is Cloudflare a Reverse Proxy?

Cloudflare can act as a reverse proxy in front of your origin server. When proxying is enabled for a DNS record, visitors connect to Cloudflare’s network, and Cloudflare connects onward to your server.

You can even have multiple layers: Cloudflare may proxy traffic to nginx, and nginx may then proxy that request to a Docker container.

Do You Have to Configure Reverse Proxies Manually?

No. Manual nginx configuration is valuable because it teaches you what the routing layer is doing, but several platforms automate most of the work.

Caddy

Caddy combines reverse proxying with automatic HTTPS and can make simple deployments remarkably short.

status.example.com {
    reverse_proxy 127.0.0.1:8081
}

Nginx Proxy Manager

Nginx Proxy Manager provides a browser-based administration panel. Instead of writing every server block manually, you define proxy hosts using forms and can manage certificates from the interface.

Traefik

Traefik is especially attractive for environments where containers are created and removed frequently. Docker labels can describe routing rules, allowing Traefik to discover services dynamically.

Coolify and Similar Platforms

Modern self-hosting platforms can hide most of the reverse-proxy plumbing. You deploy an application, assign a domain, and the platform configures routing and certificates for you.

Understanding nginx manually is still useful because errors such as failed certificate issuance, incorrect routes and gateway failures ultimately involve the same underlying concepts.

Which Reverse Proxy Should You Choose?

Reverse Proxy Frequently Asked Questions

Final Thoughts

The main idea behind a reverse proxy is much simpler than the configuration files initially make it appear.

Your public server has one front door. nginx, Caddy, Traefik or another proxy stands at that door. Every incoming request identifies the destination it wants, and the proxy forwards that request to the correct application.

Once you understand that architecture, technologies such as managed self-hosting platforms, Docker ingress systems, Cloudflare, Caddy and Traefik become much easier to understand because they are solving variations of the same routing problem.

Last updated: 2026. Always review current nginx, Docker and Certbot documentation before applying server configuration in production.