What is a reverse proxy: how it works, setup, and benefits

Load balancing

The simplest case is round-robin. Requests go in a circle. First to server1, second to server2, third to server3, fourth back to server1. In nginx it looks like this.

upstream backend {
  server 10.0.0.1:5000;
  server 10.0.0.2:5000;
  server 10.0.0.3:5000;
}

But round-robin is dumb. Doesn't account that server1 might be overloaded while server2 is idle. That's why there's least_conn. A new request goes where there are fewer active connections.

upstream backend {
  least_conn;
  server 10.0.0.1:5000;
  server 10.0.0.2:5000;
}

Even cooler to use weights. You have server1 with 32GB RAM, server2 with 8GB. Makes sense to send 4 times more to the first one.

upstream backend {
  server 10.0.0.1:5000 weight=4;
  server 10.0.0.2:5000 weight=1;
}

Caching and content delivery acceleration

Cache in nginx is a separate dissertation topic. Basic configuration looks like this.

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;‍

server {
	location / {
      proxy_cache my_cache;
      proxy_cache_valid 200 1h;
      proxy_cache_valid 404 1m;
      proxy_pass http://backend;
    }
}

The levels=1:2 parameter means a two-level folder structure. Otherwise there'll be a million files in one directory. The file system will choke.

keys_zone designates an area in shared memory for storing cache keys. 

max_size sets the maximum size on disk.

The trick is in proxy_cache_use_stale. Backend crashed? Nginx will serve stale cache.

proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;

HTTPS encryption and security

SSL/TLS handshake eats CPU like crazy. RSA 2048 bit requires 0.5ms per handshake on a modern CPU. With 1000 new connections per second, half a core goes just to cryptography.

Reverse proxy https solves the problem. SSL terminates at nginx, then plain HTTP goes on.

server {
  listen 443 ssl http2;
  ssl_certificate /etc/ssl/certs/cert.pem;
  ssl_certificate_key /etc/ssl/private/key.pem;
  ssl_session_cache shared:SSL:10m;
  ssl_session_timeout 10m;

  location / {
  	proxy_pass http://backend;
  }
}

The ssl_session_cache parameter is critically important. Without it every connection requires a full handshake. With it, session resumption happens, 10 times faster.

Masking internal infrastructure

Backends can be on anything. You have a legacy PHP4 application? Hide it behind nginx, no one will know. API on Go, admin panel on Django, reports on .NET? From the outside looks like a single service.

Headers can be cleaned up. Backend returns Server Apache/2.2.15 (CentOS)? You overwrite it.

proxy_hide_header Server;
add_header Server "nginx";

And if you're working with IP-demanding platforms, you'll have to think about the quality of outgoing connections. Specialized services like GonzoProxy help here. They have 20+ million verified residential IPs that don't get flagged as proxies. Especially relevant for parsing and multi-accounting.

For web application protection

Rate limiting saves from dumb brute force. Someone's hammering POST /login? We limit.

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
  location /login {
  limit_req zone=login burst=5 nodelay;
  proxy_pass http://backend;
}

5 requests per minute per IP. The burst=5 parameter allows exceeding, but no more than 5 requests. nodelay means don't delay, immediately return 503.

ModSecurity (WAF for nginx) filters absolutely everything. SQL injections, XSS, path traversal. Out-of-the-box rules catch 90% of typical attacks. But false positives happen, needs tuning.

For scalability and fault tolerance

Adding a server to nginx is simple. Add one line and reload.

upstream backend {
  server 10.0.0.1:5000;
  server 10.0.0.2:5000;
  server 10.0.0.3:5000; # new
}

No downtime. Nginx will reread the config, old workers will finish current requests and die, new ones will start with the new config.

Health checks in the open source version of nginx are primitive. Only passive. Server didn't respond max_fails times in a row, excluded for fail_timeout seconds. Nginx Plus has active health checks, but that's paid.

For corporate network optimization

Single entry point for all services. Instead of a dozen DNS A-records you get one. Instead of a dozen SSL certificates you use one wildcard. Instead of firewall setup for each service you only configure for the proxy.

Authentication can be moved to the proxy. Use nginx with the auth_request module.

location /internal/ {
  auth_request /auth;
  proxy_pass http://internal_service;
}

location = /auth {
  internal;
  proxy_pass http://auth_service/verify;
}

By the way, for distributed teams with lots of external integrations, quality proxies like GonzoProxy become a must-have. When you're hitting partner APIs 1000 times per minute, residential IPs with low fraud scores are critical.

Nginx as reverse proxy

Event-driven architecture is nginx's killer feature. One worker process through epoll (Linux) or kqueue (BSD) handles thousands of connections. Apache under load forks processes and eats gigabytes of RAM. Nginx works in 100 MB.

Nginx config reads like DSL. Nested blocks, directive inheritance. Location blocks match by priority. First exact (=), then regexes (~), then prefixes.

location = /api/v1/status {  # exact match, maximum priority
	return 200 "OK";
}

