Comprehensive Nginx Overview: Concepts, Configuration, and Use Cases
This article provides an in‑depth introduction to Nginx, covering its core concepts, advantages, request handling, proxy types, configuration syntax, directory structure, rate‑limiting mechanisms, load‑balancing strategies, high‑availability setup, and practical examples for static resource handling and virtual host deployment.
Nginx is a lightweight, high‑performance reverse‑proxy web server capable of handling tens of thousands of concurrent connections, widely used by major Chinese sites such as Sina, NetEase, and Tencent.
Key advantages include cross‑platform support, simple configuration, low memory consumption, built‑in health checks, GZIP compression, high stability, and asynchronous request handling.
It processes requests by matching listen and server_name directives to a server block, then locating the appropriate location block that maps the URI to a root directory or proxy target.
server {
listen 80;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
}Forward (正向) proxy sends client requests directly to the target server, while reverse proxy (反向) receives all requests, forwarding them to backend services based on defined rules.
Benefits of reverse proxy include hiding backend servers, improving security, and enabling load balancing.
Nginx configuration files reside under /usr/local/nginx, with nginx.conf as the main file, containing directives such as worker_processes, events, and http blocks.
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}Static resources are served directly from the html directory, and cross‑origin issues can be mitigated by proxying API requests through Nginx.
Virtual hosts can be configured based on domain name, port, or IP, with examples showing separate document roots for www.lijie.com and bbs.lijie.com, as well as port‑based routing.
# Domain‑based virtual host
server {
listen 80;
server_name www.lijie.com;
location / {
root data/www;
index index.html index.htm;
}
}
# Port‑based virtual host
server {
listen 8080;
server_name 8080.lijie.com;
location / {
root data/www;
index index.html index.htm;
}
}The location directive matches URIs using exact, prefix, or regex patterns, with priority rules demonstrated through examples such as exact match, ^~, ~, and ~* patterns.
# Exact match
location = / { return 400; }
# Prefix match (case‑sensitive)
location ^~ /av { root /data/av/; }
# Regex match (case‑sensitive)
location ~ /media { alias /data/static/; }
# Regex match (case‑insensitive)
location ~* \.(jpg|gif|png|js|css)$ { root /data/av/; }
# Fallback
location / { return 403; }Rate limiting is implemented via the ngx_http_limit_req_module (token‑bucket) and ngx_http_limit_conn_module, with configurations for normal request rate, burst handling, and concurrent connection limits.
# Normal rate limiting
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/m;
server {
location /seckill.html {
limit_req zone=one;
proxy_pass http://lj_seckill;
}
}
# Burst with nodelay
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/m;
server {
location /seckill.html {
limit_req zone=one burst=5 nodelay;
proxy_pass http://lj_seckill;
}
}
# Connection limiting
limit_conn_zone $binary_remote_addr zone=myip:10m;
server {
location / {
limit_conn myip 10;
limit_conn myServerName 100;
}
}Two primary algorithms for traffic shaping are the leaky‑bucket (smooths bursts) and token‑bucket (allows bursts up to a defined capacity).
Static‑dynamic separation is achieved by directing static assets (images, CSS, JS) to Nginx for direct serving, while dynamic requests (e.g., JSP, servlet) are proxied to application servers like Tomcat.
location /image/ {
root /usr/local/static/;
autoindex on;
}Nginx load balancing supports multiple strategies: round‑robin (default), weighted, IP‑hash, fair (third‑party), and URL‑hash (third‑party), each illustrated with configuration snippets.
# Round‑robin
upstream backserver {
server 192.168.0.12;
server 192.168.0.13;
}
# Weighted
upstream backserver {
server 192.168.0.12 weight=2;
server 192.168.0.13 weight=8;
}
# IP‑hash
upstream backserver {
ip_hash;
server 192.168.0.12:88;
server 192.168.0.13:80;
}High availability is configured by setting appropriate proxy timeouts and fallback mechanisms, ensuring that if an upstream server fails, requests are routed to healthy nodes.
server {
listen 80;
server_name www.lijie.com;
location / {
proxy_pass http://backServer;
proxy_connect_timeout 1s;
proxy_send_timeout 1s;
proxy_read_timeout 1s;
index index.html index.htm;
}
}Access control can be enforced using if statements to block specific IPs or user agents, returning custom HTTP status codes such as 403 or 500.
# Block specific IP
if ($remote_addr = 192.168.9.115) { return 403; }
# Block Chrome browsers
if ($http_user_agent ~ Chrome) { return 500; }Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Selected Java Interview Questions
A professional Java tech channel sharing common knowledge to help developers fill gaps. Follow us!
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
