The web server stack: nginx, PHP-FPM and Node

01What a web server does, and how nginx does it

Think of a busy restaurant. The host at the door greets every guest, hands out menus (static files) and sends real orders to the kitchen (your application). The web server is that host. It listens on ports 80 and 443, parses the HTTP request, decides who should answer it and sends the response back. nginx is event-driven: a small number of worker processes (usually one per CPU core) each handle thousands of connections using non-blocking I/O, so an idle or slow client costs almost nothing. Apache traditionally used a process or thread per connection (prefork/worker MPMs); its modern event MPM narrowed the gap, and Apache still shines with per-directory .htaccess files and its huge module ecosystem. In practice many stacks, including most hosting panels, put nginx in front for static files and TLS and keep Apache behind it for compatibility.

• Master process: reads config, opens ports, manages workers.
• Worker processes: handle connections; worker_processes auto matches CPU cores.
• Apache .htaccess is convenient but is read on every request; nginx has no equivalent, by design.

02Server blocks and locations

nginx config is a tree. The http context holds global settings. Inside it, each server block is one virtual host, chosen by the port and the Host header (server_name). Inside a server, location blocks match the URL path and decide what happens: serve a file, pass to PHP, proxy to Node, or deny. Location matching has rules worth memorising: exact matches (=) win first, then the longest prefix match, unless a regular-expression location (~) also matches, in which case the first matching regex wins (a ^~ prefix stops regex checks). try_files is the workhorse: it checks for a real file, then a directory, then falls back to an application entry point. On Ubuntu, sites live in /etc/nginx/sites-available and are enabled with a symlink in sites-enabled.

1server {
2    listen 80;
3    server_name static.example.com;
4    root /var/www/static/public;
5    index index.html;
6 
7    location / {
8        try_files $uri $uri/ =404;
9    }
10 
11    location ~* \.(css|js|svg|png|jpg|webp|woff2)$ {
12        expires 30d;
13        access_log off;
14    }
15 
16    location ~ /\.(?!well-known) {
17        deny all;
18    }
19}

03PHP-FPM: how nginx runs PHP

nginx cannot execute PHP itself. It forwards the request over the FastCGI protocol to PHP-FPM (FastCGI Process Manager), a separate service that keeps a pool of PHP worker processes ready. The connection is usually a Unix socket such as /run/php/php8.5-fpm.sock (PHP 8.5 is the default on Ubuntu 26.04; 24.04 ships 8.3). A pool is a group of workers with its own user, socket and limits. Give each app its own pool running as its own system user: one compromised site then cannot read another site's files, and one slow app cannot eat all the workers. pm = dynamic scales workers between limits; pm.max_children is the hard cap, so size it as roughly (RAM for PHP) divided by (average worker memory, often 40 to 80 MB for Laravel). When every child is busy, requests queue and you see 502/504 errors and 'server reached pm.max_children' in the FPM log.

1; /etc/php/8.5/fpm/pool.d/api.conf
2[api]
3user = api
4group = api
5listen = /run/php/php8.5-fpm-api.sock
6listen.owner = www-data
7listen.group = www-data
8pm = dynamic
9pm.max_children = 20
10pm.start_servers = 4
11pm.min_spare_servers = 2
12pm.max_spare_servers = 6
13pm.max_requests = 500
14request_terminate_timeout = 60s

04A Laravel API behind nginx

Laravel has a single entry point, public/index.php, and the document root must point at the public folder so that .env, storage and vendor are never reachable from the web. try_files serves real files first and sends everything else to index.php with the query string intact. Using $realpath_root instead of $document_root matters when you deploy with a 'current' symlink: PHP then sees the resolved release path, so OPcache does not keep serving the old release after the symlink switches. The certificate paths below are what certbot creates for Let's Encrypt. http2 on is the modern way to enable HTTP/2; the old 'listen 443 ssl http2' form is deprecated since nginx 1.25.1.

1server {
2    listen 443 ssl;
3    http2 on;
4    server_name api.example.com;
5    root /var/www/api/current/public;
6    index index.php;
7    ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
8    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;
9    client_max_body_size 20m;
10 
11    location / { try_files $uri $uri/ /index.php?$query_string; }
12 
13    location ~ \.php$ {
14        include snippets/fastcgi-php.conf;
15        fastcgi_pass unix:/run/php/php8.5-fpm-api.sock;
16        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
17        fastcgi_param DOCUMENT_ROOT $realpath_root;
18    }
19    location ~ /\.(?!well-known) { deny all; }
20}

