Nginx Configuration for Web Servers

Master Nginx configuration for web servers. Learn about server blocks, reverse proxying, SSL termination, caching, and performance tuning.

Nginx Architecture

Nginx uses an event-driven, asynchronous architecture that handles thousands of concurrent connections with minimal memory. Unlike Apache's process-per-connection model, Nginx uses a small number of worker processes, each handling many connections simultaneously.

Master Process
├── Worker Process 1 (handles ~1024 connections)
├── Worker Process 2
└── Worker Process N (one per CPU core)

This architecture is why Nginx excels at serving static files, reverse proxying, and handling high-concurrency workloads.

Server Block Configuration

Each website or application gets its own server block (equivalent to Apache's VirtualHost):

# /etc/nginx/sites-available/example.com
server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example.com/public;
    index index.html;

    # Logging
    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;

    # Static file caching
    location ~* \.(css|js|jpg|png|gif|ico|woff2)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
    }

    location / {
        try_files $uri $uri/ =404;
    }
}

Enable the site with a symlink: ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

Reverse Proxy Configuration

Nginx is widely used as a reverse proxy in front of application servers (Gunicorn, Node.js, Tomcat):

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://127.0.0.1:8000;
        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;

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

The proxy_set_header directives ensure the upstream application receives the real client IP and protocol, not the proxy's.

SSL/TLS Termination

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

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Modern SSL configuration
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers off;

    # HSTS (1 year)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

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

Performance Tuning

Key directives for high-performance Nginx:

# /etc/nginx/nginx.conf
worker_processes auto;           # One per CPU core
worker_connections 2048;         # Max connections per worker

# Compression
gzip on;
gzip_comp_level 5;
gzip_types text/plain text/css application/json application/javascript text/xml;
gzip_min_length 256;

# Buffer sizes
client_body_buffer_size 16k;
client_max_body_size 50m;
proxy_buffer_size 128k;
proxy_buffers 4 256k;

# File serving optimization
sendfile on;
tcp_nopush on;
tcp_nodelay on;

Testing and Reloading

Always test configuration before applying changes:

# Test configuration syntax
sudo nginx -t

# Reload without downtime (graceful)
sudo systemctl reload nginx

# View active configuration
nginx -T

A failed nginx -t means the configuration has errors and the reload will be rejected, keeping the previous working configuration active.

انظر أيضًا