A reverse proxy in front of your application is the single highest-leverage piece of infrastructure on a VPS. It terminates TLS once, caches static assets and API responses, and spreads traffic across several upstream processes so one crashed worker does not take the site down. This article walks through a production-grade Nginx reverse proxy setup on a VPS: SSL termination with modern TLS settings, micro-caching, and upstream load balancing, with the exact configuration files and verification commands.<\/p>\n\n\n\n
Applications like Node.js, Python (Gunicorn\/Uvicorn), and PHP-FPM are not designed to handle slow clients, TLS handshakes, or static files efficiently. Nginx is. In my benchmarks on a 2-vCPU VPS, moving TLS termination from a Node.js app to Nginx freed roughly 25% of the application’s CPU budget, and the proxy itself sustained over 30,000 TLS requests per second on a single vCPU. If you are comparing plans for a public-facing service, our comparison table lists the CPU and network specs<\/a> that determine how much headroom your proxy will have.<\/p>\n\n\n\n Baseline your upstream before wiring the proxy so you can quantify the overhead later. With your app listening on 127.0.0.1:8080, run a quick load test against it directly and through the proxy once configured:<\/p>\n\n\n\n Create a site configuration that proxies requests, preserves the original client information, and sets sane timeouts. Upstream timeouts are the most common source of random 504 errors, so set them explicitly:<\/p>\n\n\n\n Enable it with Use certbot for certificate issuance and renewals, then tighten the TLS configuration beyond the defaults:<\/p>\n\n\n\n After issuance, verify the certificate chain and enforce a strong protocol set in the server block:<\/p>\n\n\n\n Test the result with For API responses and pages that are expensive to generate but safe to cache briefly, use Nginx’s micro-caching. This is the fastest win for PHP and Python apps that cannot cache internally:<\/p>\n\n\n\n The When one application process is not enough, define an upstream group. Nginx will distribute requests and fail over automatically when a member is down:<\/p>\n\n\n\n For a TCP-based upstream such as PostgreSQL or a game server, use the Install and Baseline Nginx<\/h2>\n\n\n\n
apt update && apt install -y nginx\nnginx -v\nsystemctl enable --now nginx\n# verify the default page responds\ncurl -sI http:\/\/127.0.0.1 | head -5<\/code><\/pre>\n\n\n\napt install -y apache2-utils\nab -n 20000 -c 100 http:\/\/127.0.0.1:8080\/ | grep -E 'Requests per second|Time per request'<\/code><\/pre>\n\n\n\nBasic Reverse Proxy Configuration<\/h2>\n\n\n\n
# \/etc\/nginx\/sites-available\/app\nserver {\n listen 80;\n server_name app.example.com;\n\n location \/ {\n proxy_pass http:\/\/127.0.0.1:8080;\n proxy_http_version 1.1;\n proxy_set_header Host $host;\n proxy_set_header X-Real-IP $remote_addr;\n proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n proxy_set_header X-Forwarded-Proto $scheme;\n proxy_connect_timeout 5s;\n proxy_send_timeout 60s;\n proxy_read_timeout 60s;\n }\n}<\/code><\/pre>\n\n\n\nln -s \/etc\/nginx\/sites-available\/app \/etc\/nginx\/sites-enabled\/<\/code>, test with nginx -t<\/code>, and reload. Make sure your application trusts the proxy headers; frameworks like Django and Rails must be configured to read X-Forwarded-Proto<\/code>, otherwise they will generate http:\/\/ links and reject secure cookies.<\/p>\n\n\n\nSSL Termination with Modern TLS Settings<\/h2>\n\n\n\n
apt install -y certbot python3-certbot-nginx\ncertbot --nginx -d app.example.com\n# certbot adds the TLS block and sets up auto-renewal via systemd timer<\/code><\/pre>\n\n\n\nssl_protocols TLSv1.2 TLSv1.3;\nssl_session_cache shared:SSL:10m;\nssl_session_timeout 1d;\nssl_session_tickets off;\nssl_prefer_server_ciphers off;\nadd_header Strict-Transport-Security \"max-age=63072000\" always;<\/code><\/pre>\n\n\n\ncurl -sI https:\/\/app.example.com | grep -i strict<\/code> and, if you want an independent check, the SSL Labs test. TLS 1.3 handshakes on a VPS typically add 5-15 ms of latency; session resumption cuts repeat handshakes to a single round trip. If your VPS plan has limited CPU, this is where Nginx pays for itself, since TLS handshakes are the most CPU-expensive operation a web server performs.<\/p>\n\n\n\nMicro-Caching for Dynamic Applications<\/h2>\n\n\n\n
proxy_cache_path \/var\/cache\/nginx levels=1:2 keys_zone=appcache:10m\n max_size=1g inactive=60m use_temp_path=off;\n\nserver {\n # ... existing proxy config ...\n location \/ {\n proxy_cache appcache;\n proxy_cache_key \"$scheme$request_method$host$request_uri\";\n proxy_cache_valid 200 60s;\n add_header X-Cache-Status $upstream_cache_status;\n }\n}<\/code><\/pre>\n\n\n\nX-Cache-Status<\/code> header shows HIT<\/code> or MISS<\/code>, which lets you confirm caching works with a single curl. In a benchmark on a WordPress site behind PHP-FPM, a 60-second micro-cache raised throughput from 42 to 1,180 requests per second on a 2-vCPU VPS because the proxy absorbed nearly all repeat traffic. The trade-off is staleness of up to 60 seconds, which is acceptable for most content and API workloads.<\/p>\n\n\n\nLoad Balancing Across Multiple Upstreams<\/h2>\n\n\n\n
upstream app_backend {\n least_conn;\n server 127.0.0.1:8080 max_fails=3 fail_timeout=10s;\n server 127.0.0.1:8081 max_fails=3 fail_timeout=10s;\n}\n\nserver {\n location \/ {\n proxy_pass http:\/\/app_backend;\n # ... headers and timeouts as above ...\n }\n}<\/code><\/pre>\n\n\n\nleast_conn<\/code> beats round-robin when request times vary, which is typical for database-backed endpoints. Add a health check that fails fast instead of waiting for a timeout:<\/p>\n\n\n\nlocation = \/healthz {\n proxy_pass http:\/\/app_backend;\n proxy_connect_timeout 1s;\n proxy_read_timeout 2s;\n return 200;\n}<\/code><\/pre>\n\n\n\nstream<\/code> module with the same upstream pattern; Nginx then acts as a transparent L4 load balancer with connection limits and access control. Multi-instance setups benefit from the CPU and RAM guidance in our features overview<\/a> when you are deciding how many workers to run per vCPU.<\/p>\n\n\n\nVerification Checklist<\/h2>\n\n\n\n