Nginx(读作"engine-x")诞生于2004年,最初是为了解决C10K问题——即Apache在当时难以高效处理的10,000个并发连接。如今,Nginx已成为全球最流行的Web服务器,运行于全球超过34%的网站,是大多数现代DevOps流水线的默认选择。
什么是Nginx?
Nginx 是一款多功能开源软件,可同时扮演多种角色:提供静态文件的Web服务器、将请求转发至后端的反向代理,以及在多台服务器间分配负载的负载均衡器。其异步事件驱动架构使单个worker进程无需创建新线程或进程即可同时处理数千个连接——这与Apache的thread-per-request模型截然不同。
可以将Nginx想象成办公楼的智能前台:来访者(HTTP请求)始终先经过前台,前台立即处理简单需求(如分发现成文件,即静态文件),对于复杂需求则引导访客到正确的部门(后端服务),而无需访客自行摸索前往楼上。
需要企业数据解决方案?
自 2019 年起,AlgoData 为企业提供数据工程、分析与 AI 解决方案。

Nginx的三大核心角色
Web服务器——高速提供静态内容
Nginx以极低延迟直接从磁盘提供HTML、CSS、JavaScript、图片和视频。由于无需为每个文件创建新进程或线程,即使在普通硬件上,Nginx也能每秒处理数百万个请求。这正是CDN和静态托管服务(如Netlify、Vercel自建架构)通常在边缘节点使用Nginx的原因。
反向代理——保护后端的中间层
在后端应用(Node.js、Python/Gunicorn、Go、PHP-FPM)前部署Nginx时,Nginx充当反向代理:接收来自互联网的所有请求,完成TLS终止(SSL termination),可选地缓存响应、启用gzip压缩,然后通过proxy_pass将请求转发给运行在localhost的后端。后端完全对外部互联网不可见。
负载均衡器——在多个实例间分配流量
当系统拥有多个后端实例(横向扩展)时,Nginx的upstream块充当第7层负载均衡器,按照round-robin、least_conn或ip_hash算法分配请求。这是实现微服务架构零停机部署的基础。
Nginx、Apache与IIS对比
如果应用大量依赖每目录.htaccess文件(共享托管、WordPress插件自动写入重写规则),Apache更为灵活,因为它会在每次请求时读取.htaccess。Nginx不支持.htaccess——所有配置必须集中写在nginx.conf文件中。
Nginx基础配置

以下是完整的nginx.conf配置文件,包含提供静态文件的server块、到后端的反向代理配置,以及上游负载均衡设置。
1# /etc/nginx/nginx.conf
2worker_processes auto; # 自动选择worker数量 = CPU核心数
3events {
4 worker_connections 1024; # 每个worker的最大连接数
5}
6
7http {
8 # --- Upstream: 用于负载均衡的后端池 ---
9 upstream app_backend {
10 least_conn; # 算法:优先选择连接数最少的服务器
11 server 10.0.0.10:8080 weight=3;
12 server 10.0.0.11:8080 weight=2;
13 server 10.0.0.12:8080 weight=1 max_fails=3 fail_timeout=30s;
14 }
15
16 # --- Server块:HTTPS + 反向代理 ---
17 server {
18 listen 443 ssl http2;
19 server_name example.com www.example.com;
20
21 ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
22 ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
23 ssl_protocols TLSv1.2 TLSv1.3;
24 ssl_ciphers HIGH:!aNULL:!MD5;
25
26 # 直接提供静态文件(图片、CSS、JS)
27 location /static/ {
28 root /var/www/myapp;
29 expires 30d;
30 add_header Cache-Control "public, immutable";
31 }
32
33 # 将其余所有请求代理到后端池
34 location / {
35 proxy_pass http://app_backend;
36 proxy_set_header Host $host;
37 proxy_set_header X-Real-IP $remote_addr;
38 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
39 proxy_set_header X-Forwarded-Proto $scheme;
40 proxy_connect_timeout 5s;
41 proxy_read_timeout 60s;
42 }
43 }
44
45 # --- HTTP → HTTPS 重定向 ---
46 server {
47 listen 80;
48 server_name example.com www.example.com;
49 return 301 https://$host$request_uri;
50 }
51}
重要指令说明
worker_processes auto— Nginx自动检测CPU核心数并启动相应数量的worker,最大化吞吐量。upstream— 定义后端池;least_conn指令选择连接数最少的服务器,而非默认的round-robin。proxy_set_header X-Real-IP— 将客户端真实IP传递给后端;否则后端只能看到Nginx的IP。expires 30d— 为静态文件启用HTTP缓存,显著减轻服务器负载。
实际应用场景
提供静态网站 / JAMstack
Nginx只需几行location块即可提供Next.js、Hugo或任何静态站点生成器的完整构建目录。Nginx提供静态文件的速度接近磁盘/网络速度上限——应用层的任何框架都无法与之竞争。
后端应用反向代理
这是最常见的使用场景:Nginx监听公开的80/443端口,后端应用运行在localhost:3000或localhost:8080,无需对外暴露。Nginx负责处理TLS、gzip和慢速客户端连接——后端只需专注于业务逻辑。
SSL终止
无需在每个后端服务上单独安装TLS,将所有证书管理集中在Nginx处理。后端通过内部HTTP(专用局域网内的明文传输)与Nginx通信——简化了配置,并通过Certbot轻松实现证书续签。
限速——防止API滥用
1http {
2 limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
3
4 server {
5 location /api/ {
6 limit_req zone=api_limit burst=20 nodelay;
7 proxy_pass http://app_backend;
8 }
9 }
10}
limit_req_zone指令按IP创建共享内存区,将请求限制为每秒10个,最大突发20个。超出阈值的请求直接在Nginx层收到HTTP 429响应,不消耗任何后端资源。
Nginx作为Kubernetes中的Ingress Controller

