演练条件与问题

教学演练，非客户记录。以下环境与现象均为假设，用于说明排查方法，没有对应的线上故障、处理耗时或恢复成果。

假设访问链路为“浏览器 → Nginx → HTTP 应用服务”，某个页面返回 502。MDN 将 502 解释为网关或代理收到无效的上游响应；这个状态码本身并未给出具体根因。[1]

先把请求与日志对应起来

在这个假设场景中，先记录失败路径与时间，再查看入口访问日志和错误日志。Nginx 官方入门文档将这两类日志列为异常调查的线索来源。[2]

确认报错来自哪一层，以及请求实际转发到哪个服务。若前面还有其他代理，应分别核对，不能只凭错误页面上的品牌判断报错位置。

形成可以被推翻的假设

演练假设：应用已经改用新的监听端口，但入口仍指向旧端口。核对应用的实际监听地址与 Nginx 转发目标；proxy_pass 定义了被代理服务的协议和地址。[3]

如果两者一致，这个假设就不成立，应继续检查日志指向的连接、响应或服务状态问题，而不是为了符合预想而修改配置。

修改前与修改后分别验证什么

只有在证据支持目标地址不一致时，才制定相应调整，并核对影响范围、原配置与退回方法。在隔离环境中验证后，再由有权限的人决定实际变更。

后续应重复原失败请求，同时观察相关路径与日志。即使得到一次正常响应，也只代表该次验证通过；还需记录未验证的功能和持续观察项。

这次演练保留的判断方式

从“看到 502”推进到“某一层与某个上游的关系需要核对”，再用实际证据支持或否定假设。本文只演示这条验证路径，不表示某个真实系统已经修复。