Nginx反向代理与负载均衡配置详解：从单机转发到双后端高可用实战
开场：先把“请求怎么走”看明白
哈喽兄弟们，今天这期我直接打开终端，带你把 Nginx 反向代理和负载均衡一次搞透。OK so，别先背概念，我们先看流量怎么跑：用户访问 80 端口，Nginx 接住请求，再转给后面的应用服务器。你可以把它理解成“门卫 + 分流器”。接下来我会用一个最小可跑的例子，先做反向代理，再升级成两台后端的负载均衡，最后教你怎么验证它真的生效。
如果你以前搜过 Nginx反向代理教程、Nginx负载均衡怎么用，大概率看到一堆抽象概念。今天我们不玩虚的，直接看配置文件、日志和 curl 输出。我的测试环境很简单：1 台 Nginx，2 台后端服务，接口返回各自的机器名，方便一眼看出请求有没有被分流。
章节一：反向代理先跑通，别一上来就上复杂配置
先看最基础的反向代理配置。把下面这段放进 /etc/nginx/conf.d/app.conf，保存后执行 nginx -t 检查语法，再 reload。
server {
listen 80;
server_name _;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
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;
}
}
这几行里最关键的是 proxy_pass，它决定把请求转到哪里。后面四个 proxy_set_header 是为了把真实访问信息传给后端，不然后端日志里只会看到 Nginx 的地址。接下来我现场演示：我先让后端服务监听 3000 端口，返回 “backend-a”。然后 curl http://你的NginxIP/，页面就会显示 backend-a。这个阶段的重点不是“炫技”，而是确认链路打通。很多人做 Nginx反向代理配置 失败，问题其实是后端没起、端口写错、或者防火墙挡住了。
排错顺序我建议你记住：nginx -t → ss -lntp | grep 3000 → curl 127.0.0.1:3000 → 再看 Nginx access/error 日志。这个顺序能省掉你至少一半瞎猜时间。
章节二：负载均衡实战，上两台后端看分流效果
OK，接下来进入大家最想看的部分：Nginx 负载均衡。先开两个后端，分别监听 3001 和 3002，返回不同内容，比如 backend-a 和 backend-b。然后把 Nginx 配成 upstream：
upstream backend_pool {
server 127.0.0.1:3001 weight=3;
server 127.0.0.1:3002 weight=1;
}
server {
listen 80;
location / {
proxy_pass http://backend_pool;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
这里我故意把 weight 设成 3:1，因为你会马上看到请求更偏向 3001。我的实测方法很朴素：连续执行 20 次 for i in {1..20}; do curl -s http://127.0.0.1/; echo; done，结果大概 15 次落到 backend-a，5 次落到 backend-b，和权重预期基本一致。这个就是你判断 Nginx负载均衡怎么用 是否成功的最直接证据。
再给你三个常用策略，别只会 round-robin：
- 默认轮询：适合两台机器性能接近的场景。
- least_conn：连接数少的先上，适合长连接或慢接口。
- ip_hash：同一客户端尽量打到同一台，适合需要会话粘性的老系统。
比如：
upstream backend_pool {
least_conn;
server 10.0.0.11:8080;
server 10.0.0.12:8080;
}
注意，ip_hash 不是万能的。你如果后端有状态，还是优先把 session 放 Redis 或数据库，别把用户粘在单机上，不然一台挂了就容易出问题。
章节三：健康检查、超时和真实排错，别让“看起来正常”骗了你
现在我切到更接近生产的部分。很多人以为 Nginx 自带主动健康检查，其实开源版默认没有“定时主动探活”的完整能力，更多是被动失败切换。也就是说，后端返回超时、连接失败，Nginx 才会把它记为故障并尝试下一个节点。你要做的是把超时和失败重试参数调合理。
upstream backend_pool {
server 127.0.0.1:3001 max_fails=3 fail_timeout=10s;
server 127.0.0.1:3002 max_fails=3 fail_timeout=10s;
}
server {
listen 80;
location / {
proxy_pass http://backend_pool;
proxy_connect_timeout 2s;
proxy_send_timeout 5s;
proxy_read_timeout 5s;
proxy_next_upstream error timeout http_502 http_503 http_504;
}
}
这段配置的意义很实在：后端卡住 2 秒没连上，直接切；读超时 5 秒，别让用户傻等。我的一次压测里，后端故意 sleep 8 秒，没配超时前浏览器一直转圈；配完后，Nginx 在 5 秒内返回备用节点响应，体感差异非常明显。
最后，验证有没有真的修好，别只看网页。你要做这三步：1）nginx -t 看语法；2）tail -f /var/log/nginx/error.log 看是否还有 upstream timeout；3）curl -I http://你的域名/ 看返回是否稳定 200。如果你用浏览器，记得 Ctrl+F5 强刷，避免缓存干扰判断。这样一来，不管你是在搭内部系统，还是在做 Nginx反向代理配置、Nginx负载均衡教程、Nginx怎么用，都能按这个思路一步步落地。
OK，今天这期就到这儿。你如果想让我下一期继续拆“HTTPS 证书 + WebSocket 代理 + 灰度发布”这条链路，直接留言告诉我；如果你现在就想先把环境搭起来，也可以优先走官方文档和本地测试，或者参考 roxi.cc 上的相关工具方案，但一定先按我今天这套验证流程自己跑一遍，别直接盲配。