在Kubernetes集群中,Nginx Ingress Controller 是将HTTP/HTTPS服务暴露到集群外部最常用的方式。YAML格式的Ingress资源将域名和路径映射到内部Service:
1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4 name: myapp-ingress
5 annotations:
6 nginx.ingress.kubernetes.io/rewrite-target: /
7 nginx.ingress.kubernetes.io/limit-rps: "100"
8spec:
9 ingressClassName: nginx
10 tls:
11 - hosts:
12 - api.example.com
13 secretName: tls-secret
14 rules:
15 - host: api.example.com
16 http:
17 paths:
18 - path: /v1
19 pathType: Prefix
20 backend:
21 service:
22 name: api-v1-svc
23 port:
24 number: 80
25 - path: /v2
26 pathType: Prefix
27 backend:
28 service:
29 name: api-v2-svc
30 port:
31 number: 80
Nginx Ingress Controller读取Ingress资源并自动重新加载内部nginx.conf配置,无需重启Pod。这正是微服务系统实现滚动更新的方式:只需修改path规则,即可将流量从/v1逐步迁移到/v2。
在执行nginx -s reload之前,务必先运行nginx -t。该命令会检查整个nginx.conf及所有包含文件的语法,并在发现错误时返回具体提示。带有错误配置的重新加载会被自动拒绝——Nginx绝不会应用错误配置而导致服务中断。
Nginx性能优化
除基础配置外,以下几个常被忽视的指令对吞吐量有重大影响:
1http {
2 sendfile on; # 使用sendfile()系统调用——从磁盘到socket的零拷贝
3 tcp_nopush on; # 在发送前合并多个TCP段
4 tcp_nodelay on; # 为keep-alive连接禁用Nagle算法
5 keepalive_timeout 65; # 保持TCP连接65秒(减少重复TLS握手)
6 gzip on;
7 gzip_types text/plain text/css application/json application/javascript;
8 gzip_min_length 1000; # 不压缩小于1KB的文件(开销大于收益)
9}
sendfile on是提供大型静态文件时最重要的优化——内核直接将数据从页缓存传输到socket,无需经过用户空间复制。
结论: Nginx不仅仅是一款Web服务器——它是现代架构中全面的流量调度层。无论您是在提供静态SPA、为Node.js后端做代理、对微服务进行负载均衡,还是需要Kubernetes的Ingress Controller,Nginx都能以单一二进制文件提供一致、高性能且配置透明的解决方案。