location ~ \.php$ {  # regex, medium priority
	proxy_pass http://php_backend;
}

location /static/ {  # prefix, low priority
	root /var/www;
}

Apache as reverse proxy

Apache with mod_proxy works differently. Process-based model (prefork MPM) or thread-based (worker MPM). Each request gets a separate process/thread. Memory hungry, but isolation is better.

Configuration through .htaccess is a double-edged sword. Convenient for shared hosting, but performance hit on every request. Apache rereads .htaccess files along the entire path.

<VirtualHost *:80>
  ProxyPreserveHost On
  ProxyPass / http://127.0.0.1:8080/
  ProxyPassReverse / http://127.0.0.1:8080/
</VirtualHost>

ProxyPreserveHost is important. Without it backend will get Host 127.0.0.1 instead of the original domain.

Setting up reverse proxy in Windows environment

IIS with ARR (Application Request Routing) is the standard for Windows. GUI for configuration helps those who fear the console. URL Rewrite module is quite powerful, supports regexes.

<system.webServer>
  <rewrite>
    <rules>
      <rule name="ReverseProxy" stopProcessing="true">
        <match url="(.*)" />
        <action type="Rewrite" url="http://backend/{R:1}" />
      </rule>
    </rules>
  </rewrite>
</system.webServer>

The problem with IIS is performance. On the same hardware nginx will handle 5-10 times more requests.

Prerequisites (server, access, basic knowledge)

VPS/VDS minimum is 1 CPU, 512 MB RAM for tests. For production take 2+ CPU, 2+ GB RAM. SSD is mandatory if you're planning caching. Random I/O on HDD will kill performance.

You need root or sudo access. Without this nginx won't start on ports 80/443 (privileged). You can start on 8080, but then you'll have to specify the port in the URL.

Commands that will definitely come in handy. ss -tulpn will show which ports are listening. journalctl -u nginx will output systemd unit logs. nginx -T will show the full configuration including includes. curl -I will check response headers.

Setting up reverse proxy in Nginx (configuration example)

Installing nginx. For Ubuntu/Debian use the command apt update && apt install -y nginx.

For RHEL/CentOS/Rocky run yum install -y epel-release && yum install -y nginx.

Config structure in Debian-based is like this. The /etc/nginx/sites-available/ folder contains configs, /etc/nginx/sites-enabled/ contains symlinks to active ones. In RHEL-based all configs are in /etc/nginx/conf.d/ with .conf extension.

Writing config /etc/nginx/sites-available/myapp.

upstream app_backend {
  keepalive 32;  # keep 32 connections open
  server 127.0.0.1:3000 max_fails=2 fail_timeout=10s;
  server 127.0.0.1:3001 max_fails=2 fail_timeout=10s backup;  # backup server
}
server {
  listen 80;
  server_name myapp.com;
  # Buffer sizes are important for performance
  client_body_buffer_size 128k;
  client_max_body_size 10m;
  proxy_buffer_size 4k;
  proxy_buffers 32 4k;
  
  location / {
    proxy_pass http://app_backend;
    proxy_http_version 1.1;  # for keepalive
    proxy_set_header Connection "";  # for keepalive
    
    # Pass real client IP
    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_set_header Host $host;
    
    # Timeouts
    proxy_connect_timeout 5s;
    proxy_send_timeout 60s;
    proxy_read_timeout 60s;
  }
  
  # Serve static directly
  location ~* \.(jpg|jpeg|gif|png|css|js|ico|xml)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
    root /var/www/static;
  }
}

Activate with commands ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/ and then nginx -t && systemctl reload nginx.

Setting up reverse proxy for HTTPS

Certbot is the simplest way to get a free SSL from Let's Encrypt. Install snap install --classic certbot.

Then run certbot --nginx -d myapp.com -d www.myapp.com --email admin@myapp.com --agree-tos --no-eff-email.

Certbot will add SSL settings to the config itself. But it's better to tweak some parameters.

# Modern protocols and ciphers

ssl_protocols TLSv1.2 TLSv1.3;

ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;

ssl_prefer_server_ciphers off;

‍

# OCSP stapling speeds up certificate verification

ssl_stapling on;

ssl_stapling_verify on;

‍

# HTTP/2 for performance

listen 443 ssl http2;

Checking and testing operation

Test config before applying. This is sacred. Run nginx -t.

If you see "syntax is ok", you can reload. "test failed" means read what's wrong.

Check what's listening with command ss -tulpn | grep nginx. Should see ports 80 and 443.

curl for checking works like this. For HTTP use curl -I http://myapp.com. For HTTPS run curl -I https://myapp.com. Follow redirects via curl -IL http://myapp.com. With custom header check curl -H "X-Test: 123" http://myapp.com.

Debug logs watch with command tail -f /var/log/nginx/access.log for general log. Errors are visible in tail -f /var/log/nginx/error.log. Filter by IP via tail -f /var/log/nginx/access.log | grep "192.168".