On a 1–2 vCPU, 1–2 GB VPS, the default nginx configuration wastes memory and lets slow clients tie up workers that should be serving real traffic. The good news: a handful of directives fixes most of the pain, and every change is verifiable with a benchmark. This guide walks through the nginx settings that matter on small servers — worker processes, timeouts, buffers, and static-file handling — with concrete values and the reasoning behind them.<\/p>\n\n\n\n
nginx runs one worker process per CPU core by design. On a small VPS, set Memory math is simple: each connection costs a few kilobytes of overhead, and each worker’s total memory footprint scales with Slow clients — mobile connections, crawlers, keep-alive hoarders — occupy a worker for as long as the timeouts allow. Tight, realistic values free workers quickly without hurting legitimate users:<\/p>\n\n\n\n These values assume your application responds in well under a second. If your PHP or Node backend regularly takes longer, raise Oversized buffers on a small VPS are pure waste — nginx allocates them per request. Keep them small and let the OS page cache do the heavy lifting.<\/p>\n\n\n\n For static assets, the classic trio is A few one-line defaults round out the setup. Set After editing, validate and reload with worker_processes auto;<\/code> so nginx matches whatever vCPUs the kernel actually sees — including your burst allocation. Each worker handles up to worker_connections<\/code> simultaneous connections; 1024 is a sensible ceiling on a 1–2 GB box. The event loop should look like this:<\/p>\n\n\n\n\n
worker_processes auto;<\/code> — one worker per vCPU<\/li>\nworker_connections 1024;<\/code> — connections per worker (2048 only if RAM allows)<\/li>\nuse epoll;<\/code> — the right event model on Linux<\/li>\nmulti_accept on;<\/code> — accept all new connections in one notification<\/li>\n<\/ul>\n\n\n\nworker_connections<\/code>. On a 1 GB VPS, raising worker_connections<\/code> to 4096 without raising RAM just moves the problem from nginx to the OOM killer.<\/p>\n\n\n\nTimeouts That Stop Slow Clients from Hogging Workers<\/h2>\n\n\n\n
\n
keepalive_timeout 20;<\/code> — how long an idle keep-alive connection stays open (20–30 s is plenty)<\/li>\nkeepalive_requests 500;<\/code> — requests per keep-alive connection before recycling<\/li>\nclient_body_timeout 10;<\/code> — seconds to read the request body (10–15 s)<\/li>\nclient_header_timeout 10;<\/code> — seconds to read the request headers<\/li>\nsend_timeout 10;<\/code> — seconds between two write operations to a client<\/li>\n<\/ul>\n\n\n\nsend_timeout<\/code> to 30–60 s — but first fix the backend, because timeouts are a symptom, not a solution.<\/p>\n\n\n\nBuffers and Request Sizes<\/h2>\n\n\n\n
\n
client_body_buffer_size 16k;<\/code> — buffer for the request body before spilling to disk<\/li>\nclient_max_body_size 2m;<\/code> — maximum upload size; raise it only if your app needs it<\/li>\nlarge_client_header_buffers 4 16k;<\/code> — headroom for large cookies and long URIs<\/li>\n<\/ul>\n\n\n\nStatic Files and Compression<\/h2>\n\n\n\n
sendfile on;<\/code> (copy files straight from disk to the socket), tcp_nopush on;<\/code> (send headers and file data in one packet), and tcp_nodelay on;<\/code> (disable Nagle for interactive traffic). Enable gzip for text assets with gzip on;<\/code>, gzip_comp_level 5;<\/code>, gzip_min_length 1024;<\/code>, and gzip_types text\/css application\/javascript application\/json image\/svg+xml;<\/code>. Finally, cache open file metadata so repeated requests skip stat calls: open_file_cache max=1000 inactive=20s;<\/code>, open_file_cache_valid 30s;<\/code>, open_file_cache_min_uses 2;<\/code>.<\/p>\n\n\n\nDirective<\/th> Recommended value<\/th> Why it matters<\/th><\/tr><\/thead> worker_processes<\/td> auto<\/td> Matches workers to actual vCPUs<\/td><\/tr> keepalive_timeout<\/td> 20<\/td> Frees workers held by idle connections<\/td><\/tr> client_max_body_size<\/td> 2m<\/td> Prevents memory waste on oversized uploads<\/td><\/tr> gzip_comp_level<\/td> 5<\/td> Good compression without burning CPU<\/td><\/tr> open_file_cache<\/td> max=1000 inactive=20s<\/td> Cuts stat() syscalls for repeated files<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Small Defaults Worth Changing<\/h2>\n\n\n\n
server_tokens off;<\/code> to stop nginx from advertising its version in headers — a cheap win that also reduces automated exploit attempts. Replace the default combined log format with a minimal one and disable access logging for static assets: location ~* \\.(css|js|png|jpg|svg|woff2)$ { access_log off; expires 7d; }<\/code> keeps disk I\/O and log rotation down on small boxes. If you proxy to PHP-FPM or an upstream app, add upstream php { server unix:\/run\/php\/php-fpm.sock; keepalive 32; }<\/code> and set proxy_http_version 1.1;<\/code> with proxy_set_header Connection \"\";<\/code> so upstream connections are reused instead of re-established per request — a measurable latency win under concurrent load.<\/p>\n\n\n\nVerify and Measure<\/h2>\n\n\n\n
nginx -t && sudo systemctl reload nginx<\/code>. Then benchmark before and after with wrk: wrk -t2 -c50 -d30s http:\/\/localhost\/<\/code>. On a typical small VPS you should see lower p95 latency and a smaller nginx memory footprint after tuning. The changes interact with your PHP-FPM or application settings, so retest after any backend change. Track resident memory too — ps -o pid,rss,cmd -C nginx<\/code> shows per-worker RSS, and each worker should stay well under 50 MB on a tuned config; if workers creep toward 100 MB, reduce worker_connections<\/code> or trim buffer sizes. If your workload is WordPress-heavy, also look at the caching features compared at virtualserversvps.com<\/a> — nginx tuning pairs well with FastCGI caching and Redis object caching. The FAQ<\/a> also answers common questions about running web servers on small plans.<\/p>\n\n\n\n