Web ServerWeb Servers

Part of the Backend Roadmap knowledge base.

Overview

A web server is a program that listens for HTTP(S) requests over the network and returns HTTP responses. In the classic sense it serves static content (HTML, CSS, JavaScript, images, fonts) directly from disk. In modern architectures it almost always plays a second, more important role: sitting in front of your application as a reverse proxy — terminating TLS, routing requests, load balancing, caching, compressing, and shielding the app from raw internet traffic.

Understanding web servers matters because they are the first hop of every request that reaches your backend. Getting the web server layer right gives you free wins in performance (caching, compression, connection reuse), security (TLS, rate limiting, request filtering), and operability (graceful reloads, access logs, health checks) — before a single line of your application code runs.

This note complements two related sections in this knowledge base:

• ../devops/en/06-web-servers-and-proxies.md — the operations/DevOps angle (deployment, config management, TLS automation at scale).
• The network-engineer topics — the lower-level networking angle (TCP, TLS handshakes, DNS, HTTP/2, HTTP/3).

Here we focus on the backend developer’s view: how a web server fits in front of your app, what a reverse proxy actually does, and how to configure one correctly.

Related notes: Internet and Web Fundamentals · Caching · Scalability and Reliability.

Fundamentals

Static vs dynamic content

A good rule: let the web server serve static assets (it is optimized for sendfile, byte ranges, caching headers) and let the app server handle dynamic logic. The web server proxies dynamic requests to the app.

The request path in front of an app server

A typical request flow for a modern web app:

The web server / reverse proxy is the boundary between the “public edge” and your “application internals”. It speaks HTTP to the world and forwards to the app over a private, often plaintext, upstream connection (HTTP or a Unix socket).

Why not expose the app server directly?

Most application servers can speak HTTP directly, but you generally shouldn’t expose them to the internet:

• App servers are optimized for running your code, not for slow-client handling, TLS at scale, or serving files efficiently.
• A reverse proxy buffers slow clients so a single slow uploader doesn’t tie up an expensive app worker (mitigates slow-loris style problems).
• The proxy centralizes cross-cutting concerns (TLS, gzip, rate limiting, headers, logging) so every app doesn’t reimplement them.

Key Concepts

Web server vs application server vs reverse proxy vs API gateway vs load balancer

These terms overlap and a single product (like Nginx) can play several roles at once. The distinction is about responsibility, not necessarily separate machines.

Key clarifications:

• A reverse proxy forwards requests to backends on behalf of clients. A forward proxy does the opposite — it forwards requests from clients out to the internet (e.g. a corporate egress proxy). “Reverse” is from the server’s perspective.
• A load balancer is a reverse proxy whose main focus is distribution + health checking. An L4 load balancer routes by IP/port without reading HTTP; an L7 load balancer reads HTTP and can route by path/host/header.
• An API gateway is a reverse proxy plus API-specific policy (authentication, API keys, rate limits, request shaping). It is the “smart” edge for API traffic.
• These roles compose: internet → load balancer → several Nginx reverse proxies → app servers is a common, healthy layout.

Reverse proxy responsibilities

A reverse proxy earns its place by handling cross-cutting concerns in one place:

TLS termination

The proxy holds the certificate and private key, terminates TLS, and forwards plaintext HTTP to the upstream (over a trusted private network) — or re-encrypts (TLS passthrough / re-encryption) when the backend hop must also be encrypted. Terminating at the edge means you renew and manage certificates in one place. Caddy takes this further with automatic HTTPS via ACME/Let’s Encrypt out of the box.

Load balancing algorithms

Health checks (passive: mark a backend down after N failures; active: probe an endpoint) keep traffic away from dead instances.

Process and concurrency models

How a web server handles many simultaneous connections shapes its performance profile.

Event-driven servers (Nginx, Caddy) scale to very high concurrency with low memory because they don’t allocate a thread/process per connection. This is why Nginx became the standard reverse proxy for high-traffic sites.

Keep-alive, timeouts, and buffering

• Keep-alive reuses one TCP (and TLS) connection for multiple requests, avoiding repeated handshakes. Configure keepalive_timeout for clients and a keepalive connection pool to upstreams.
• Timeouts bound how long the server waits at each stage: client_header_timeout, client_body_timeout, send_timeout, and upstream proxy_connect_timeout / proxy_read_timeout. Sensible timeouts prevent resource exhaustion.
• Buffering (proxy_buffering on) lets the proxy read the whole upstream response, freeing the app worker quickly. Disable it (proxy_buffering off) for streaming/SSE/long-polling responses.

Best Practices

Survey of web servers

