场景一：让Nginx站到应用前面#

很多人第一次接触Nginx时，最容易把它理解成一个静态文件服务器，但在真实生产环境里，它更常见的身份其实是反向代理。所谓反向代理，就是客户端以为自己在直接访问网站，实际上请求先到Nginx，再由Nginx代替客户端去访问真正的后端应用，比如Java、PHP、Node.js、Go或者Python服务。

最经典的场景是：前端用户访问80或443端口，Nginx接住流量，然后把动态请求转发给运行在内网端口上的应用服务器。这样做有三个直接好处，第一是隐藏后端真实地址，第二是把SSL终止、限流、缓存、日志等横切能力统一收口在入口层，第三是为后续的负载均衡和灰度发布留出操作空间。

1
server {
2
    listen 80;
3
    server_name www.example.com;
4

5
    location / {
6
        proxy_pass http://127.0.0.1:8080;
7
    }
8
}

这段配置的含义非常直接。用户访问www.example.com时，请求先落到Nginx，location /表示所有路径默认都匹配这里，然后proxy_pass把请求转发给本机8080端口上的后端应用。浏览器看到的始终是80端口的网站地址，真正干活的是后面的业务服务。

NOTE

正向代理代理的是客户端，常见于科学上网和企业出口代理；反向代理代理的是服务端，客户端通常感知不到后端真实拓扑。Nginx在Web场景里默认讨论的几乎都是反向代理。

如果想快速验证代理是否真的生效，可以在后端先启动一个简单服务，然后用curl去打Nginx入口。

1
# 假设后端服务监听在8080端口
2
curl -I http://www.example.com
3

4
# 或者本机测试Host头
5
curl -I -H "Host: www.example.com" http://127.0.0.1

场景二：把用户真实信息透传给后端#

只会写proxy_pass还不够，因为默认情况下，后端拿到的很多请求信息已经不是最原始的样子了。尤其是在登录、审计、鉴权、回调地址生成这些场景里，后端通常需要知道客户端真实IP、原始Host、访问协议到底是HTTP还是HTTPS。

生产环境里更推荐把常用代理头一起配上：

1
server {
2
    listen 80;
3
    server_name app.example.com;
4

5
    location / {
6
        proxy_pass http://127.0.0.1:8080;
7

8
        proxy_set_header Host $host;
9
        proxy_set_header X-Real-IP $remote_addr;
10
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
11
        proxy_set_header X-Forwarded-Proto $scheme;
12
    }
13
}

这四行几乎可以算反向代理的标配。

如果你不传这些头，后端框架经常会出现一串非常典型的问题：日志里全是127.0.0.1，回调地址错误地生成成http://，安全审计看不到真实来源，甚至登录态回跳都可能出错。

TIP

只要你的业务需要知道“用户从哪里来、是怎么来的、访问的是哪个域名”，这几行proxy_set_header就尽量不要省。

场景三：路径映射、静态资源与WebSocket#

反向代理最容易写出事故的地方，不是proxy_pass本身，而是URI拼接规则。尤其是location和proxy_pass结尾有没有斜杠，行为差别非常大，很多线上404和接口路径错乱都出在这里。

先看一组最容易混淆的配置：

1
server {
2
    location /api/ {
3
        proxy_pass http://127.0.0.1:9000/;
4
    }
5

6
    location /service/ {
7
        proxy_pass http://127.0.0.1:9000;
8
    }
9
}

如果用户访问/api/user/list，第一段配置会把匹配到的/api/前缀替换掉，最终转发成后端的/user/list。而访问/service/user/list时，第二段配置因为proxy_pass后面没有斜杠，Nginx会把原始URI整体拼上去，后端实际收到的是/service/user/list。

WARNING

proxy_pass末尾的斜杠不是格式问题，而是行为开关。写错时最典型的表现就是前端地址正常、后端接口却一直404。

除了动态接口，静态资源和长连接也常常交给Nginx统一处理。下面是一段非常常见的综合配置：

