What Is a Reverse Proxy? How It Works and When to Use One

If you've set up a web application on a VPS, followed a deployment guide, or worked with Nginx configuration files, you've encountered reverse proxies. The term appears often but isn't always explained clearly.

This guide explains what a reverse proxy is, what it does, when you need one, and an important monitoring consideration that many developers miss.

The Core Concept

A reverse proxy is a server that sits in front of your application and forwards incoming requests to it. From the client's perspective, they're talking to your website. In reality, the reverse proxy receives the request and passes it to the actual application running on the server.

It's called a "reverse" proxy because it's the opposite of a forward proxy. A forward proxy sits in front of clients (like a corporate network proxy that routes employee internet traffic). A reverse proxy sits in front of servers.

The most common reverse proxies you'll encounter are Nginx and Caddy (and Apache, which can act as one). Managed services like Cloudflare also function as reverse proxies at the network level.

What a Reverse Proxy Does

SSL termination — The reverse proxy handles HTTPS, decrypts the incoming request, and passes plain HTTP to your application. Your app doesn't need to handle SSL itself. Caddy in particular automates SSL certificate provisioning and renewal via Let's Encrypt, making this essentially zero-configuration.

Load balancing — If you're running multiple instances of your application, the reverse proxy distributes incoming requests across them. Nginx can route requests round-robin, by least connections, or by other strategies.

Request routing — Route different paths to different applications on the same server. /app goes to your Node.js application on port 3000. /api goes to your Python API on port 8000. /static gets served directly from disk. All behind a single domain.

Serving static files — Reverse proxies are much faster than application servers at serving static files (images, CSS, JS). Nginx can serve static files directly without touching your application.

Caching — Some reverse proxy configurations cache responses and serve them without hitting the application, reducing load.

Rate limiting — Nginx can be configured to limit requests per IP address, providing basic protection against abuse.

Compression — Enable gzip or brotli compression at the proxy level for all responses, without modifying your application.

A Typical Nginx Configuration

Here's a typical Nginx reverse proxy configuration for a Node.js application:

server {
    listen 80;
    server_name yourdomain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://localhost:3000;
        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;
    }

    location /static/ {
        alias /var/www/yourdomain/static/;
    }
}

This configuration:

• Redirects all HTTP traffic to HTTPS
• Terminates SSL and forwards decrypted requests to your app on port 3000
• Passes the real client IP to your application via headers
• Serves static files directly from disk without touching your app

Caddy: The Simpler Alternative

Caddy is a modern web server that auto-provisions HTTPS certificates and has a simpler configuration syntax. The equivalent of the Nginx config above in Caddy:

yourdomain.com {
    reverse_proxy localhost:3000
    file_server /static/* {
        root /var/www/yourdomain
    }
}

Caddy handles certificate provisioning and renewal automatically. For many setups, Caddy is easier to configure correctly than Nginx.

The Monitoring Blind Spot

Here's something many developers miss: your reverse proxy being up doesn't mean your application is working.

Nginx and Caddy can be running and accepting connections while the application they're proxying to has crashed, is returning errors, or is responding too slowly. From the reverse proxy's perspective, it's forwarding requests. From the user's perspective, they're getting error pages.

Standard server monitoring that checks whether Nginx is running won't catch this. You need to monitor what users actually experience — a real HTTP request to your domain that checks for a successful response.

This is also true the other way: if your reverse proxy fails, your application might be running perfectly fine, but users get connection refused or timeout errors and see nothing.

Domain Monitor monitors your website end-to-end — making real HTTP requests from multiple global locations every minute and verifying the response. It catches failures at any layer: the reverse proxy, the application, the database, or anything else in the chain.

Create a free account and add your domain. You'll know immediately if users can't reach your application, regardless of which layer is failing. See how to set up uptime monitoring for a complete guide.

When You Need a Reverse Proxy

Almost always on a VPS. If you're running a web application on your own server, you should have a reverse proxy in front of it. The SSL handling alone is worth it, and the ability to route requests and serve static files efficiently makes your setup significantly more capable.

Not always on managed hosting. If you're on Heroku, Vercel, Railway, or a similar managed platform, the platform handles the reverse proxy layer for you. You don't need to configure Nginx yourself.

Multiple apps on one server. A reverse proxy is the standard way to host multiple applications on a single server behind a single IP address, routing to each application based on the domain or path.

Quick Setup Guide

For a new VPS running Ubuntu:

# Install Nginx
sudo apt install nginx

# Or install Caddy (handles SSL automatically)
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo apt install caddy

With Caddy, point your domain at the server and your Caddyfile handles the rest. With Nginx, you'll configure the server blocks manually and use Certbot for SSL certificates.

Once configured, add monitoring so you know when anything in the chain fails.

Related Articles

• The Ultimate Guide to DNS - How the Domain Name System Works
• What Is a CDN? How Content Delivery Networks Work
• The Complete Guide to Web Application Performance