Nginx Configuration: Optimization & Security

Problem: stock Nginx can't handle the load

A client came with a typical Laravel 10 + PHP 8.3 project that was crashing under 1000 concurrent requests. Nginx from the repository gave frequent 502 errors, and static files loaded in 3–5 seconds. We found that worker_connections and fastcgi buffers were at defaults, caching was not configured, and rate limiting was absent. After deep optimization — aggressive caching, SSL tuning, and rate limiting — P99 latency dropped from 5 seconds to 200 ms, and the server now handles 12,000 RPS. Below are production-proven settings we apply to all projects. Contact us for a free audit.

We don't just copy generic configs; we adapt them to your specific stack. For some, micro-tuning worker_processes to CPU cores works best; for others, enabling sendfile and tcp_nopush is key. The important thing is to identify where the bottleneck is: disk, network, or backend.

Problems we solve

• Slow page loads due to inefficient static file handling and missing caching. For example, serving CSS/JS without gzip and without expires headers.
• Crashes under load due to misconfigured timeouts and fastcgi buffers. A common cause is worker_connections = 1024 when expecting 10k RPS.
• Memory leaks from poor worker_processes and worker_connections settings. On a VPS with 2 GB RAM, it's better to set auto or manually limit to 2 processes.
• DDoS attacks on APIs or login pages — without rate limiting, even a simple botnet can bring the server down. We use zones keyed by $binary_remote_addr with limits like 30/5 requests per minute.
• Insecure configuration: exposed server_tokens, weak SSL settings, missing HSTS.

Base configuration for Laravel/PHP

We use this template for 80% of PHP projects as a starting point.

# /etc/nginx/sites-available/myapp.conf
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;
    root /var/www/myapp/current/public;
    index index.php;

    # SSL
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;

    # Security headers
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header X-Frame-Options "DENY" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    charset utf-8;
    client_max_body_size 50M;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
        fastcgi_buffers 16 16k;
        fastcgi_buffer_size 32k;
        fastcgi_read_timeout 300;
    }

    # Static files — maximum caching
    location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|woff2?|ttf|eot)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
        access_log off;
    }

    # Deny access to hidden files
    location ~ /\. {
        deny all;
        access_log off;
        log_not_found off;
    }
}

Additional settings

Reverse Proxy for Node.js

If the backend is Node.js, replace fastcgi with proxy_pass:

upstream nodejs_app {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
    keepalive 32;
}

server {
    listen 443 ssl http2;

    location / {
        proxy_pass http://nodejs_app;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        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;
        proxy_cache_bypass $http_upgrade;
        proxy_read_timeout 300;
    }
}

Gzip and caching

A separate file for gzip and proxy_cache:

# /etc/nginx/conf.d/gzip.conf
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_min_length 1024;
gzip_types
    text/plain text/css text/xml text/javascript
    application/json application/javascript application/xml+rss
    application/atom+xml image/svg+xml font/ttf font/otf;

# Proxy cache (for caching backend responses)
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=app_cache:10m
                 max_size=1g inactive=60m use_temp_path=off;

location /api/public/ {
    proxy_cache app_cache;
    proxy_cache_valid 200 10m;
    proxy_cache_use_stale error timeout updating;
    add_header X-Cache-Status $upstream_cache_status;
    proxy_pass http://app;
}

Rate Limiting

Protect APIs and login:

limit_req_zone $binary_remote_addr zone=api:10m rate=30r/m;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location /api/ {
    limit_req zone=api burst=10 nodelay;
    limit_req_status 429;
    proxy_pass http://app;
}

location /login {
    limit_req zone=login burst=2 nodelay;
    proxy_pass http://app;
}

Logging

JSON format for integration with monitoring systems:

log_format combined_json escape=json
    '{'
        '"time":"$time_iso8601",'
        '"remote_addr":"$remote_addr",'
        '"method":"$request_method",'
        '"uri":"$request_uri",'
        '"status":$status,'
        '"request_time":$request_time,'
        '"bytes_sent":$bytes_sent,'
        '"http_referer":"$http_referer",'
        '"http_user_agent":"$http_user_agent"'
    '}';

