Nginx 反向代理与负载均衡实战基于陶辉《深入理解 Nginx》第三章本文所有命令输出均来自两台真实云服务器Ubuntu 24.04.4 / nginx 1.24.0的现场回显未做任何编造。拓扑目标一台代理层把流量按多种策略转发给上游的多个后端并具备故障自动转移能力。一、实验拓扑公网 / 客户端 │ ┌────────▼────────┐ │ 代理层 PROXY │ 139.9.***.*** (公网) │ 192.168.0.149 │ nginx 1.24.0 │ upstream │ │ proxy_pass │ └────────┬─────────┘ 内网 192.168.0.xVPC 互通走内网不占公网带宽 │ ┌────────▼────────┐ │ 上游层 UPSTREAM │ 119.3.***.*** (公网) │ 192.168.0.113 │ nginx 1.24.0 │ 3 个后端: │ │ 8081/8082/8083 │ └──────────────────┘代理层承担「反向代理 负载均衡」对外只暴露 80/443内网回源走192.168.0.113。上游层用 3 个独立server块模拟 3 台应用服务器各自返回可区分的身份头X-Backend方便观察分发结果。二、环境准备两台机器两台均用发行版自带的 nginxapt 安装无需编译版本与运行状态如下$ nginx-vnginx version: nginx/1.24.0(Ubuntu)$ systemctl is-active nginx active $ ss-ltn|grep:80LISTEN05110.0.0.0:800.0.0.0:* LISTEN0511[::]:80[::]:*上游层部署 3 个后端/etc/nginx/conf.d/backends.conf节选server { listen 8081; server_name _; default_type text/plain; add_header X-Backend backend-8081; location / { return 200 backend-8081 served at $time_local\n; } } # 8082 / 8083 结构相同仅端口与标识不同本地验证三个后端均可独立响应$curl-s-ihttp://127.0.0.1:8081/|head-8HTTP/1.1200OK Server: nginx/1.24.0(Ubuntu)Content-Type: text/plain X-Backend: backend-8081 $curl-shttp://127.0.0.1:8082/api/health OK backend-8082 $ ss-ltn|grep-E:808[123]LISTEN05110.0.0.0:80810.0.0.0:* LISTEN05110.0.0.0:80830.0.0.0:* LISTEN05110.0.0.0:80820.0.0.0:*代理层先确认能通过内网访问到上游这是生产最佳实践回源走内网省公网带宽、低延迟$curl-s-ihttp://192.168.0.113:8081/|head-6HTTP/1.1200OK Server: nginx/1.24.0(Ubuntu)Content-Type: text/plain Content-Length:50Connection: keep-alive三、反向代理基础proxy_pass反向代理的核心只有一行proxy_pass它把客户端请求转发给 upstream 定义的后端组# /etc/nginx/conf.d/proxy_upstreams.conf upstream backend_rr { zone backend_rr 64k; server 192.168.0.113:8081; server 192.168.0.113:8082; server 192.168.0.113:8083; }# /etc/nginx/conf.d/proxy_lb.conf server { listen 80; server_name _; add_header X-Upstream $upstream_addr always; # 透出实际选中的后端 location / { proxy_pass http://backend_rr; 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_set_header三件套非常关键X-Real-IP/X-Forwarded-For把真实客户端 IP 透传给后端否则后端access.log里全是代理 IP。Host $host保留原始 Host避免后端因 Host 不匹配而走默认站点。X-Forwarded-Proto告知后端原始协议http/https对生成重定向链接、校验安全 cookie 很重要。从公网直接访问代理的 80 端口请求被转发到内网后端并回传身份头$curl-s-ihttp://139.9.***.***/|grep-iEX-Backend|X-Upstream|HTTP/HTTP/1.1200OK X-Backend: backend-8081 X-Upstream:192.168.0.113:8081X-Backend来自上游后端X-Upstream来自代理层$upstream_addr——两个头合起来一条请求从「客户端 → 代理 → 哪个后端」的链路就一目了然。四、负载均衡算法逐一验证代理层同时开了 4 个端口分别绑定不同算法的 upstream便于横向对比端口算法upstream80默认轮询 round-robinbackend_rr8091加权轮询 weightedbackend_weighted8092ip_hash 一致性哈希backend_iphash8093最少连接 least_connbackend_leastconn⚠️踩坑与最佳实践最开始我没有给upstream加zone指令结果多 worker 下轮询状态各自独立连续 9 次请求里 8 次都打到了backend-8081--1-- X-Backend: backend-8081 / X-Upstream: 192.168.0.113:8081 ...2~8 同样 --9-- X-Backend: backend-8082 / X-Upstream: 192.168.0.113:8082加上zone backend_rr 64k;后把节点状态放进共享内存分发立刻均衡见下。生产环境强烈建议所有 upstream 都加zone它还能支持运行时增删节点upstream_conf。1) 默认轮询round-robin$foriin$(seq130);docurl-s-ihttp://127.0.0.1:80/|grep-iX-Backend|tr-d\r;done|sort|uniq-c10X-Backend: backend-808110X-Backend: backend-808210X-Backend: backend-8083三个后端严格 1:1:1符合 round-robin 的加权轮询默认权重相等。2) 加权轮询weightupstream backend_weighted { zone backend_weighted 64k; server 192.168.0.113:8081 weight3; server 192.168.0.113:8082 weight1; server 192.168.0.113:8083 weight1; }$foriin$(seq120);docurl-s-ihttp://127.0.0.1:8091/|grep-iX-Backend|tr-d\r;done|sort|uniq-c12X-Backend: backend-80814X-Backend: backend-80824X-Backend: backend-808312:4:4 3:1:1与配置权重完全吻合。当某台机器性能好、或某实例权重高时用weight把更多流量分给它。3) 最少连接least_connupstream backend_leastconn { zone backend_leastconn 64k; least_conn; server 192.168.0.113:8081; server 192.168.0.113:8082; server 192.168.0.113:8083; }$foriin$(seq130);docurl-s-ihttp://127.0.0.1:8093/|grep-iX-Backend|tr-d\r;done|sort|uniq-c10X-Backend: backend-808110X-Backend: backend-808210X-Backend: backend-8083本例请求都极轻量连接数始终为 0所以退化为均匀分发。least_conn的真正价值在「请求耗时不均」的场景谁最闲分谁避免慢请求把某台机器堆满。它同样常与zone搭配。4) ip_hash 一致性哈希upstream backend_iphash { zone backend_iphash 64k; ip_hash; server 192.168.0.113:8081; server 192.168.0.113:8082; server 192.168.0.113:8083; }$foriin1234;docurl-s-ihttp://127.0.0.1:8092/|grep-iX-Backend|tr-d\r;doneX-Backend: backend-8083 X-Backend: backend-8083 X-Backend: backend-8083 X-Backend: backend-8083同一客户端 IP 始终落到同一后端——这正是「会话保持 / 粘性」的需求场景如未做分布式 Session 时让用户总是命中同一台缓存了状态的应用。注意ip_hash是按$remote_addr哈希若前端还有 CDN/反向代理需配合X-Forwarded-For的real_ip模块才能拿到真实客户端 IP。五、故障自动转移failover负载均衡不只是「分发」更是「容错」。当某后端不可达时Nginx 默认通过proxy_next_upstream把请求重试到下一个健康节点。我们在上游层用iptables把 8082 端口「拒绝」掉模拟该后端宕机$ iptables-IINPUT-ptcp--dport8082-jREJECT;echoadded added $ iptables-LINPUT-n|grep8082REJECT6--0.0.0.0/00.0.0.0/0 tcp dpt:8082 reject-with icmp-port-unreachable此时从代理层连续请求 12 次$foriin$(seq112);docurl-s-ihttp://127.0.0.1:80/|grep-iX-Backend|tr-d\r;done|sort|uniq-c6X-Backend: backend-80816X-Backend: backend-8083死掉的8082一次都没出现流量被自动切到8081与8083。恢复后移除规则$ iptables-DINPUT-ptcp--dport8082-jREJECT;echoremoved removed $ iptables-LINPUT-n|grep8082||echonone none说明开源版 Nginx 没有「主动健康检查」health_check需商业版 Nginx Plus。这里的 failover 依赖被动健康检查——只有当连接/超时/返回错误proxy_next_upstream默认的error timeout发生时才换节点。生产环境可结合max_fails/fail_timeout让节点被「熔断」一段时间或用第三方模块做主动探活。六、小结反向代理proxy_passproxy_set_header透传 Host / 真实 IP / 协议即可回源优先走内网。负载均衡round-robin 默认均分weight调权重least_conn按连接数选闲ip_hash做会话保持。四者都在upstream块内声明。两个关键经验upstream务必加zone—— 否则多 worker 下分发会严重偏斜实测 9 次里 8 次打同一台。failover 默认开启proxy_next_upstream但属于被动健康检查高可用需额外探活机制。下一篇我们将基于这套拓扑继续实战反向代理缓存与HTTPS HTTP/2。
Nginx 反向代理与负载均衡实战（基于陶辉《深入理解 Nginx》第三章）
Nginx 反向代理与负载均衡实战基于陶辉《深入理解 Nginx》第三章本文所有命令输出均来自两台真实云服务器Ubuntu 24.04.4 / nginx 1.24.0的现场回显未做任何编造。拓扑目标一台代理层把流量按多种策略转发给上游的多个后端并具备故障自动转移能力。一、实验拓扑公网 / 客户端 │ ┌────────▼────────┐ │ 代理层 PROXY │ 139.9.***.*** (公网) │ 192.168.0.149 │ nginx 1.24.0 │ upstream │ │ proxy_pass │ └────────┬─────────┘ 内网 192.168.0.xVPC 互通走内网不占公网带宽 │ ┌────────▼────────┐ │ 上游层 UPSTREAM │ 119.3.***.*** (公网) │ 192.168.0.113 │ nginx 1.24.0 │ 3 个后端: │ │ 8081/8082/8083 │ └──────────────────┘代理层承担「反向代理 负载均衡」对外只暴露 80/443内网回源走192.168.0.113。上游层用 3 个独立server块模拟 3 台应用服务器各自返回可区分的身份头X-Backend方便观察分发结果。二、环境准备两台机器两台均用发行版自带的 nginxapt 安装无需编译版本与运行状态如下$ nginx-vnginx version: nginx/1.24.0(Ubuntu)$ systemctl is-active nginx active $ ss-ltn|grep:80LISTEN05110.0.0.0:800.0.0.0:* LISTEN0511[::]:80[::]:*上游层部署 3 个后端/etc/nginx/conf.d/backends.conf节选server { listen 8081; server_name _; default_type text/plain; add_header X-Backend backend-8081; location / { return 200 backend-8081 served at $time_local\n; } } # 8082 / 8083 结构相同仅端口与标识不同本地验证三个后端均可独立响应$curl-s-ihttp://127.0.0.1:8081/|head-8HTTP/1.1200OK Server: nginx/1.24.0(Ubuntu)Content-Type: text/plain X-Backend: backend-8081 $curl-shttp://127.0.0.1:8082/api/health OK backend-8082 $ ss-ltn|grep-E:808[123]LISTEN05110.0.0.0:80810.0.0.0:* LISTEN05110.0.0.0:80830.0.0.0:* LISTEN05110.0.0.0:80820.0.0.0:*代理层先确认能通过内网访问到上游这是生产最佳实践回源走内网省公网带宽、低延迟$curl-s-ihttp://192.168.0.113:8081/|head-6HTTP/1.1200OK Server: nginx/1.24.0(Ubuntu)Content-Type: text/plain Content-Length:50Connection: keep-alive三、反向代理基础proxy_pass反向代理的核心只有一行proxy_pass它把客户端请求转发给 upstream 定义的后端组# /etc/nginx/conf.d/proxy_upstreams.conf upstream backend_rr { zone backend_rr 64k; server 192.168.0.113:8081; server 192.168.0.113:8082; server 192.168.0.113:8083; }# /etc/nginx/conf.d/proxy_lb.conf server { listen 80; server_name _; add_header X-Upstream $upstream_addr always; # 透出实际选中的后端 location / { proxy_pass http://backend_rr; 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_set_header三件套非常关键X-Real-IP/X-Forwarded-For把真实客户端 IP 透传给后端否则后端access.log里全是代理 IP。Host $host保留原始 Host避免后端因 Host 不匹配而走默认站点。X-Forwarded-Proto告知后端原始协议http/https对生成重定向链接、校验安全 cookie 很重要。从公网直接访问代理的 80 端口请求被转发到内网后端并回传身份头$curl-s-ihttp://139.9.***.***/|grep-iEX-Backend|X-Upstream|HTTP/HTTP/1.1200OK X-Backend: backend-8081 X-Upstream:192.168.0.113:8081X-Backend来自上游后端X-Upstream来自代理层$upstream_addr——两个头合起来一条请求从「客户端 → 代理 → 哪个后端」的链路就一目了然。四、负载均衡算法逐一验证代理层同时开了 4 个端口分别绑定不同算法的 upstream便于横向对比端口算法upstream80默认轮询 round-robinbackend_rr8091加权轮询 weightedbackend_weighted8092ip_hash 一致性哈希backend_iphash8093最少连接 least_connbackend_leastconn⚠️踩坑与最佳实践最开始我没有给upstream加zone指令结果多 worker 下轮询状态各自独立连续 9 次请求里 8 次都打到了backend-8081--1-- X-Backend: backend-8081 / X-Upstream: 192.168.0.113:8081 ...2~8 同样 --9-- X-Backend: backend-8082 / X-Upstream: 192.168.0.113:8082加上zone backend_rr 64k;后把节点状态放进共享内存分发立刻均衡见下。生产环境强烈建议所有 upstream 都加zone它还能支持运行时增删节点upstream_conf。1) 默认轮询round-robin$foriin$(seq130);docurl-s-ihttp://127.0.0.1:80/|grep-iX-Backend|tr-d\r;done|sort|uniq-c10X-Backend: backend-808110X-Backend: backend-808210X-Backend: backend-8083三个后端严格 1:1:1符合 round-robin 的加权轮询默认权重相等。2) 加权轮询weightupstream backend_weighted { zone backend_weighted 64k; server 192.168.0.113:8081 weight3; server 192.168.0.113:8082 weight1; server 192.168.0.113:8083 weight1; }$foriin$(seq120);docurl-s-ihttp://127.0.0.1:8091/|grep-iX-Backend|tr-d\r;done|sort|uniq-c12X-Backend: backend-80814X-Backend: backend-80824X-Backend: backend-808312:4:4 3:1:1与配置权重完全吻合。当某台机器性能好、或某实例权重高时用weight把更多流量分给它。3) 最少连接least_connupstream backend_leastconn { zone backend_leastconn 64k; least_conn; server 192.168.0.113:8081; server 192.168.0.113:8082; server 192.168.0.113:8083; }$foriin$(seq130);docurl-s-ihttp://127.0.0.1:8093/|grep-iX-Backend|tr-d\r;done|sort|uniq-c10X-Backend: backend-808110X-Backend: backend-808210X-Backend: backend-8083本例请求都极轻量连接数始终为 0所以退化为均匀分发。least_conn的真正价值在「请求耗时不均」的场景谁最闲分谁避免慢请求把某台机器堆满。它同样常与zone搭配。4) ip_hash 一致性哈希upstream backend_iphash { zone backend_iphash 64k; ip_hash; server 192.168.0.113:8081; server 192.168.0.113:8082; server 192.168.0.113:8083; }$foriin1234;docurl-s-ihttp://127.0.0.1:8092/|grep-iX-Backend|tr-d\r;doneX-Backend: backend-8083 X-Backend: backend-8083 X-Backend: backend-8083 X-Backend: backend-8083同一客户端 IP 始终落到同一后端——这正是「会话保持 / 粘性」的需求场景如未做分布式 Session 时让用户总是命中同一台缓存了状态的应用。注意ip_hash是按$remote_addr哈希若前端还有 CDN/反向代理需配合X-Forwarded-For的real_ip模块才能拿到真实客户端 IP。五、故障自动转移failover负载均衡不只是「分发」更是「容错」。当某后端不可达时Nginx 默认通过proxy_next_upstream把请求重试到下一个健康节点。我们在上游层用iptables把 8082 端口「拒绝」掉模拟该后端宕机$ iptables-IINPUT-ptcp--dport8082-jREJECT;echoadded added $ iptables-LINPUT-n|grep8082REJECT6--0.0.0.0/00.0.0.0/0 tcp dpt:8082 reject-with icmp-port-unreachable此时从代理层连续请求 12 次$foriin$(seq112);docurl-s-ihttp://127.0.0.1:80/|grep-iX-Backend|tr-d\r;done|sort|uniq-c6X-Backend: backend-80816X-Backend: backend-8083死掉的8082一次都没出现流量被自动切到8081与8083。恢复后移除规则$ iptables-DINPUT-ptcp--dport8082-jREJECT;echoremoved removed $ iptables-LINPUT-n|grep8082||echonone none说明开源版 Nginx 没有「主动健康检查」health_check需商业版 Nginx Plus。这里的 failover 依赖被动健康检查——只有当连接/超时/返回错误proxy_next_upstream默认的error timeout发生时才换节点。生产环境可结合max_fails/fail_timeout让节点被「熔断」一段时间或用第三方模块做主动探活。六、小结反向代理proxy_passproxy_set_header透传 Host / 真实 IP / 协议即可回源优先走内网。负载均衡round-robin 默认均分weight调权重least_conn按连接数选闲ip_hash做会话保持。四者都在upstream块内声明。两个关键经验upstream务必加zone—— 否则多 worker 下分发会严重偏斜实测 9 次里 8 次打同一台。failover 默认开启proxy_next_upstream但属于被动健康检查高可用需额外探活机制。下一篇我们将基于这套拓扑继续实战反向代理缓存与HTTPS HTTP/2。
![[论文学习]ToolEmu:用语言模型模拟沙盒识别语言模型智能体的风险](images/news2.jpg)
