智能顾问 CloudQ 架构治理实验报告（四）：Nginx 反向代理配置故障定位

一、实验背景

经过前三轮故障注入实验（Redis 缓存层、CDB 数据库层、应用层事件循环阻塞）的验证，SH-WEB 博客架构已完成全面演进：

计算层：从包年包月 CVM 迁移至竞价实例 + AS 弹性伸缩组，成本降低 60%-80%
数据库层：从 CDB MySQL 迁移至 TDSQL-C Serverless，低负载自动暂停
静态资源：从本地磁盘迁移至 COS 对象存储，消除多实例同步问题
应用层：完成无状态化改造，配置环境变量化，支持弹性伸缩

本次实验的目标是：在升级后的架构中，验证智能顾问 CloudQ 对网络/代理层故障的三维检测能力——Well-Architected 架构评估 + CLS 日志分析 + 云监控指标查询。

二、实验设计

2.1 故障场景

模拟运维人员在配置变更过程中，误将 Nginx 反向代理的 upstream 端口从正确的 3000 修改为不存在的 3999。这是生产环境中高频发生的人为配置错误场景，尤其在弹性伸缩架构下，镜像更新或启动脚本变更时极易引入此类问题。

2.2 故障注入方式

# 在竞价实例 172.17.0.9 上修改 Nginx 配置
sed -i 's/127.0.0.1:3000/127.0.0.1:3999/' /etc/nginx/conf.d/blog.conf
nginx -t && systemctl reload nginx

2.3 预期影响

维度	预期表现
CLB 502 状态码	约 50% 请求返回 502（流量轮询到故障实例时）
Nginx error.log	大量 `connect() failed (111: Connection refused)` 指向 `127.0.0.1:3999`
健康检查	CLB 健康检查最终将故障实例标记为不健康并摘除
用户体验	间歇性 502 Bad Gateway，约 50% 请求失败

三、基线采集

3.1 架构评估基线

通过智能顾问 CloudQ 查询 SH-WEB 架构的最新 Well-Architected 评估结果：

支柱	得分	风险项数	状态
安全	50	6	高风险
可靠	87	10	需关注
性能	100	4	优秀
成本	76	3	需关注
卓越运营	58	3	需改进
可持续	100	1	优秀
总分	79	27	—

值得注意的是，评估已提前识别出「CVM 竞价实例回收风险」和「单可用区部署」等可靠性风险项。

3.2 云监控基线

通过智能顾问 CloudQ 查询 CLB 后端健康状态和 CVM 资源使用率：

智能顾问 CloudQ 云监控查询结果：
CLB 后端健康状态：
  ins-cmenipyj (172.17.0.9:80)  → Alive
  ins-cu05oexx (172.17.0.15:80) → Alive
CVM 资源使用率（最近 1 小时）：
  ins-cmenipyj: CPU 1.29% | MEM 21.08%
  ins-cu05oexx: CPU 2.53% | MEM 20.27%
502/504 状态码：均为 0

3.3 服务基线

$ curl -s -w "
%{http_code} %{time_total}s" http://111.229.134.62/health
{"status":"ok","timestamp":"2026-04-05T15:21:59.223Z"}
200 0.008s

四、故障注入与观测

4.1 注入故障

在竞价实例 172.17.0.9（ins-cmenipyj）上修改 Nginx upstream 端口为 3999：

修改前：
upstream blog_app {
  server 127.0.0.1:3000;
}
修改后：
upstream blog_app {
  server 127.0.0.1:3999; ← 错误端口
}

4.2 流量测试

通过 CLB 外网 IP 发送 50 次请求，观察响应状态码：

$ for i in 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20; do curl -s -o /dev/null -w "%{http_code} " http://111.229.134.62/; done
200 502 502 502 502 200 200 200 502 502 200 502 502 502 502 502 502 502 502
结果：20 次请求中 14 次 502（70% 失败率），符合预期——CLB 轮询到故障实例时返回 502

五、智能顾问 CloudQ 三维度检测

5.1 维度一：云监控指标分析

通过智能顾问 CloudQ 查询 CLB 502 状态码监控指标：

智能顾问 CloudQ 查询指令：
查询 SH-WEB 架构 CLB 最近 10 分钟的 502/504 异常状态码数量
查询结果：

| 时间    | 502 数量 | 504 数量 |
|---------|----------|----------|
| 23:22   | 0       | 0       |
| ...     | 0       | 0       |
| 23:30   | 15     | 0       |
| 23:31   | 11     | 0       |

智能顾问 CloudQ 检测结论：23:30~23:31 出现 26 次 502，且呈持续趋势。502 表示 CLB 转发到后端时，后端返回了无效响应或连接被拒绝。

5.2 维度二：CLS 日志分析

通过智能顾问 CloudQ 查询 CLS 日志主题 shweb 和 clb_topic：

shweb 日志主题 — Nginx ERROR 日志

