第八次课：Nginx 反向代理与负载均衡

约 3209 字大约 11 分钟

Nginx反向代理负载均衡upstream

2026-07-30

进入本课环境

[Windows PowerShell] wsl ~：打开本机默认的 WSL2 Ubuntu；出现 用户名@主机名:~$ 后再执行标为 [WSL] 的命令。
[WSL] ssh root@你的ECS公网IP：从 WSL 连接自己的 ECS；如果登录用户不是 root，请换成控制台显示的实际用户，看到远端提示符后再执行标为 [ECS] 的命令。

前几次课里，浏览器始终连接某一个 Web 服务。如果同一站点有两个后端实例，需要在它们前面增加一个稳定入口：客户端只认识负载均衡器，负载均衡器再选择后端。

本课运行三个隔离容器：

lb：Nginx 负载均衡入口，只绑定 ECS 的 127.0.0.1:18008；
backend-a：返回页面标识 backend-a；
backend-b：返回页面标识 backend-b。

连续请求看到两个不同标识时，说明请求确实到过不同后端。停止其中一个后端，入口仍能返回另一个后端的页面；恢复后再次观察到两个标识，才算走完一轮完整的故障处理验证。

安全边界

只允许停止 cloud-course-lab-08 中的 backend-b。不要停止服务器现有 Nginx、所有容器或其他 Compose 项目，也不要把 18008 改为公网绑定。

8.1 反向代理站在谁的角度

反向代理（代表后端服务接收客户端请求，再把请求转发到内部服务的中间层）对浏览器暴露一个统一入口。用户访问时只认这个公开地址，通常不必知道后端有多少台机器、内部 IP 是什么。

完整请求路径如下：

Windows 浏览器
  -> WSL SSH 隧道
  -> ECS 127.0.0.1:18008
  -> lb:80
  -> backend-a:80 或 backend-b:80

正向代理替客户端去访问外网资源，反向代理则是替服务端接收并分发外部请求。本课聚焦在反向代理场景。

关键提醒

负载均衡器本身存活，后端不一定正常；配置了两个后端，流量也不一定平摊过去。必须结合静态配置、后端直连测试与入口访问日志综合判断。

Nginx 反向代理模式建议观看：6:01

在 Bilibili 打开

观看时留意：客户端看见的是代理入口还是后端地址，代理又替谁选择后端？

与本课的关系：视频解释代理位置。课程中的端口、upstream 名称和隔离边界以本课配置为准。

8.2 `upstream` 定义后端组

本课的核心 Nginx 配置：

upstream course_backends {
    server backend-a:80 max_fails=1 fail_timeout=5s;
    server backend-b:80 max_fails=1 fail_timeout=5s;
}

upstream course_backends 为后端服务组命名。两条 server 指向 Compose 服务的名称，避免写死容器的动态 IP。

在未指定额外调度算法时，Nginx 默认采用轮询（Round Robin）。max_fails=1 fail_timeout=5s 规定在 5 秒内如果某后端连续失败 1 次，就暂时将其剔除；这属于请求驱动的被动熔断，不是主动探针检测。

入口代理配置：

location / {
    proxy_pass http://course_backends;
    proxy_connect_timeout 2s;
    proxy_read_timeout 5s;
    proxy_next_upstream error timeout http_502 http_503 http_504;
    proxy_next_upstream_timeout 6s;
    proxy_next_upstream_tries 2;
}

proxy_pass 把请求转发给后端组。proxy_connect_timeout 2s 限制连接单个后端的等待时间，proxy_next_upstream_timeout 6s 限制本次请求在候选后端之间重试的总时间。没有这两个边界时，停止后端后的第一条请求可能等待很久，终端看上去像“卡住了”。

8.3 启动前先检查配置和端口

进入 ECS 上的项目目录：