1
server {
2
    listen 80;
3
    server_name app.example.com;
4

5
    location /static/ {
6
        root /data/www;
7
        expires 7d;
8
    }
9

10
    location /ws/ {
11
        proxy_pass http://127.0.0.1:8081;
12
        proxy_http_version 1.1;
13
        proxy_set_header Upgrade $http_upgrade;
14
        proxy_set_header Connection "upgrade";
15
    }
16

17
    location / {
18
        proxy_pass http://127.0.0.1:8080;
19
        proxy_set_header Host $host;
20
        proxy_set_header X-Real-IP $remote_addr;
21
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
22
        proxy_set_header X-Forwarded-Proto $scheme;
23
    }
24
}

这段配置体现了反向代理最有价值的地方：同一个入口域名下，静态资源由Nginx直接返回，WebSocket请求升级后转给长连接服务，普通动态请求继续转给主应用。对用户来说只有一个站点，对运维来说入口规则却已经实现了分流治理。

反向代理与负载均衡的关系#

很多初学者会把反向代理和负载均衡当成两个完全独立的能力，其实后者往往是前者的升级版。先有Nginx代替客户端去访问后端，这叫反向代理；当Nginx面对的不再是一台后端，而是一组后端，并且还要决定请求发给谁，这才进入负载均衡的范畴。

换句话说，负载均衡几乎总是建立在反向代理之上。先把“怎么转发”搞明白，再去理解“转发给谁”，学习路径就顺了。

实验环境与角色设定#

为了让所有推演足够具体，我们先搭建一个虚拟的电商网站后端集群，一共三台Web服务器，每台机器的性格和能力完全不同。

第一台机器IP是10.0.0.7，配置为2核4G，是一台服役多年的老机器，性能弱但还能用。第二台机器IP是10.0.0.8，配置为8核16G，是刚采购的新机器，性能强劲。第三台机器IP是10.0.0.9，配置为2核4G，平时不干活，专门用来当备胎救急。

这三台机器将贯穿负载均衡部分的全部场景，你会看到同样的三台机器在不同算法下完全不同的命运。

场景一：流量分发策略的四种姿势#

1
upstream web_pools {
2
    server 10.0.0.7:80;
3
    server 10.0.0.8:80;
4
    server 10.0.0.9:80;
5
}

1
upstream web_pools {
2
    server 10.0.0.7:80 weight=1;
3
    server 10.0.0.8:80 weight=3;
4
    server 10.0.0.9:80 weight=1;
5
}

1
upstream backend {
2
    least_conn;
3
    server 10.0.0.7:80 weight=1;
4
    server 10.0.0.8:80 weight=3;
5
}

1
upstream web_pools {
2
    ip_hash;
3
    server 10.0.0.7:80 weight=1;
4
    server 10.0.0.8:80 weight=3;
5
}

场景二：健康检查，自动踢掉死机节点#

1
upstream web_pools {
2
    server 10.0.0.7:80 max_fails=2 fail_timeout=10s;
3
    server 10.0.0.8:80 max_fails=2 fail_timeout=10s;
4
}

1
wget http://nginx.org/download/nginx-1.26.1.tar.gz
2
wget https://github.com/yaoweibin/nginx_upstream_check_module/archive/refs/tags/v0.4.0.tar.gz
3
tar zxf nginx-1.26.1.tar.gz && tar zxf v0.4.0.tar.gz
4
cd nginx-1.26.1
5
patch -p1 < ../nginx_upstream_check_module-0.4.0/check_1.20.1+.patch
6
./configure --add-module=../nginx_upstream_check_module-0.4.0
7
make && make install

1
upstream backend {
2
    server 10.0.0.7:80;
3
    server 10.0.0.8:80;
4

5
    check interval=3000 rise=2 fall=3 timeout=1000 type=http;
6
    check_http_send "GET /health HTTP/1.0\r\n\r\n";
7
    check_http_expect_alive http_2xx http_3xx;
8
}

1
location / {
2
    proxy_pass http://backend;
3
    health_check interval=5s fails=3 passes=2 uri=/health;
4
}

场景三：平滑升级，更换引擎不熄火#

这是运维操作里最帅的一手。假设当前跑着Nginx1.20，现在要升级到1.22，全程用户零感知。

第一步，查出当前主进程的PID，假设是1000。

1
ps -ef | grep nginx
2
kill -USR2 1000
3
kill -WINCH 1000
4
kill -QUIT 1000