05A Next.js frontend as a reverse proxy

A Node app (Next.js, NestJS, Express) is its own HTTP server listening on a local port such as 127.0.0.1:3000. nginx acts as a reverse proxy: it accepts the public HTTPS connection and forwards the request to that port, adding headers so the app knows the real client IP and protocol. Bind the Node app to 127.0.0.1 so it is never reachable directly. Keep the process alive with pm2 (pm2 start npm --name web -- start, then pm2 startup and pm2 save) or a systemd unit with Restart=always. The map block belongs in the http context; it lets WebSocket upgrades through while keeping normal requests on reusable keepalive connections. Add a second server block on port 80 that returns 301 to HTTPS, and enable gzip (gzip_types for CSS, JS, JSON, SVG); Brotli needs an extra module, or you can let a CDN such as Cloudflare compress at the edge.

1map $http_upgrade $connection_upgrade { default upgrade; '' ''; }
2upstream web_app { server 127.0.0.1:3000; keepalive 16; }
3server {
4    listen 443 ssl;
5    http2 on;
6    server_name example.com;
7    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
8    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
9 
10    location / {
11        proxy_pass http://web_app;
12        proxy_http_version 1.1;
13        proxy_set_header Host $host;
14        proxy_set_header X-Real-IP $remote_addr;
15        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
16        proxy_set_header X-Forwarded-Proto $scheme;
17        proxy_set_header Upgrade $http_upgrade;
18        proxy_set_header Connection $connection_upgrade;
19    }
20}

06Zero-downtime reloads and deploys

Never restart nginx to apply a config change. Test it, then reload: the master process reads the new config, starts new workers and lets old workers finish their in-flight requests before exiting. If the test fails, nothing changes and the old config keeps serving. The same idea applies to the apps. PHP-FPM supports a graceful reload. For Laravel, deploy each release into its own folder, run composer install and migrations there, then switch a 'current' symlink atomically and reload PHP-FPM; rolling back is just pointing the symlink back. Restart queue workers (php artisan queue:restart) so they pick up the new code. For Node, pm2 reload in cluster mode restarts instances one by one; with a single fork-mode instance it is effectively a restart, so run at least two instances if you need true zero downtime.

1# nginx: validate, then graceful reload
2sudo nginx -t && sudo systemctl reload nginx
3 
4# Laravel release switch (atomic symlink swap)
5ln -sfn /var/www/api/releases/2026-11-05_1200 /var/www/api/current
6sudo systemctl reload php8.5-fpm
7php /var/www/api/current/artisan queue:restart
8 
9# Node: rolling restart of a pm2 cluster
10pm2 reload web

07Hosting panels vs a plain server

Panels such as Plesk and cPanel install and manage this whole stack for you: web server, PHP versions, databases, mail, DNS, certificates and backups, all through a web UI. They are great when many small sites need to be managed by non-specialists, or when you sell hosting. The cost is control and overhead. Panels add licence fees, extra services that use memory and need patching, their own config templates that overwrite hand edits, and a bigger attack surface (the panel itself is a login page on the internet). A plain server with nginx, PHP-FPM, Node and a few scripts is leaner and fully understandable, but you own every piece: updates, certificates, backups and monitoring. For a handful of apps run by an engineer, plain is usually better; for dozens of brochure sites and mailboxes, a panel can still be the pragmatic choice.

08Buffering, slow clients and streaming responses

One of nginx's most valuable jobs is invisible: buffering. When a phone on a weak connection uploads a form, nginx reads the whole request body first (in memory up to client_body_buffer_size, then in a temporary file) and only then hands it to PHP-FPM or Node. On the way back it reads the full upstream response quickly into proxy or FastCGI buffers and trickles it to the slow client itself. The expensive application worker is freed in milliseconds instead of being held for seconds by someone on a train. The exception is streaming: Server-Sent Events, long polling and streamed AI or report responses must reach the client as they are produced. For those locations turn proxy buffering off and raise proxy_read_timeout, which defaults to 60 seconds between two reads. An app can also disable buffering per response with the X-Accel-Buffering: no header.