[ECS] mkdir -p ~/cloud-course/lab-08
[ECS] cd ~/cloud-course/lab-08
[ECS] cp -r starter/* .

实训包包含 compose.yaml、lb.conf 和两个后端目录（从智慧职教课程资源区下载 lab-08-starter.zip 解压）。

解析 Compose 配置：

[ECS] docker compose config --services

输出应包含 backend-a、backend-b、lb。这能证明 service 定义正确。

[ECS] docker compose config --quiet

命令静默无输出说明 YAML 语法合法。而 Nginx 内部的配置文件语法，等容器启动后再用 nginx -t 进一步校验。

[ECS] ss -lnt 'sport = :18008'

启动前预期无输出。如果端口已被占用，请先暂停，并按课程分配重新确认端口。

启动容器服务：

[ECS] docker compose up -d
[ECS] docker compose ps

backend-a、backend-b 只显示内部 80；lb 显示 127.0.0.1:18008->80/tcp。

检查 Nginx 配置：

[ECS] docker compose exec -T lb nginx -t

预期出现 syntax is ok 和 test is successful。这能证明语法和引用文件可加载，后端页面能不能访问还得接着看。

分别从负载均衡器直连两个后端：

[ECS] docker compose exec -T lb wget -qO- http://backend-a/

输出应包含 backend-a。

[ECS] docker compose exec -T lb wget -qO- http://backend-b/

输出应包含 backend-b。两次直连把“后端本身不可达”和“负载算法异常”分开。

负载均衡配置、端口与后端直连的原始整页终端截图 — 数据来源：host-B，捕获于 2026-07-28。页面只负责选择和排版，命令与输出保存在独立数据文件中。

请求进入稳定入口

curl 访问 ECS 127.0.0.1:18008，请求先进入 lb:80。

观察点

单次 200 只能证明一条请求成功，不能证明轮询。
后端直连与入口请求分别验证内部可达性和转发行为。
日志中的 upstream_status 与最终 status 可能反映重试过程。

8.4 用多次请求观察轮询

一次请求只能证明”某个后端返回了响应”，请求是不是真的分到了不同后端还得继续验证。

Bash for 循环的格式是 for 变量 in 列表; do 命令; done——i 依次取列表中的每个值，$i 在循环体内展开为当前值。下面的循环把 i 从 1 走到 6，每次请求入口并提取后端标识：

[ECS] for i in 1 2 3 4 5 6; do
  printf 'request-%s -> ' “$i”
  curl -sS http://127.0.0.1:18008/ | grep -o 'backend-[ab]'
done

预期交替或近似交替出现 backend-a、backend-b。默认轮询表示按请求选择后端，但连接复用、失败重试和配置变化都会影响实际序列；验收重点是两个标识都出现，不要求死记固定顺序。

Nginx 轮询调度建议观看：2:55

在 Bilibili 打开

观看时留意：为什么一次请求不能证明轮询，多次请求时应该观察哪个后端标记？

与本课的关系：轮询结果要用连续请求验证，不能只凭配置文件声称负载均衡已经生效。

[ECS] curl -sSI http://127.0.0.1:18008/ | grep -i '^X-Course-Upstream:'

本课配置额外返回 X-Course-Upstream，用于教学观察。生产环境是否公开上游信息要根据安全策略决定。

连续请求观察两个后端的原始整页终端截图 — 数据来源：host-B，捕获于 2026-07-28。页面只负责选择和排版，命令与输出保存在独立数据文件中。

8.5 单后端停止时入口会怎样

故障前保存基线：

[ECS] docker compose ps

只停止本项目的 backend-b：

[ECS] docker compose stop backend-b

再次连续请求：

[ECS] for i in 1 2 3 4; do
  curl --max-time 8 -sS http://127.0.0.1:18008/ | grep -o 'backend-[ab]'
done

预期请求仍返回 backend-a。--max-time 8 是客户端总等待上限；首次命中故障后端时，Nginx 会在配置的连接和重试时间内转向下一项可用后端。

查看最近日志：

[ECS] docker compose logs --since 30s --tail 20 lb

重点寻找 connect() failed、upstream 地址和最终 HTTP 状态。日志能说明负载均衡器怎样处理请求，不要因为看到一行错误就认定整个站点已经不可用。

恢复后端：

[ECS] docker compose start backend-b

先确认容器健康：

[ECS] docker compose ps

等待 backend-b 为 healthy，超过 fail_timeout 后再次执行多次请求。重新看到 backend-a 与 backend-b，表示后端已经回到请求链。

单后端中断、重试与恢复的原始整页终端截图 — 数据来源：host-B，捕获于 2026-07-28。页面只负责选择和排版，命令与输出保存在独立数据文件中。

完整记录按“停止后端—重复请求—查看日志—启动后端—再次请求”的顺序展开。日志中出现 connect() failed，描述的是 Nginx 访问上游时遇到的故障，不代表 docker compose logs 这条查询命令执行失败。

单后端停止后的入口请求的原始整页终端截图 — 数据来源：host-B，捕获于 2026-07-28。页面只负责选择和排版，命令与输出保存在独立数据文件中。

四行 backend-a 与上方同一条循环命令直接对应，说明捕获时这些只读请求仍得到响应。它没有说明 Nginx 怎样完成切换，下一张日志才补上内部证据。

负载均衡器记录上游失败的原始整页终端截图 — 数据来源：host-B，捕获于 2026-07-28。页面只负责选择和排版，命令与输出保存在独立数据文件中。

日志中的 connect() failed 是第一次上游连接失败，upstream_status=502, 200 表示同一请求先遇到失败，随后从另一候选后端取得成功响应。内部地址已经遮盖，这段日志也只对应捕获时的 GET 请求。

后端恢复后重新参与轮询的原始整页终端截图 — 数据来源：host-B，捕获于 2026-07-28。页面只负责选择和排版，命令与输出保存在独立数据文件中。

输出重新同时出现 backend-a 与 backend-b，证明恢复后的后端已经回到请求链。这个短序列只能证明两个后端都被选中过，不能用来比较性能或推断长期分配比例。

Nginx 后端状态：backup 与 down建议观看：5:07

在 Bilibili 打开

观看时留意：后端退出调度和后端成为备用节点时，请求分配会发生什么变化？

与本课的关系：配置状态不等于完整高可用。本课还要用故障请求、日志和恢复结果验证。

观察点

助教是否先确认项目与三个服务边界？
是否区分配置、后端直连、入口请求和日志证据？
是否避免把一次 GET 接替夸大为完整高可用？

不知道问什么时，可以先选一句：

正在加载对话组件…

本实验的原始聊天仅保存在当前标签页，不会写入全局课程助教上下文。

8.6 被动故障判断不是完整高可用

开源 Nginx 的上述配置依赖真实请求发现连接错误。它没有解决所有高可用问题：

lb 仍然是单个入口，若它停止，两个后端都无法通过该入口访问；
两个后端必须共享或同步必要数据，否则用户可能看到不一致内容；
带副作用的请求不能随意重试，需要结合 HTTP 方法和应用幂等性；
主动健康检查、连接排空、会话保持和跨机故障切换需要进一步设计；
两个容器在同一台 ECS 上，不能抵御整台主机故障。

因此，本课结果应表述为“单个后端连接失败时，入口仍能把本次只读请求交给另一个后端”，而不是“系统已经永不宕机”。

8.7 常见现象的检查顺序

nginx -t 失败

先根据错误行号检查 upstream、分号和 proxy_pass。不要反复重启，配置无法加载时重启只会重复失败。

两个后端直连都成功，入口返回 502

查看 lb 日志和 proxy_pass 的组名，确认入口 location 使用的是 course_backends，再检查 Nginx 是否加载了修改后的配置。

多次请求始终只有一个后端

先确认另一后端健康并能直连，再检查是否存在 ip_hash、权重、失败计数或浏览器缓存。不要仅凭两次请求断定轮询失效。

停止一个后端后入口也失败

检查另一后端能否直连、proxy_next_upstream 条件和错误日志。若两个后端同时不可达，负载均衡器无法凭空生成业务响应。

8.8 分层实训与提交

完整步骤见实训 08：负载均衡与后端故障恢复。

保底任务

从配置中标出入口、upstream 组和两个后端；
区分配置检查、后端直连和入口请求三类证据；
根据给定日志判断请求停在哪一层。

标准任务

启动三服务项目并通过 nginx -t；
用连续请求观察两个后端；
停止 backend-b，记录入口、日志与恢复结果；
运行 verify.sh，清理项目并确认 18008 释放。

挑战任务

为 backend-a 设置权重 2，记录 12 次请求的分布；
改用 least_conn，说明它与轮询关注的指标差异；
画出“负载均衡器自身故障”还需要增加的组件。

提交前清理实验环境：

[ECS] docker compose down
[ECS] ss -lnt 'sport = :18008'
[ECS] rm -rf ~/cloud-course/lab-08

最后一条确认 18008 端口已释放。

提交：

班级_学号_姓名_第08次课_Nginx负载均衡报告.docx

只上传一个 Word 到智慧职教“第08次课”，不上传公网地址、SSH 配置、容器日志全集或其他项目信息。

8.8.1 前八次课回归测评

这组题不重复本课术语，而是检查你能否把前八次课的环境定位、Web 链路、备份恢复、Compose 依赖和负载均衡证据重新调动起来。先独立作答；错题回到对应证据层复查，不靠背选项。

8.9 第八次课小测

8.10 小结

反向代理为客户端提供稳定入口，内部再选择后端。
upstream 定义后端组，默认算法为轮询。
配置检查、后端直连、多次入口请求和日志回答不同问题。
单后端停止后，Nginx 可以把符合条件的请求交给另一后端。
恢复后必须重新观察两个后端，而不是只看容器启动。
单机三容器只能演示后端故障处理，不能替代跨主机高可用设计。

下一次课将进入阶段考核：从环境基线出发，独立定位并修复一组匿名化故障。

带入第 9 次课的不是某一条“万能修复命令”，而是一张简短工单：正常基线是什么、故障时哪一层先异常、你用了什么最小修改、修复后跑了哪些同路检查。阶段考核只提供现象，不提示故障层级，这张工单就是你的排查路线。

8.11 资料来源

以下资料在 2026-07-28 核对：

课程 AI 助教

现在，试着让助教陪你复盘

助教会读取当前课程页面和结构化学习记录，但不会读取正文实验框里的原始聊天。

第八次课：Nginx 反向代理与负载均衡

进入本课环境

8.1 反向代理站在谁的角度

8.2 `upstream` 定义后端组

8.3 启动前先检查配置和端口

示范：一次请求怎样选择后端

8.4 用多次请求观察轮询

8.5 单后端停止时入口会怎样

实验：判断负载均衡请求停在哪一层

8.6 被动故障判断不是完整高可用

8.7 常见现象的检查顺序

8.8 分层实训与提交

提交负载均衡报告前确认一下

8.8.1 前八次课回归测评

第 8 次课回归测评：前八次课证据链

8.9 第八次课小测

lesson-08-check 小测

8.10 小结

8.11 资料来源

现在，试着让助教陪你复盘