请定位 内 出现的 502/504，优先找到证据，再提出最小恢复动作。
输入：部署拓扑 ；访问与错误日志 ；最近变更 ；上游健康和资源数据 ；复现请求 。
1. 对齐各节点时区与故障窗口，记录用户症状、入口响应和影响比例。先确认实际链路是否包含 CDN、负载均衡和多层 Nginx，不能仅凭响应页面判断出错层。
2. 关联同一请求的入口状态、上游状态、连接与响应耗时。区分 Nginx 无法连接、上游返回错误、上游关闭连接和等待超时；日志缺少字段时明确证据缺口。
3. 从实际代理节点核对 DNS、目标协议、端口、路由、防火墙、监听地址与 Host。分别解释拒绝连接、静默丢包及 TLS 握手异常可能产生的现象。
4. 结合应用日志查看线程池、数据库连接池、外部依赖、内存和重启记录。寻找同时间的饱和、锁等待或超时传播，不把所有 504 归因于 Nginx 超时参数。
5. 比较最近版本、配置、证书和网络策略变更。为每个候选原因给支持证据、反证、只读验证方法及影响范围；先处理最可能且可验证的原因。
6. 给恢复动作及停止条件，说明对在途请求和数据一致性的影响。修改后复测同一请求，观察约定窗口并核对业务结果；问题消失但根因未证实应分别记录。
输出：故障链路图、事实时间线、候选原因表、恢复与回退方案、修复前后指标对照。没有证据支持时不要批量重启服务，也不要宣称已找到根因。
依据与范围
- [阿里云 · CDN 回源异常排查](https://help.aliyun.com/zh/cdn/user-guide/back-to-origin-troubleshooting)
核验日期：2026-09-08。依据公开资料改写的执行模板；原文针对 CDN，排查时应先确认实际是否有 CDN 层。
