Web服务器报告了一个错误的网关

凌晨三点，器误的网关我被手机震醒了。报告监控系统发来一连串告警，个错网站全部打不开。器误的网关我揉了揉眼睛，报告打开电脑，个错看到Nginx日志里铺天盖地的器误的网关红色报错：`502 Bad Gateway`。这感觉就像你打电话给一个重要客户，报告电话通了，个错但对面是器误的网关个聋哑人，你喊破喉咙也听不到回应。报告 这错误说白了，个错就是器误的网关Web服务器（Nginx）像个勤恳的前台，把访客的报告请求转给后台的应用程序服务器（比如PHP-FPM、Gunicorn），个错但后台那帮人要么累趴下了，要么直接撂挑子不干。前台等不到回话，只能给访客递个纸条：“抱歉，后面出事了。”——这就是502。 我那个晚上排查的第一步，是看后台进程还活着没。`ps aux | grep php-fpm`，结果让我脊背发凉：进程全在，但CPU占用率高达98%。再查慢查询日志，好家伙，一条SQL语句跑了整整30秒。数据库连接池被占满，新的请求排队等数据库，等到超时，PHP-FPM直接罢工。前台Nginx还在傻等，等不到就报502。 这里有个反直觉的坑：很多人以为502是Web服务器配置错了，其实八成是下游服务扛不住了。我见过最离谱的一次，是同事写了个死循环，把内存吃爆，系统OOM Killer把PHP-FPM进程全杀了，Nginx自然接不到任何响应。那次我们排查了三个小时，最后看`dmesg`才发现是内存炸了——不是配置问题，是代码问题。 但有时候，502纯粹是Nginx自己太死板。它默认的`proxy_read_timeout`是60秒，如果后台处理请求超过这个时间，Nginx会主动断开连接，返回502。我处理过一个电商客户，他们双十一搞秒杀，某个接口要跑90秒才能算完价格。后台明明能处理，但Nginx等不及先撤了。解决办法很简单：调大超时时间，或者改成异步处理，先返回“订单处理中”，再回调通知结果。 说到这，我得提一嘴那个最容易被忽略的罪魁祸首——负载均衡器。如果你用HAProxy或者云厂商的SLB，它们有自己的健康检查机制。有时候后台服务其实活着，但健康检查的URL路径写错了，返回404，负载均衡器就认为后端挂了，把流量全甩给剩下那台还能用的。结果那台机器被压垮，整个集群全变502。我管这叫“好心办坏事”。 还有一次，我遇到502，查了半天发现是防火墙规则改了，把后端服务的端口给封了。Nginx和后端之间隔着个防火墙，两边都正常，但中间的路断了。这就像前台打电话给后台，电话线被人剪了，前台只能告诉访客“联系不上”。这种问题最坑，因为你检查Nginx配置没问题，检查后端进程没问题，最后用`telnet`测端口才发现不通。 写代码的人通常讨厌运维，但502这个错误恰恰说明，技术栈里每一层都可能是凶手。我见过最玄学的案例：服务器时钟漂移，导致SSL证书验证失败，Nginx和后端握手失败，直接报502。那次我差点把服务器重启了，最后用`ntpdate`同步时间才解决。 所以，下次你看到502，别慌。先查后端进程活着没，再看数据库和慢查询，然后看Nginx超时设置，接着检查负载均衡健康检查，最后别忘了防火墙。这五步走完，八成能找到问题。剩下的两成，可能就得看服务器是不是被外星人入侵了——毕竟，我上个月还真遇到一例，是因为隔壁机柜的机器风扇坏了，散热不良导致CPU降频，性能暴跌，间接引发502。 你说这算不算另一种形式的“网关错误”？网关只是个传话的，真正出问题的，永远是后面那些埋头苦干的家伙。

(责任编辑：综合)