打开网站返回 502，先查程序还是先查网关这一层
先确定这个响应是谁发出的：502 是网关或代理层返回的，含义是它作为转发方从上游收到了无效响应，协议文档对这个状态码的定义就是这样。也就是说请求已经到达网关，网关也尝试转发了，问题落在网关到应用这一段，而不是浏览器到站点那一段。按三步分锅：绕过网关直连源站、看网关错误日志、看程序进程与端口监听，顺序不要颠倒，否则会在一层里反复找另一层的原因。
502 说明的是哪一段失败
一个响应能被称为 502，前提有两个：这一跳上有充当网关或代理的服务器，且它从上游拿到了响应但认为这个响应无效。它和「程序报错」不是一回事：程序自己返回的业务错误码是有效响应，网关会原样透传，浏览器看到的就是那个状态码而不是 502。所以出现 502 时，值得先怀疑的是转发链路对上游响应的解读——连接被断开、响应不完整、协议不匹配、进程在处理途中退出，都会呈现为这一类。
和拿不到响应的那类错误怎么分
文档里同时写明：如果代理或网关没有从源站收到任何 HTTP 响应，它给客户端返回的是 504 Gateway Timeout。这个区分能省掉一半排查方向：拿到 502，说明上游有响应但无效，进程多半活着；拿到 504，是等不到响应，要往超时配置、进程卡住或端口不通去看；拿到连接被重置、拒绝连接这类根本没有任何 HTTP 状态的结果，则更像监听与网络层的问题。三种表现对应三段原因，不要混在一起调参数。
三步分锅
第一步，绕过网关直连源站。在服务器本机按监听端口直接请求一次，能拿到正常页面说明应用侧没问题，问题在网关配置或它与源站之间的连通；直连也异常，才进入应用侧排查。第二步，看网关的错误日志，关注上游连接失败、超时与协议错误的记录，时间点对齐故障发生的那一分钟。第三步，看程序进程与端口监听：进程是否在、监听地址是不是网关配置里指向的那个、有没有在重启周期里。站内的部署方式（面板一键部署、命令部署或容器镜像）默认监听 8001 端口，网关反代的地址要与这个实际监听端口一致，这类不一致是 502 常见来源之一。
部署形态对排查的影响
| 部署形态 | 网关与程序关系 | 排查重点 | 容易误判的地方 |
|---|---|---|---|
| 面板反代 | 面板配置转发到本机端口 | 转发地址与证书配置 | 改了站点却在看旧配置 |
| 手写网关配置 | 自己维护上游地址 | 上游地址、超时、协议版本 | 超时调大掩盖进程卡死 |
| 容器部署 | 端口映射多一跳 | 映射与网络连通 | 把容器网络问题当程序问题 |
容器形态要多看一跳：端口映射与网络名称解析都在网关和程序之间，宿主机上直连正常不代表容器网络内可达。面板部署则要先确认当前站点绑定的转发配置是哪一份，改错站点是这类排查里最常见的耗时来源。
动手之前留一份退路
改网关配置属于会影响整站可用的操作，动手前先备份当前的网关配置文件与站点数据，改一处试一次，不要一次改多处再整体重启。站内有备份与恢复能力，覆盖站库数据与静态文件，配合配置文件的副本，回滚才是可执行的而不是一句原则。
常见问题
问：只有某个页面返回 502，其他正常，还是网关问题吗？ 答：更像这个请求让程序在中途结束了，先看该页面对应的功能与程序日志，网关侧一般不会对特定路径单独报错。
问：重启程序后立刻正常，需要继续查吗？ 答：需要。重启只是恢复现场，进程退出的原因仍在日志里，不查清会重复发生。
问：调大网关超时可以解决 502 吗？ 答：这属于 504 方向的手段。502 的成因是拿到了无效响应，超时参数一般不改变这一点。