Rule of thumb: Nginx or Caddy as the reverse proxy in front; your app framework’s embedded/app server behind it. Caddy if you want zero-config HTTPS; Nginx if you want maximum control and ecosystem.

A real Nginx reverse-proxy config

Reverse proxy to an upstream app, with TLS, gzip, and basic response caching:

# /etc/nginx/nginx.conf (http context — key directives shown)

# Define a proxy cache zone: 10 MB of keys, up to 1 GB on disk.
proxy_cache_path /var/cache/nginx/app
                 levels=1:2
                 keys_zone=app_cache:10m
                 max_size=1g
                 inactive=60m
                 use_temp_path=off;

# Rate limit: 10 requests/sec per client IP, with a small burst allowance.
limit_req_zone $binary_remote_addr zone=req_per_ip:10m rate=10r/s;

# Upstream pool of application instances.
upstream app_backend {
    least_conn;                       # send to the least-busy instance
    server 127.0.0.1:8000 max_fails=3 fail_timeout=15s;
    server 127.0.0.1:8001 max_fails=3 fail_timeout=15s;
    keepalive 32;                     # reuse upstream connections
}

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

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

    # --- TLS termination ---
    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         HIGH:!aNULL:!MD5;
    ssl_session_cache   shared:SSL:10m;
    ssl_session_timeout 1d;

    # --- Security headers ---
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;

    # --- gzip compression ---
    gzip on;
    gzip_comp_level 5;
    gzip_min_length 256;
    gzip_types text/plain text/css application/json application/javascript
               text/xml application/xml image/svg+xml;
    gzip_vary on;

    # --- Serve static assets directly, cache hard in the browser ---
    location /static/ {
        root /var/www/example;
        expires 30d;
        access_log off;
        add_header Cache-Control "public, immutable";
    }

    # --- Proxy dynamic requests to the app, with response caching ---
    location / {
        limit_req zone=req_per_ip burst=20 nodelay;

        proxy_pass http://app_backend;

        # Preserve client info for the app.
        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;

        # Use HTTP/1.1 + keep-alive to the upstream.
        proxy_http_version 1.1;
        proxy_set_header Connection "";

        # Timeouts.
        proxy_connect_timeout 5s;
        proxy_send_timeout    30s;
        proxy_read_timeout    30s;

        # Response caching for cacheable GET/HEAD responses.
        proxy_cache            app_cache;
        proxy_cache_valid      200 301 302 10m;
        proxy_cache_valid      404 1m;
        proxy_cache_use_stale  error timeout updating http_500 http_502 http_503 http_504;
        proxy_cache_lock       on;   # collapse concurrent misses into one upstream fetch
        add_header X-Cache-Status $upstream_cache_status;  # HIT / MISS / EXPIRED — great for debugging
    }
}

Notes on the config:

• X-Forwarded-For / X-Forwarded-Proto are essential so the app sees the real client IP and scheme after TLS termination. Make sure your framework is configured to trust these headers only from the proxy.
• proxy_cache_lock on prevents a “thundering herd” of identical requests hitting the backend when a popular entry expires.
• X-Cache-Status surfaces whether a response was served from cache — invaluable when tuning. See Caching for cache-key and invalidation strategy.
• proxy_cache_use_stale improves resilience: serve slightly stale content if the backend is momentarily down.

Reload without dropping connections after editing config:

nginx -t            # validate config first — never reload a broken config
nginx -s reload     # graceful reload: new workers start, old ones drain

Tuning basics

Operational best practices

• Terminate TLS at the edge and keep certificates in one place; automate renewal (Certbot, or Caddy’s built-in ACME).
• Always nginx -t before reload, and use graceful reloads to avoid dropped requests during deploys.
• Let the web server serve static assets; only proxy dynamic requests to the app.
• Set and forward the right headers (X-Forwarded-*) and add security headers (HSTS, nosniff).
• Cache deliberately: cache what is safe, key correctly, expose X-Cache-Status, and have an invalidation plan.
• Rate-limit and buffer to protect app workers from abuse and slow clients.
• Health-check upstreams and configure max_fails / fail_timeout so traffic avoids dead instances.
• Match timeouts to reality: streaming/SSE endpoints need buffering off and longer read timeouts.
• Run multiple proxy instances behind a load balancer for the proxy tier’s own availability — see Scalability and Reliability.

References

• Nginx documentation
• Nginx reverse proxy guide (admin docs)
• Nginx content caching guide
• Apache HTTP Server documentation
• Apache mod_proxy documentation
• Caddy documentation (automatic HTTPS)
• MDN: What is a web server?
• roadmap.sh/backend