How to Set Up Nginx as a Reverse Proxy on a VPS: Step-by-Step from Installation to Production

Nginx is one of the most capable reverse proxy servers available, and it excels on resource-constrained VPS environments where every megabyte of RAM counts. Whether you are balancing traffic across multiple application instances, terminating SSL/TLS to offload work from your backend, or proxying WebSocket connections for real-time features, Nginx handles it all with minimal overhead. This step-by-step guide walks you from a fresh Nginx installation all the way to a production-grade reverse proxy configuration.

Prerequisites

Before you begin, ensure you have:

A VPS running Ubuntu 22.04 or Debian 12 with at least 512 MB RAM
Root or sudo access
A registered domain name pointing to your VPS IP address
Ports 80 and 443 open in your firewall

Step 1: Install Nginx

Start by installing Nginx from the official repository:

sudo apt update
sudo apt install nginx -y
sudo systemctl enable --now nginx

# Verify the installation
nginx -v
curl -I http://localhost

If you see the Nginx default welcome page, the installation was successful. For optimal performance, consider using the Nginx mainline version from the official Nginx repository instead of the distribution package — it includes the latest features and security patches.

Step 2: Understand the Reverse Proxy Flow

A reverse proxy sits between clients and your backend application servers. When a client sends a request to Nginx on port 80 or 443, Nginx forwards that request to an upstream server (like a Node.js, Python, Ruby, or Go application running on a different port or even a different machine), then returns the response to the client. This architecture provides several benefits:

Security: The backend server is never directly exposed to the internet
Load balancing: Distribute traffic across multiple backend instances
SSL termination: Handle encryption at the proxy layer, not in your application
Caching: Serve static assets and even cached API responses directly from Nginx
Compression: Gzip responses before sending to clients, saving bandwidth

Step 3: Basic Reverse Proxy Configuration

Create a site configuration file for your application. Remove the default symlink and create yours:

sudo rm -f /etc/nginx/sites-enabled/default
sudo nano /etc/nginx/sites-available/myapp

Add the following configuration for a basic reverse proxy with a single upstream server:

upstream myapp_backend {
    server 127.0.0.1:3000;
    keepalive 32;
}

server {
    listen 80;
    server_name myapp.example.com;
    client_max_body_size 100M;

    location / {
        proxy_pass http://myapp_backend;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        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_buffering off;
    }
}

Enable the site and test:

sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

The keepalive 32 directive maintains persistent connections between Nginx and your upstream server, eliminating TCP handshake overhead on every request. On a low-memory VPS, this can reduce latency by 30–50% under load.

Step 4: Load Balancing Across Multiple Backends

If your application runs multiple instances (e.g., using Node.js cluster mode or multiple workers), configure Nginx to distribute traffic:

upstream app_backend {
    least_conn;
    server 127.0.0.1:3000 weight=3;
    server 127.0.0.1:3001 weight=2;
    server 127.0.0.1:3002 backup;
}

Nginx offers several load balancing algorithms:

Round Robin (default): Distributes requests evenly in sequence. Best for homogeneous backends.
Least Connections: Routes to the server with the fewest active connections. Ideal for long-lived requests or variable processing times.
IP Hash: Ensures a client always hits the same backend. Useful when session data is stored locally and you don’t have a shared session store.
Generic Hash: Routes based on a custom key like $request_uri for cache-aware routing.

The weight parameter controls how much traffic each server gets. The backup flag marks a server that only receives traffic when all primary servers are unavailable.

Step 5: SSL Termination with Let’s Encrypt

Serving traffic over HTTPS is non-negotiable for production applications. Use Certbot to obtain free Let’s Encrypt certificates:

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d myapp.example.com

Certbot automatically modifies your Nginx configuration to enable HTTPS with modern TLS settings. After obtaining the certificate, your server block should include:

server {
    listen 443 ssl http2;
    server_name myapp.example.com;

    ssl_certificate /etc/letsencrypt/live/myapp.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/myapp.example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1h;
    ssl_session_tickets off;

    # HTTP/2 enabled for multiplexed connections
    # SSL session cache reduces CPU during handshakes

    location / {
        proxy_pass http://myapp_backend;
        proxy_set_header X-Forwarded-Proto https;
    }
}

# Redirect HTTP to HTTPS
server {
    listen 80;
    server_name myapp.example.com;
    return 301 https://$server_name$request_uri;
}

Enable HTTP/2 on the SSL listener — it multiplexes multiple requests over a single connection, reducing latency significantly on high-traffic sites. The ssl_session_cache directive stores TLS session parameters so subsequent connections from the same client skip the full handshake.

Step 6: WebSocket Support

For real-time applications (chat, live notifications, collaborative editing), configure Nginx to upgrade connections to WebSocket:

location /ws/ {
    proxy_pass http://ws_backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 86400s;
    proxy_send_timeout 86400s;
}

The critical directives are proxy_set_header Upgrade $http_upgrade and proxy_set_header Connection "upgrade". Without these, Nginx treats the WebSocket handshake as a normal HTTP request and the upgrade fails. Set the timeout values to at least 24 hours (86400s) to prevent premature connection drops during long-running WebSocket sessions.

Step 7: Performance Tuning for Low-Memory VPS

On a VPS with 1–2 GB RAM, Nginx proxy buffers can consume significant memory if not tuned properly. Adjust these values in your server block:

proxy_buffers 8 4k;
proxy_buffer_size 4k;
proxy_busy_buffers_size 8k;

These settings limit each buffer to 4 KB and cap the total at 32 KB per connection. For streaming applications or server-sent events, set proxy_buffering off so responses flow immediately to the client. For traditional web applications, buffering improves perceived performance by allowing Nginx to collect the full response before transmitting it.

Step 8: Securing and Hardening the Proxy

Additional security measures to protect your VPS:

Hide Nginx version: Add server_tokens off; in the http block
Rate limiting: Use limit_req_zone and limit_conn_zone to prevent abuse
Block malicious requests: Filter requests by user-agent, referrer, or request method
Set proper timeouts: Configure proxy_connect_timeout, proxy_read_timeout, and proxy_send_timeout to prevent slow loris attacks
Fail2ban: Install and configure Fail2ban to block repeated failed login attempts on SSH

Here is a hardened configuration snippet you can add to the http block:

# Security hardening
server_tokens off;
client_body_buffer_size 128k;
client_max_body_size 10m;
large_client_header_buffers 4 8k;

# Rate limiting
limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;

# Timeouts
proxy_connect_timeout 60s;
proxy_read_timeout 60s;
proxy_send_timeout 60s;

Troubleshooting Common Issues

502 Bad Gateway: Your upstream server is not running or unreachable. Check systemctl status your-app and verify the upstream address in your Nginx configuration.

504 Gateway Timeout: The upstream server takes too long to respond. Increase proxy_read_timeout or optimize the backend application.

SSL certificate errors: Certbot auto-renewal may fail if ports 80/443 are blocked. Ensure your firewall allows traffic on these ports and test renewal with sudo certbot renew --dry-run.

Monitoring Your Reverse Proxy

Once your reverse proxy is running, monitor key metrics including active connections, upstream response times, SSL handshake durations, and HTTP error rates. You can expose Nginx metrics with the ngx_http_stub_status_module and scrape them into your monitoring stack. For a solid VPS that can handle both your reverse proxy and monitoring tools simultaneously, compare VPS plans with adequate resources.

With Nginx acting as a reverse proxy, your application benefits from SSL termination, load balancing, WebSocket support, and a security layer — all running efficiently on a modest VPS. This setup scales from a single server handling a few hundred requests per second to a multi-node cluster serving millions.