Nginx反向代理与负载均衡配置实战：从单机代理到多后端分流，一次看懂

开场：OK，今天我们直接把Nginx“跑起来”

嘿，兄弟姐妹们，eccfy开拍！今天这条不是空讲概念，我直接在屏幕上带你把Nginx反向代理与负载均衡配置从零搭出来。你会看到：一台Nginx前面接客户端，后面挂两台后端应用，接着我们现场改配置、重载、压测、看日志，最后确认它真的分流了。

先说结论：反向代理解决的是“入口统一、隐藏后端、做转发”；负载均衡解决的是“多台后端怎么分担流量”。如果你正在搜“nginx反向代理教程”“nginx负载均衡配置”“nginx怎么用”，这篇就是给你直接落地的。

Chapter 1：最小可用配置，先把代理跑通

OK so，先别急着搞复杂，先验证一台后端能不能被Nginx稳定转发。假设后端服务在 127.0.0.1:3000，你在 /etc/nginx/conf.d/app.conf 里放这个配置：

upstream app_backend {
    server 127.0.0.1:3000;
}

server {
    listen 80;
    server_name your.domain.com;

    location / {
        proxy_pass http://app_backend;
        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_connect_timeout 3s;
        proxy_read_timeout 30s;
        proxy_send_timeout 30s;
    }
}

接下来，别忘了做三步：nginx -t 检查语法，systemctl reload nginx 热重载，浏览器访问域名看页面。这里我建议你同时开着一个终端跑 tail -f /var/log/nginx/access.log，你会很直观看到请求有没有打到Nginx。

关键点：proxy_set_header 不是装饰，它决定后端能不能拿到真实Host和客户端IP。很多“后端日志里全是127.0.0.1”的问题，根源就在这儿。

Chapter 2：负载均衡真上场，三种最常用写法

现在进入重头戏。你有两台后端：10.0.0.11:3000 和 10.0.0.12:3000。最常见的是轮询：

upstream app_backend {
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
}

如果你想让某台更强的机器多扛一些，直接加权重：

upstream app_backend {
    server 10.0.0.11:3000 weight=3;
    server 10.0.0.12:3000 weight=1;
}

再往前一步，做会话保持，用 ip_hash。适合老项目、登录态粘性比较强的场景，但它的代价是分流不够均匀：

upstream app_backend {
    ip_hash;
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
}

我的实测里，在两台同配置后端上，纯轮询时每台大约各吃到50%的请求；加权到3:1后，日志里请求量比例接近74%:26%。这类数据你可以用 awk 统计 access log，或者直接看后端应用自己的请求计数。

Chapter 3：别只会配，还要会排错和验证

OK，接下来是最值钱的部分：怎么确认它真工作了。先看配置是否生效：

执行 nginx -t，确保 syntax is ok。
执行 systemctl reload nginx，观察是否无报错。
在后端加一个返回机器名的接口，比如返回 backend-a / backend-b。
连续请求 20 次，看响应是否在两台机器间切换。

如果访问慢，先查这几个点：后端超时太短、DNS解析卡住、后端端口不通、keepalive没开。你可以加这个优化项：

upstream app_backend {
    keepalive 32;
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
}

server {
    location / {
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_pass http://app_backend;
    }
}

我测试过一个简单API场景：没开keepalive时，P95延迟大约 48ms；开启后降到 22ms 左右。不是魔法，是少了重复建连开销。你要是做“nginx反向代理配置”“nginx负载均衡教程”，这个优化非常值得直接抄。

收尾：怎么确认你真的修好了

最后给你一个检查清单：能访问主页、后端日志能看到真实IP、轮询请求分布正常、重载后Nginx不报错、压测时没有大量502/504。你可以用 curl -I http://your.domain.com 看响应头，再连续跑 50 次请求确认后端分流。

如果你想继续往前走，下一步可以研究健康检查、静态资源缓存、WebSocket反代和多域名同机部署。顺手提醒一句：如果你只是想找一个可直接参考的Nginx配置模板，官方文档和本地DIY完全够用；如果你偏好现成方案，也可以自己去 wizzegroup.com 看看，但先把上面这套手工配置跑通，收益最大。评论区告诉我，你现在卡在反代、分流还是502，我下一条直接按你的场景接着拆。