502 Bad Gateway 与 504 Gateway Timeout 怎么解决：访问者与站长的排查方法

打开一个网页，页面上只有一行字：502 Bad Gateway，下面写着 nginx；或者等了很久，出现 504 Gateway Timeout；用了 Cloudflare 的网站还会显示一个带三段图示的错误页，告诉你浏览器、Cloudflare 与源站哪一段出了问题。这类错误在网站发版、流量突增、后端服务崩溃、接口查询太慢时最常见，也会在你通过公司代理或其他代理软件访问网站时出现。很多人第一反应是自己的网络坏了，其实 502 与 504 说明你已经成功连到了网站的网关，是网关后面的服务没有正常工作。

502 的意思是网关从后端收到了无效的响应，或者根本连不上后端，比如后端进程挂了、端口没监听、连接被提前关闭；504 的意思是网关等后端响应等到超时，比如数据库查询太慢、后端在处理一个大请求、后端所在服务器负载过高。对访问者来说，能做的是排除代理与缓存因素、稍后重试；对站长来说，要看网关的错误日志，确认是哪一种上游错误。下面分别讲两类人的处理步骤。

502、504 与相近错误的区别

有状态码的错误，说明请求已经到了某个服务器并拿到了答复，问题在服务端；没有状态码、只显示连接被重置或超时的错误，问题可能出在网络链路上。区分这一点很重要：前者访问者换网络通常没用，后者换网络或线路往往立刻恢复。

访问者与站长的处理步骤

• 第一步：先把网络线路准备好。访问境外网站遇到错误时，先确认是不是自己的网络链路问题，连上刺猬VPN 再打开目标网站对比一次，客户端自定义用户名和密码即可匿名注册，不需要邮箱和手机号；如果你在用公司代理或其他代理软件，502 也可能是那个代理连不上目标网站，先关掉它直接访问对比；
• 第二步：访问者强制刷新页面，或者用无痕窗口打开，排除浏览器缓存了旧的错误页；等一两分钟再试，网站发版与重启期间常有短暂的 502；
• 第三步：访问者换一个网络或设备访问同一个网址，比如手机流量，如果其他网络正常，说明问题在你当前的网络或代理；如果到处都是 502，就是网站自身的问题，只能等对方修复；
• 第四步：站长先看网关的错误日志。Nginx 默认在 error.log 里记录上游错误，按时间找到对应的请求，看是 connect() failed、upstream prematurely closed 还是 upstream timed out；
• 第五步：站长确认后端进程与端口。在服务器上查看后端服务状态，用 curl 直接请求后端监听的地址与端口，绕过网关看后端是否正常返回；
• 第六步：502 且日志显示 Connection refused：后端没在监听，重启服务，并检查网关配置里的上游地址与端口是否与后端一致；
• 第七步：504 且日志显示 upstream timed out：后端处理太慢，先找出慢的接口与数据库查询并优化，确有长任务再适当调大 proxy_read_timeout，不要一味加大超时；
• 第八步：用了 Cloudflare 的网站，看错误页上标红的是哪一段：标在源站说明是你的服务器问题，522 检查源站防火墙是否放行了 Cloudflare 的地址段，524 说明请求处理超过了等待上限；
• 第九步：修复后在网关上配置健康检查与多个后端实例，单个实例故障时自动摘除，减少用户看到 502 的机会。

按现象排查：日志原文对应的原因

Nginx 的错误日志是定位网关错误最直接的依据，下面按日志原文列出原因与动作。

• connect() failed (111: Connection refused) while connecting to upstream：后端端口没有监听，进程挂了或端口配置错误，重启服务并核对端口；
• connect() failed (113: No route to host)：网关到后端的网络不通，检查内网路由、安全组与防火墙；
• upstream prematurely closed connection while reading response header：后端在返回响应前关闭了连接，常见于后端崩溃、内存不足被系统终止，查看后端日志；
• upstream timed out (110: Connection timed out) while reading response header：后端处理超时，优化慢查询或调整超时；
• no live upstreams while connecting to upstream：所有后端都被标记为不可用，先恢复至少一个实例；
• upstream sent too big header：后端返回的响应头太大，常见于大量 Cookie，调大缓冲区设置；
• 只在高峰期出现 502：后端进程数或连接数不够，扩容或调整进程池；
• 发版时短暂 502：重启期间没有可用实例，改为滚动发布或平滑重启；
• 访问者只有自己遇到：多半是自己的网络或代理问题，换网络对比确认。

访问者能做什么：网络因素对照

