Mastering Nginx: From Static Servers to Advanced Load Balancing and Reverse Proxy

1. Deploying a Simple Static Server

Nginx can serve static resources directly. Create a /usr/local/var/www/html directory, place a test.html file inside, and configure nginx.conf to point the root to this path.

user  mingday  staff;
http {
    server {
        listen       80;
        server_name  localhost;
        client_max_body_size 1024M;
        location / {
            root   /usr/local/var/www/html;
            index  index.html index.htm;
        }
    }
}

Access http://localhost/ to view the default Nginx page and http://localhost/test.html for the custom file.

2. Understanding location Directives and Regex

The location block maps request URIs to filesystem paths or upstream servers. Common directives include:

server : defines a virtual server; multiple server blocks can exist.

listen : IP address and port to listen on.

server_name : domain name for the virtual host.

location : matches a URI pattern; can use exact ( =), prefix ( ^~), case‑sensitive regex ( ~), or case‑insensitive regex ( ~*).

root : filesystem path for static files.

index : default file when a directory is requested.

Regex symbols such as ., ?, +, *, \d, ^, $, {n}, [a‑z], and grouping (a|b) are used to fine‑tune matches. Captured groups can be referenced with $1, $2, etc.

3. Setting Up a Reverse Proxy

To forward client requests to a backend Java application running on port 8081, use the proxy_pass directive:

server {
    listen       80;
    server_name  localhost;
    location / {
        proxy_pass http://localhost:8081;
        proxy_set_header Host $host:$server_port;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
    }
}

Now http://localhost/ proxies to http://localhost:8081.

4. Load Balancing Strategies

Define an upstream block and reference it in proxy_pass. Common methods:

Round Robin (default) : distributes requests sequentially.

Weight : weight parameter skews distribution proportionally.

ip_hash : hashes client IP so a client consistently reaches the same backend (useful for session‑based apps).

fair (third‑party): prefers servers with lower response time.

url_hash (third‑party): hashes the request URI, useful for cache‑oriented backends.

# Round robin with weight
upstream web_servers {
    server localhost:8081 weight=1;
    server localhost:8082 weight=3;
    server localhost:8083 weight=4 backup;
}

# ip_hash example
upstream hash_test {
    ip_hash;
    server localhost:8080;
    server localhost:8081;
}

# fair (requires third‑party module)
upstream fair_backend {
    fair;
    server localhost:8080;
    server localhost:8081;
}

# url_hash example
upstream url_hash_backend {
    hash $request_uri;
    hash_method crc32;
    server localhost:8080;
    server localhost:8081;
}

5. Static‑Dynamic Separation (动静分离)

Separate static assets from dynamic requests by routing static file extensions to a dedicated root and proxying all other traffic to the application servers:

upstream web_servers {
    server localhost:8081;
    server localhost:8082;
}

server {
    listen 80;
    server_name localhost;
    set $doc_root /usr/local/var/www;
    location ~* \.(gif|jpg|jpeg|png|bmp|ico|swf|css|js)$ {
        root $doc_root/img;
    }
    location / {
        proxy_pass http://web_servers;
        proxy_set_header Host $host:$server_port;
    }
    error_page 500 502 503 504 /50x.html;
    location = /50x.html { root $doc_root; }
}

6. Additional Useful Directives

return : send a status code or redirect, e.g., return 301 http://example.com/moved;.

rewrite : modify the URI with regex, optionally ending processing with break or issuing a redirect.

error_page : map error codes to custom pages, e.g., error_page 404 /404.html;.

log_format and access_log : define log layout and enable logging (ensure gzip on for compression).

deny : block access to matching locations, e.g., deny all; for certain file types.

Built‑in variables : $remote_addr, $host, $request_uri, $uri, $document_root, $http_user_agent, etc., can be used throughout configuration.

These directives together enable fine‑grained control over request handling, security, and observability in Nginx deployments.