Nginx’s performance advantage begins with its event-driven, asynchronous architecture. Unlike traditional web servers that spawn a new thread or process for each connection—consuming significant memory and CPU overhead—Nginx uses a single master process that manages multiple worker processes. Each worker process handles thousands of simultaneous connections using non-blocking I/O and an event loop, typically leveraging system calls like epoll (Linux) or kqueue (FreeBSD). This design minimizes context switching and memory fragmentation, allowing Nginx to serve tens of thousands of concurrent clients on modest hardware. The master process reads configuration, monitors worker health, and gracefully reloads changes without dropping connections. Understanding this architecture is foundational: configuration directives like worker_processes (typically set to the number of CPU cores) and worker_connections (maximum concurrent connections per worker) directly scale this model. The formula max_clients = worker_processes * worker_connections provides a quick capacity estimate, though real-world limits also depend on file descriptors and memory.
Every Nginx deployment begins with nginx.conf, a hierarchical configuration file structured into blocks: events, http, server, and location. The events block sets connection-processing parameters. worker_connections should be tuned to the system’s ulimit -n (open file limit). Using use epoll on modern Linux ensures efficient event handling. In the http block, keep sendfile on to copy data directly between file descriptors, bypassing user-space overhead. tcp_nopush and tcp_nodelay should be enabled to optimize packet sending and reduce latency, particularly for small responses. keepalive_timeout (default 75 seconds) should be reduced to 15–30 seconds to free connections for new clients. For static assets, open_file_cache max=1000 inactive=20s caches file metadata, reducing disk reads. Disabling server tokens with server_tokens off hides Nginx version details from attackers. These optimizations, when combined, can reduce CPU usage by 30% or more under heavy load.
Nginx excels as a reverse proxy and load balancer. The upstream block defines a group of backend servers. Default round-robin distribution works for homogeneous backends, but least_conn forwards requests to the server with fewest active connections, ideal when request processing times vary. For session persistence, ip_hash maps client IPs to specific servers, ensuring stateful applications like shopping carts function correctly, though this can cause uneven load. The weight parameter assigns proportional load: server 192.168.1.10 weight=3 receives three times the traffic of an unweighted peer. Health checks use max_fails and fail_timeout: after max_fails consecutive failures within fail_timeout, the server is marked down. Active health checks require the commercial Nginx Plus, but passive ones suffice for most needs. For load balancing over multiple data centers, use zone to share state across Nginx instances. Include backup servers with down to handle failover gracefully. SSL termination at the proxy reduces backend encryption overhead—remember to pass X-Forwarded-For and X-Real-IP headers so backend logs retain client IPs.
Securing Nginx involves multiple layers. Start by creating a dedicated user www-data with minimal ownership over web root directories. Restrict access to sensitive locations: location ~ /.git { deny all; } prevents repository leaks. Use limit_req_zone $binary_remote_addr zone=login:10m rate=5r/s to throttle login endpoints, mitigating brute-force attacks. Rate limiting uses a leaky bucket algorithm—the burst parameter allows short spikes (e.g., burst=10 nodelay). For DDoS prevention, client_body_timeout 10s and client_header_timeout 10s drop slow connections. The client_max_body_size directive (default 1MB) should be explicitly set to 0 for unlimited or a specific limit for upload endpoints. HTTP Strict Transport Security (HSTS) is enforced via add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;. TLS configuration requires strong ciphers: ssl_ciphers HIGH:!aNULL:!MD5; and disabling SSLv3/TLSv1.0. Use ssl_stapling on to reduce certificate validation latency. For web application firewalling, integrate ModSecurity with Nginx’s dynamic module support, or use ngx_http_limit_conn_module to limit concurrent IP connections: limit_conn perip 20. Regularly update Nginx to patch CVEs—vulnerabilities like CVE-2023-44487 have exploited HTTP/2 rapid reset attacks in earlier versions.
Nginx’s caching capabilities dramatically reduce backend load for repeat requests. Enable caching in the http block: proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mycache:10m max_size=1g inactive=60m use_temp_path=off;. The keys_zone defines shared memory allocation (10MB can store ~80,000 keys). use_temp_path off prevents temp file creation, improving I/O. In a location block, specify proxy_cache mycache;. Cache key customization uses proxy_cache_key "$scheme$request_method$host$request_uri";. For dynamic content, implement cache purging with proxy_cache_purge (requires commercial version or custom Lua scripting). Microcaching—setting proxy_cache_valid 200 1s—caches API responses for seconds, absorbing traffic spikes. Bypass caching for authenticated sessions using cookies: proxy_no_cache $cookie_session;. Use proxy_cache_use_stale error timeout invalid_header updating http_500 to serve stale content during backend failures. Monitor cache hit ratios via the $upstream_cache_status variable logged with $http_x_cache_status. A well-tuned cache can serve 95% of requests from memory, reducing TTFB to under 10ms.
Comprehensive logging is non-negotiable. The default combined log format is adequate, but custom formats capture critical metrics: log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time $upstream_response_time'. The $request_time variable measures total request processing including network latency; $upstream_response_time isolates backend performance. Perform log rotation with logrotate to prevent disk exhaustion—one common pitfall. For real-time monitoring, expose the ngx_http_stub_status_module at a protected endpoint: location /nginx_status { stub_status; allow 192.168.0.0/16; deny all; }. This module outputs active connections, accepted handshakes, and reading/writing counts. Integrate with Prometheus using the nginx-prometheus-exporter or use commercial tools like Datadog and New Relic’s Nginx plugin. Key metrics to track: requests per second (baseline vs. spikes), 4xx/5xx error rates (target <1%), upstream response times (alarm if >500ms), and cache hit ratio (should exceed 80% for static-heavy sites). Use error logs judiciously—setting error_log /var/log/nginx/error.log warn; reduces noise while capturing critical events.
Optimization varies by use case. For static file serving, combine sendfile, tcp_nopush, and high worker_connections. Enable gzip on with gzip_types text/css application/javascript image/svg+xml; gzip_min_length 1000; gzip_vary on; to compress text assets—benchmarks show 70% size reduction. For PHP-FPM backends, adjust fastcgi_buffer_size and fastcgi_buffers to prevent Nginx from blocking on slow responses (e.g., fastcgi_buffers 256 16k; fastcgi_busy_buffers_size 512k;). Use proxy_buffering off for streaming APIs like WebSockets or video. For high-traffic APIs, enable HTTP/2 with listen 443 ssl http2; to multiplex requests over a single connection, reducing latency by up to 20%. Tune keepalive_requests (default 100) higher for persistent connections. For SSL-heavy workloads, enable session resumption via ssl_session_cache shared:SSL:20m; ssl_session_timeout 1h;—this reduces handshake CPU by 50%. Use OCSP stapling to avoid browser revocation checks. Always test with tools like ab (ApacheBench) or wrk—focus on requests per second and tail latency (p99). A single AWS t3.medium instance can serve 40,000+ concurrent connections with proper tuning.
Misconfiguration is the primary cause of Nginx failures. Pitfall 1: Symlinks and location order. Nginx evaluates location blocks in a specific order: exact matches (=) first, then prefix matches, then regex (~). A common mistake is placing regex locations before prefix—use ^~ to force prefix priority. Pitfall 2: Unclosed or conflicting server blocks. Validate configuration with nginx -t before reloading; use systemctl reload nginx for zero-downtime changes. Pitfall 3: File descriptor limits. If Nginx logs worker_connections exceed open file resource limit, raise worker_rlimit_nofile in the events block and ulimit -n system-wide (e.g., /etc/security/limits.conf). Pitfall 4: Timeout misalignment. If proxy_read_timeout (default 60s) is shorter than backend processing time, requests fail with 504 Gateway Timeout—set to 300s for slow endpoints. Pitfall 5: Inadequate buffer sizes. proxy_buffer_size (default 4KB) may truncate large headers from upstream servers, causing silent failures. Set to 8k for most APIs. Debugging involves increasing log verbosity: debug_connection 192.168.1.100; in the events block logs every event for that client. Use tcpdump to inspect raw traffic, and strace -p to identify blocking system calls. For mysterious 499 errors (client closed connection), check client timeouts or load balancer health checks closing idle connections.
Modern applications demand protocol support beyond HTTP/1.1. HTTP/2 requires SSL and is enabled via listen 443 ssl http2;. It multiplexes streams over one TCP connection, reducing head-of-line blocking. For optimal performance, ensure ssl_buffer_size aligns with your average response size (e.g., 4k). WebSocket proxying requires explicit protocol upgrade: proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";. Set proxy_read_timeout high (e.g., 3600s) for long-lived socket connections. gRPC support (Nginx 1.13.10+) allows proxying of HTTP/2 RPCs: include grpc_pass and set client_max_body_size 0 for streaming. For server-sent events (SSE), disable buffering: proxy_buffering off; proxy_cache off;. These advanced protocols require careful load balancing—ensure upstream servers support the same protocol version. Nginx’s ngx_stream_core_module also enables TCP/UDP load balancing for database and SSH traffic: define stream { upstream db_backend { server 10.0.0.1:3306; } server { listen 3306; proxy_pass db_backend; } }. This bypasses HTTP overhead for non-web protocols.
Deploying Nginx in Docker or Kubernetes requires configuration adjustments. Use the official Nginx Docker image: FROM nginx:alpine for a lightweight (~20MB) container. Pass custom nginx.conf via volumes: docker run -v /host/nginx.conf:/etc/nginx/nginx.conf:ro -p 80:80 nginx. For Kubernetes, use a ConfigMap to manage configuration without rebuilding images: kubectl create configmap nginx-config --from-file=nginx.conf. Ingress controllers (e.g., nginx-ingress for Kubernetes) use Nginx under the hood—understand annotations like nginx.ingress.kubernetes.io/proxy-body-size for tuning. For CI/CD, validate configuration in pre-merge hooks: nginx -t -c nginx.conf. Use health checks in deployment pipelines: curl -f http://localhost/nginx_status should return HTTP 200. Automate certificate management with Let’s Encrypt and certbot renewal hooks that reload Nginx. For immutable infrastructure, bake configuration into images rather than mounting volumes. Monitor logs in ephemeral containers using docker logs or Kubernetes kubectl logs—consider centralized logging with Fluentd. Performance profiling in containers is similar to bare metal, but account for cgroup limits: worker_processes auto; reads container CPU quotas correctly.