1location /events/ {
2    proxy_pass http://web_app;
3    proxy_http_version 1.1;
4    proxy_set_header Connection "";
5    proxy_set_header Host $host;
6    proxy_buffering off;          # send bytes as soon as they arrive
7    proxy_cache off;
8    proxy_read_timeout 1h;        # default 60s would cut idle streams
9}

09Microcaching: surviving a traffic spike

For pages that are the same for every anonymous visitor (a product listing, a public API response), nginx can cache the upstream response for as little as one second. That sounds useless, but under 500 requests per second it turns 500 PHP executions into one. fastcgi_cache_lock makes concurrent requests for the same uncached key wait for a single upstream fetch instead of stampeding PHP, and fastcgi_cache_use_stale with updating serves the slightly old copy while one request refreshes it in the background. The danger is caching personal data. Only cache GET and HEAD for anonymous users: bypass the cache whenever a session cookie or Authorization header is present, and never cache responses that set cookies. The X-Cache header (HIT, MISS, BYPASS, STALE) lets you verify behaviour with curl -I. proxy_cache works the same way in front of Node apps.

1# http context
2fastcgi_cache_path /var/cache/nginx/api levels=1:2 keys_zone=api_cache:50m
3                   max_size=1g inactive=10m use_temp_path=off;
4 
5# inside location ~ \.php$
6fastcgi_cache api_cache;
7fastcgi_cache_key "$scheme$request_method$host$request_uri";
8fastcgi_cache_valid 200 1s;
9fastcgi_cache_lock on;
10fastcgi_cache_use_stale error timeout updating http_500 http_503;
11fastcgi_cache_background_update on;
12fastcgi_cache_bypass $cookie_app_session $http_authorization;
13fastcgi_no_cache     $cookie_app_session $http_authorization;
14add_header X-Cache $upstream_cache_status always;

10Rate limiting with limit_req

limit_req implements a leaky bucket per key, usually the client address. limit_req_zone lives in the http context and defines the key, a shared memory zone and the rate (r/s or r/m). On 64-bit systems each state takes 128 bytes, so a 10m zone tracks about 80,000 addresses. limit_req inside a location applies it. burst is the size of the queue for requests above the rate. Without nodelay those queued requests are delayed to match the rate, which keeps upstreams smooth but makes pages feel slow; with nodelay they are served immediately and only requests beyond the burst are rejected. delay=N (since 1.15.7) mixes both. Rejections default to 503, which looks like an outage to monitoring, so set limit_req_status 429. Use $binary_remote_addr rather than $remote_addr to save memory, and configure real IPs first if a CDN sits in front, or every visitor shares the CDN's bucket.

1# http context
2limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
3limit_req_zone $binary_remote_addr zone=api:10m   rate=10r/s;
4limit_req_status 429;
5 
6# server context
7location = /api/login {
8    limit_req zone=login burst=5 nodelay;
9    try_files $uri /index.php?$query_string;
10}
11location /api/ {
12    limit_req zone=api burst=20 nodelay;
13    try_files $uri /index.php?$query_string;
14}

11Edge cases: default servers, real IPs and connection limits

If a request's Host header matches no server_name, nginx hands it to the default server for that port, which is the first one defined unless one is marked default_server. Scanners that hit your IP directly would then see your first site and, over HTTPS, its certificate, revealing which domains live there. A catch-all server that rejects the TLS handshake (ssl_reject_handshake, nginx 1.19.4+) and closes plain HTTP with the non-standard 444 avoids that. Behind Cloudflare or a load balancer, use the realip module: set_real_ip_from for each trusted proxy range and real_ip_header CF-Connecting-IP or X-Forwarded-For, so logs, rate limits and fail2ban see the visitor. Never trust that header from untrusted sources. Finally, capacity: worker_processes times worker_connections caps concurrent connections, and a proxied request uses two (client plus upstream), so raise worker_rlimit_nofile along with worker_connections.

1server {
2    listen 80 default_server;
3    listen 443 ssl default_server;
4    server_name _;
5    ssl_reject_handshake on;   # no certificate leaked to IP scanners
6    return 444;                # close the connection without a response
7}
8 
9# http context, behind Cloudflare (one line per range from cloudflare.com/ips)
10set_real_ip_from 173.245.48.0/20;
11real_ip_header CF-Connecting-IP;