access_log /var/log/nginx/access.log combined_json;
error_log  /var/log/nginx/error.log warn;

Configuration testing

Simple commands to verify:

Before/After comparison

Our process

1. Audit current configuration — review log files, load, identify bottlenecks.
2. Design architecture — choose the scheme (reverse proxy, standalone, with upstream).
3. Implement — configure virtual hosts, SSL (Let's Encrypt or your certificate), rate limiting, caching, gzip, security headers, logging, worker optimization.
4. Test — load testing (ab, wrk), security check (SSL Labs), log analysis.
5. Document — configuration diagram, management commands, update instructions.

What's included

• Full configuration documentation with explanations of every parameter.
• Automation scripts for deployment (Ansible or Docker Compose).
• Monitoring and alerting setup (Prometheus + Alertmanager or equivalent).
• Training for your team: how to make changes, restart, and analyze logs.
• 30-day guarantee on configuration stability with support.

Our experience

We've been working with Nginx for over 8 years. In that time, we've configured more than 100 production servers for projects ranging from landing pages to high-traffic e-commerce platforms. For each project, we deliver documentation and a 30-day guarantee on configuration stability.

According to official Nginx documentation, proper tuning at the OS level (sysctl) and worker settings can increase throughput by up to 50%.

How to configure rate limiting for DDoS protection?

Each scenario gets its own zone. For APIs, we use a limit of 30 requests per minute per IP with a burst of 10. For login, 5 requests per minute with a burst of 2. Always set limit_req_status 429 and log rejected requests. Combine with geo-filtering and fail2ban. This approach handles even basic DDoS attacks.

Why does SSL affect Core Web Vitals?

The SSL handshake directly impacts LCP and TTFB. If weak ciphers (TLS 1.0) or missing OCSP Stapling are used, handshake time can reach 300 ms. We use only TLS 1.2/1.3, modern ciphers (ECDHE+AES-GCM), and enable OCSP Stapling. This reduces TTFB by 15–20% without extra cost.

Step-by-step configuration check

1. Run nginx -t to verify syntax.
2. Generate load with ab -n 1000 -c 100 and monitor response statuses.
3. Check security headers via curl: curl -I https://example.com | grep -i strict.
4. Test rate limiting: send 100 requests in 1 minute and confirm that 429 appears after exceeding the limit.

Get a free engineer consultation — we'll evaluate your project and propose an optimal Nginx configuration plan. Contact us for an audit of your current configuration.

We regularly encounter a situation: "The site is not opening" at 3 a.m. — and it turns out that the VPS disk is full because nginx logs haven't been rotated for six months. Or the server went down under load on the day of an advertising campaign launch because the shared hosting had a limit of 50 concurrent connections. Setting up hosting and deployment is not about "where it's cheaper" but about what happens when something goes wrong. Our team helps avoid such incidents by designing infrastructure that accounts for real load patterns.

When to choose Vercel and Netlify?

Vercel is built for Next.js — deploy in one push, preview deployments for every PR, automatic CDN, Edge Functions, ISR without configuration. For frontend projects and JAMstack, it's the optimal choice: no operational overhead, time-to-deploy measured in minutes.

Real limitations: Vercel Serverless Functions run in us-east-1 by default (latency for Europe +80–100ms), Function timeout 300 seconds on Pro, Bandwidth 1TB/month on Pro. For heavy backend, you need workers or a separate server.

Netlify is closer to static sites and Edge Functions based on Deno Deploy. Build minutes are the main limitation on the free tier.

Why is Docker the foundation of predictable deployment?

"It works on my machine" — classic. Docker solves this through environment containerization. But a bad Dockerfile creates new problems.

A typical mistake: copying everything into the image without .dockerignore, resulting in an 800MB image instead of 80MB. node_modules inside the image weighs as much. Correct approach: multi-stage build.

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json
EXPOSE 3000
CMD ["npm", "start"]

Final image: 180MB instead of 1.2GB. CI build time is reduced due to layer caching — if package.json hasn't changed, the layer with npm ci is taken from cache.

Docker Compose for local development and simple production scenarios: application + PostgreSQL + Redis in one configuration. For production on a single server, it's a perfectly viable option if there's no requirement for horizontal scaling.

More about containerization — Wikipedia: Docker.

How to set up Nginx as a reverse proxy?

Nginx in front of the application is standard for VPS and dedicated servers. Main functions: SSL termination, gzip, static files, rate limiting, upstream load balancing.

A configuration often done incorrectly: worker_processes auto — number of processes equals CPU count. worker_connections 1024 — that's 1024 per worker process. With 4 CPUs and 1024 connections = 4096 concurrent connections. For a high-traffic site, you need worker_connections 4096 and set keepalive_timeout 65.

For static assets with hash in the filename:

location ~* \.(js|css|woff2|png|webp)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

immutable tells the browser: don't revalidate this file even on hard refresh. This only works correctly with content-hashed filenames (which Vite/webpack do by default). Documentation — Wikipedia: Nginx.

AWS: flexibility and complexity

EC2 + Auto Scaling Group — classic for horizontal scaling. AMI with pre-installed application, Launch Template, ASG with min/desired/max instances, Application Load Balancer. When CPU > 70% for 3 minutes — scale out, when CPU < 30% for 15 minutes — scale in. Health check via ALB removes unhealthy instances from rotation.

ECS Fargate — containers without managing EC2. Deploy a Docker image, specify CPU/memory (512 CPU units = 0.5 vCPU, from 512MB memory), Fargate launches it. More expensive than Lambda, but no cold start and no timeout limitations. Suitable for long-running processes, WebSocket servers, heavy workers.

RDS for PostgreSQL with Multi-AZ: automatic failover in 1–2 minutes when primary fails. Read Replicas for scaling reads. RDS Proxy for connection pooling — Lambda functions cannot hold long-term connections, the proxy buffers this.

Kubernetes: when it is justified

K8s adds significant operational complexity. Justified when: multiple teams deploy independent services, fine-grained resource allocation per service is needed, canary deployments and blue/green without downtime are required.

AWS EKS, GKE, or managed k8s from Hetzner (cheaper). Helm charts for standard services. Horizontal Pod Autoscaler based on CPU and custom metrics (RPS via Prometheus).

For most startups and medium-sized projects, Kubernetes is overkill. ECS or Fly.io provide 80% of the capabilities with 20% of the operational complexity.

Monitoring and alerting

A server without monitoring is waiting for an incident. Minimal stack: Prometheus + Grafana (or Grafana Cloud for managed), alerting on disk > 80%, memory > 85%, CPU > 90% over 5 minutes, error rate > 1%. Uptime via Better Uptime or Upptime (self-hosted).

Logs: Loki + Grafana or CloudWatch Logs Insights. Structured JSON logs (winston, pino) are mandatory — otherwise, log searching becomes a pain.

What is included in hosting setup

• Audit of current infrastructure and load profiling
• Selection of target architecture (VPS, AWS, serverless, Kubernetes)
• Setting up CI/CD pipeline (GitHub Actions, GitLab CI) with automatic deployment
• IaC via Terraform or Pulumi (infrastructure as code)
• Configuration of Nginx, SSL certificates, HTTP/2, brotli
• Monitoring and alerting (Prometheus + Grafana, PagerDuty)
• Documentation of runbooks and team training

Additionally, contact us if you need migration from current hosting or integration with external services.

Work process

1. Audit of current infrastructure (2–5 days)
2. Selection of target architecture with load and budget justification (1–3 days)
3. Setting up CI/CD pipeline (GitHub Actions, GitLab CI) (2–5 days)
4. IaC via Terraform or Pulumi (3–10 days)
5. Setting up monitoring and alerting (2–5 days)
6. Documentation of runbooks and team training (1–3 days)

Our experience — 7 years on the market, over 50 projects, guarantee of operability after deployment.

Timeline

• Basic deployment on VPS with Docker + Nginx + CI/CD: 1–2 weeks.
• Setting up AWS infrastructure with Auto Scaling, RDS, CDN: 3–6 weeks.
• Migration to EKS from scratch: 6–12 weeks.
• Setting up Vercel/Netlify for JAMstack: 3–5 days.

The cost is calculated individually depending on complexity and scope of work. Get a consultation — we'll evaluate your architecture in one day.