这张表想说明的是：网站自身的 502 与 504，任何网络下都会出现，换线路解决不了，只能等站长修复；连接被重置、超时这类没有状态码的错误，才是网络链路的问题。访问境外网站时，一条稳定的线路可以帮你排除链路因素：免费节点永久免费、不限流量、不限速，适合临时对比；时长套餐有效期内不限流量、不限速，适合每天访问境外网站。实际可用性取决于当前网络环境。

站长的预防措施

大多数 502 与 504 都可以提前预防。后端服务要配置进程守护，崩溃后自动重启；网关配置至少两个后端实例并开启健康检查，单个实例故障时自动摘除；发版采用滚动更新或平滑重启，保证任何时刻都有可用实例。监控上除了看服务器负载，还要看网关的上游错误数与响应时间，502 的数量突增往往比用户投诉来得更早。

超时设置要分层考虑：浏览器、CDN、网关、后端、数据库各有一个超时，最外层的超时应该略大于内层，否则会出现后端还在处理、网关已经返回 504 的情况。对于导出报表、批量处理这类确实耗时的操作，不要靠加大超时硬撑，改成异步任务：先返回一个任务编号，再让前端轮询或者在完成后通知用户。

命令行对照：站长常用的几条检查

定位网关错误时，几条命令比反复刷新页面有用得多。第一条：在网关服务器上用 tail 跟踪 Nginx 的 error.log，同时在浏览器里复现一次错误，日志里新出现的那一行就是答案。第二条：在网关服务器上用 curl 直接请求上游地址，例如本机的 8080 端口，加上 -w 参数输出总耗时，能直接看到后端是拒绝连接、立刻报错还是慢慢返回。第三条：用 ss 或 netstat 查看后端端口是否处于监听状态，以及当前的连接数是否已经接近上限。

后端是容器部署的，先用容器管理命令查看容器状态与重启次数，频繁重启说明进程在反复崩溃，再看容器日志找崩溃原因；内存不足被系统终止时，系统日志里会有相应的记录。数据库导致的 504，用数据库自带的慢查询日志找出耗时最长的语句，加索引或改写查询往往比调整网关超时有效得多。

把这几条命令写成一份排查清单放在运维文档里，出问题时按顺序执行：先看网关日志，再直连后端，然后看端口与进程，最后看数据库。多数网关错误在前两步就能定位，整个过程通常只需要几分钟。

和其他访问错误的分工

同样是网站打不开，403 Forbidden 是服务器明确拒绝了你的请求，原因多在权限、防火墙或访问规则，处理方法见 网站 403 Forbidden 修复指南，和 502 的排查方向完全不同。

如果浏览器没有显示任何状态码，而是 ERR_CONNECTION_RESET 或者连接已重置，那是网络链路的问题，见 ERR_CONNECTION_RESET 修复指南。可以这样记：4xx 看请求与权限，5xx 看服务端，没有状态码看网络。

常见报错速查表

高频问答

• 问：502 是我的网络问题吗？答：大多数情况下不是，说明你已经连到了网站的网关，是网关后面的服务出了问题；
• 问：刷新能解决吗？答：网站重启或短暂过载时刷新有用，后端持续故障时只能等站长修复；
• 问：504 和超时有什么区别？答：504 是网关等后端超时并返回了状态码，浏览器层面的超时则没有状态码；
• 问：为什么只有我遇到 502？答：可能是你用的代理连不上目标网站，关闭代理后对比；
• 问：站长调大超时就行了吗？答：只能缓解，根本办法是优化慢接口，或者把长任务改成异步；
• 问：Cloudflare 的错误页怎么看？答：看三段图示里哪一段标红，标在源站就是服务器的问题。

处理网关错误的正确思路

502 Bad Gateway 与 504 Gateway Timeout 都说明请求已经到了网关，问题在网关后面的服务。访问者能做的是排除代理与缓存因素、换网络对比，确认是网站自身的问题就耐心等待；站长则要从网关错误日志入手，分清连接被拒、连接提前关闭与处理超时三种情况，再对症处理，并用健康检查、多实例与平滑发布预防下一次。

刺猬VPN 采用 HTTPS+AES 加密传输，自定义用户名和密码即可匿名注册，不需要邮箱和手机号；免费节点永久免费、不限流量、不限速，适合临时对比排查网络链路；时长套餐有效期内不限流量、不限速，适合每天访问境外网站的用户。客户端带断线保护与按域名分流，一个账号支持多设备同时在线。实际可用性取决于当前网络环境。