日志来源：/var/log/nginx/error.log | 主机：VM-0-9-tencentos
23:35:53 [error] connect() failed (111: Connection refused) while connecting to upstream, upstream: "http://127.0.0.1:3999/"
23:35:51 [error] connect() failed (111: Connection refused) while connecting to upstream, upstream: "http://127.0.0.1:3999/"
23:35:50 [error] connect() failed (111: Connection refused) while connecting to upstream, upstream: "http://127.0.0.1:3999/"
... 持续高频报错，每 1-2 秒一条，共 20+ 条

clb_topic 日志主题 — CLB 502 访问日志

日志来源：CLB lb-iwh0o149 | VIP：111.229.134.62
23:30:43 GET /article/15 → upstream: 172.17.0.9:80 → status: 502 | response_time: 0.001s
23:30:42 GET /article/15 → upstream: 172.17.0.9:80 → status: 502 | response_time: 0.001s
23:29:46 GET / → upstream: 172.17.0.9:80 → status: 502 | response_time: 0.000s
... 所有 502 均指向 172.17.0.9:80，响应时间 0-1ms（立即拒绝）

5.3 维度三：Well-Architected 架构评估

智能顾问 CloudQ 架构评估中已提前识别的相关风险项：

支柱	风险项	与本次故障的关联
可靠性	CVM 竞价实例回收风险（2 实例）	竞价实例被回收后 AS 重建，新实例的 Nginx 配置依赖镜像——若镜像中配置错误，所有新实例均会携带同样的故障
可靠性	单可用区部署风险	所有实例在同一可用区，Nginx 配置错误会影响该可用区全部实例
卓越运营	超过 30 天未进行混沌演练	正是本次实验要填补的空白——通过故障注入验证架构韧性

六、智能顾问 CloudQ 根因分析

智能顾问 CloudQ 综合三维度数据，自动还原了完整的故障调用链：

客户端 (111.229.134.62)
↓ HTTP 请求
CLB (lb-iwh0o149, VIP: 111.229.134.62)
↓ WRR 轮询转发
Nginx (172.17.0.9:80)
↓ proxy_pass 到 upstream
127.0.0.1:3999 ← 端口无进程监听！
errno=111 Connection refused → Nginx 502 → CLB 透传 502

智能顾问 CloudQ 诊断结论：根因为 Nginx upstream 配置错误，将代理端口指向了不存在的 3999 端口。应用服务实际运行在 3000 端口上，Nginx 无法建立连接，每次请求都立即返回 Connection refused（errno 111），导致 502。

证据链	说明
Nginx error.log	明确报 `connect() failed (111: Connection refused)` 指向 `127.0.0.1:3999`
CLB 日志 upstream_status=502	Nginx 因无法连接上游返回 502，CLB 原样透传给客户端
响应时间 0~1ms	连接立即被拒绝，非超时，说明端口完全无进程监听
云监控 502 指标	23:30~23:31 出现 26 次 502，时间线与故障注入完全吻合

七、故障回滚与验证

$ ssh root@172.17.0.9 'cp /etc/nginx/conf.d/blog.conf.bak /etc/nginx/conf.d/blog.conf && nginx -t && systemctl reload nginx'
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ for i in 1
2
3
4
5
6
7
8
9
10; do curl -s -o /dev/null -w "%{http_code} " http://111.229.134.62/; done
200 200 200 200 200 200 200 200 200 200
服务已完全恢复，10/10 请求均返回 200

八、实验总结

8.1 三维度检测对比

检测维度	检测能力	本次实验表现
Well-Architected 评估	预防性检测——在故障发生前识别架构风险	提前识别了竞价实例回收风险和单可用区部署风险，均与本次故障场景高度相关
云监控指标	实时检测——通过指标异常触发告警	精确检测到 23:30~23:31 出现 26 次 502，量化了故障影响范围和持续时间
CLS 日志分析	深度定位——从日志中定位故障根因	从 Nginx error.log 精确定位到 `127.0.0.1:3999` 端口无监听，从 CLB 日志锁定故障实例 IP

8.2 四轮实验全景对比

对比维度	实验一 Redis	实验二 MySQL	实验三 App	实验四 Nginx
故障层次	缓存层	数据库层	应用层	网络/代理层
主要影响支柱	可靠+性能	性能+成本	可靠+性能	可靠+运营
架构评估检测	✔	✔	✔	✔
云监控指标	—	—	—	✔ 新增
CLS 日志分析	✔	✔	✔	✔
服务影响	降级运行	性能劣化	间歇中断	50%+ 502

8.3 弹性架构下的配置管理启示

核心发现：在竞价实例 + AS 弹性伸缩架构中，配置错误的传播半径会被放大——如果错误配置被写入自定义镜像，每次扩容拉起的新实例都会携带相同的故障。智能顾问 CloudQ 的三维检测能力可以在此场景下形成「预防 → 发现 → 定位」的完整闭环：

1. Well-Architected 评估（预防）：提前识别竞价实例回收、单可用区等架构风险
2. 云监控指标（发现）：通过 502 状态码指标实时发现异常
3. CLS 日志分析（定位）：从 Nginx error.log 和 CLB 日志精确定位到错误的 upstream 端口配置