第二步发送USR2信号，这是最神奇的一步。老进程收到信号后，会拉起一个运行新版本的新主进程，假设PID是2000，此后新旧两个主进程同时监听同一个端口，老进程不再接受新连接但继续处理存量连接，正在下载文件和正在支付的用户完全不受影响，所有新进来的用户则由新进程接管。

第三步发送WINCH信号，通知老进程优雅地关闭它的工作进程。工作进程不会立刻死掉，而是把手上剩余的旧连接处理完再退出，做到有始有终。

第四步发送QUIT信号，等旧连接全部处理完毕，老主进程彻底消失，舞台上只剩下新版本的2000号进程。

整个过程中没有任何一个用户的连接被掐断，页面没有任何卡顿和报错，这就是平滑二字的真正含义。另外务必保留旧版本的二进制文件，万一新版本出现异常，可以向新进程发HUP、向老进程发USR2快速回退，给自己留好退路。

工业级综合配置#

把前面三个场景串起来，就是一套可以直接上生产的完整配置。

1
upstream web_pools {
2
    ip_hash;
3

4
    server 10.0.0.7:80 weight=1 max_fails=3 fail_timeout=30s;
5
    server 10.0.0.8:80 weight=3 max_fails=3 fail_timeout=30s;
6
    server 10.0.0.9:80 backup;
7
}
8

9
server {
10
    listen 80;
11
    location / {
12
        proxy_pass http://web_pools;
13
        proxy_set_header Host $http_host;
14
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
15
    }
16
}

这段配置里，ip_hash负责会话保持，weight负责按能力分配流量，max_fails和fail_timeout负责故障自愈，9号机后面的backup关键字是点睛之笔，表示它平时不接收任何流量，只有当所有主节点全部宕机时才会被唤醒顶上来，是真正的最后防线。下面的两行proxy_set_header负责把客户端真实IP透传给后端，否则后端日志里看到的全部是Nginx自己的IP，排查问题时会两眼一抹黑。

概述：Nginx最像编程语言的地方#

Rewrite是Nginx最像编程语言的模块，也是面试和工作中最容易写错导致死循环的重灾区。它的核心目标是当请求到达Nginx时，Nginx有权不转发请求，而是直接在自身层面完成拦截、改地址、贴标签和重定向四件事。

四个指令的关系可以用一句话记住：return是拦路虎直接给结果，if是条件分支做判断，set是贴标签定义变量，rewrite是改地址做重写。一个请求进入Nginx后，会先经过set定义变量，再经过if做条件判断，然后由rewrite改写路径，最后随时可能被return一脚踢回给浏览器。

return指令：简单粗暴的拦截与跳转#

1
location /admin/ {
2
    return 403;
3
}

1
server {
2
    listen 80;
3
    server_name www.old.com;
4
    return 301 http://www.new.com$request_uri;
5
}

1
server {
2
    listen 80;
3
    server_name www.oldboy.com;
4
    return 301 https://$server_name$request_uri;
5
}

if指令：有原则的挑客#

if主要在location块里对内置变量做逻辑判断。先看一个限制请求方法的实战案例，假设网站是纯新闻展示页，只允许浏览和提交表单，其余方法一律拒绝。

1
location / {
2
    if ($request_method !~ ^(GET|POST|HEAD)$) {
3
        return 403;
4
    }
5
    proxy_pass http://web_pools;
6
}

黑客用DELETE方法发起攻击时，Nginx的内心独白是：收到一个DELETE请求，检查if条件，请求方法不匹配白名单正则，直接触发403拒绝，根本不转发给后端，后端服务器毫发无损。

必须提醒的是，官方文档里有一篇著名的文章标题直译过来就是if是邪恶的。Nginx的if在location上下文中的实现有历史遗留的坑，嵌套使用和配合proxy_pass时容易产生诡异行为。安全的使用姿势是让if块里只放return或rewrite这类终结性指令，不要在if里做复杂的逻辑编排。

set指令：给请求贴标签#

set用来定义自定义变量，配合if可以实现业务开关。最典型的场景是网站一键进入维护模式，凌晨升级数据库时不想让用户看到报错白屏，而是看到友好的维护提示。

1
server {
2
    listen 80;
3
    server_name www.oldboy.com;
4
    set $maintain 1;
5

6
    location / {
7
        if ($maintain = 1) {
8
            return 503;
9
        }
10
        proxy_pass http://web_pools;
11
    }
12
}

运维的操作节奏是这样的：白天正常运行时变量设为零，网站正常访问；凌晨要升级时把变量改为一，执行reload后所有用户看到503；升级完毕再改回零，网站瞬间恢复。全程不需要改动任何后端代码，纯Nginx层面就完成了停服通知。

还可以更进一步，配合error_page指令把冰冷的503状态码指向一个精心设计的静态维护页面，让用户看到品牌化的提示而不是浏览器默认报错，细节体验立刻拉开差距。

rewrite指令：最灵活的地址改写#

rewrite比return强大，因为它支持正则表达式，可以捕获并改写URL中的特定部分。语法结构是rewrite加正则加替换目标加标记四段式。

1
location / {
2
    rewrite ^/user/(\d+)\.html$ /user.php?id=$1 last;
3
    proxy_pass http://web_pools;
4
}

1
rewrite ^(.*)$ https://$server_name$1 permanent;

四种标记：面试必问的王炸难点#

rewrite语句末尾的flag决定了改写之后的行为，这是整个模块最容易混淆的部分。用同一组配置对比四种标记的区别。

1
location / {
2
    rewrite ^/a/(.*) /b/$1 flag;
3
    rewrite ^/b/(.*) /c/$1 flag;
4
    proxy_pass http://web_pools;
5
}
6
location /b/ {
7
    return 999;
8
}

逐个推演一遍。请求a路径进来，如果标记是last，路径被改成b之后，Nginx会拿着b路径重新走一遍location匹配流程，发现命中b的location，于是执行里面的return999，用户最终收到999。如果标记是break，路径改成b之后rewrite模块就此打住，不再执行后面的rewrite指令也不重新匹配location，直接拿着b路径在当前location里执行proxy_pass，后端收到的是b路径的请求。

redirect和permanent的共同点是都会让浏览器地址栏变化，区别在缓存行为。permanent返回的301会被浏览器永久缓存，用户下次再访问旧地址时，浏览器甚至不联系服务器，直接翻本地缓存自己跳过去。这也意味着permanent一旦配错影响很难收回，测试阶段务必先用redirect验证，确认无误后再切换成permanent。

记忆last和break的区别有一个口诀：last是重新来过，break是到此为止。last会开启新一轮location匹配，break则在当前位置画上句号。

终极排雷：死循环是怎么产生的#

写rewrite时最惨烈的翻车是下面这种写法。

1
location / {
2
    rewrite ^/(.*) /index.php?path=$1 last;
3
    proxy_pass http://web_pools;
4
}

灾难的原理是：请求进来被改写成index点php，因为标记是last，Nginx拿着新路径重新匹配location，结果index点php依然匹配斜杠这个location，于是又被改写成index点php，无限循环。Nginx的内部重定向次数上限是十次，超过之后直接报500内部错误，日志里留下一句重定向次数过多的报错。

正确的解法有三种。最简单的是把last改成break，改写一次就停手不再重新匹配。或者让重写目标指向一个专门的location，确保不会再次命中自己。还可以在rewrite之前用if判断当前路径是否已经是目标路径，是就跳过。无论用哪种，写完rewrite之后的第一件事永远是用curl实际打一遍，确认没有循环再上线。

总结#

如果把整篇文章压缩成一句话，那就是：反向代理解决“请求先由谁接住、怎么转发”，负载均衡解决“请求应该转给哪一台后端”，Rewrite解决“请求在转发前要不要改写、拦截或跳转”。这三块能力拼起来，才是Nginx在生产环境里的完整形态。

反向代理部分帮你建立入口层思维，知道为什么要透传真实头部、为什么proxy_pass的斜杠会影响URI、为什么静态资源和WebSocket也适合交给Nginx统一治理；负载均衡部分把流量调度、故障自愈和平滑升级串成一条完整链路；Rewrite部分则负责请求改写和访问控制的精细操作。把这些知识点全部吃进肌肉记忆，你在面试里被问到Nginx时就能从入口层一路讲到转发层和改写层，在工作中也能写出既优雅又安全的配置。