日常运维排查站点访问异常，需摸清502错误常见问题

说实话502见得多了，刚开始那会儿确实容易慌，上来就各种改配置，结果越改越糟。后来发现把几个常见原因吃透，大部分502几分钟就能搞定，根本不用紧张。站点突然跳502，多半是后端出状况，或者代理配置有毛病，再不然就是网络不通、资源挤爆了。别一上来就瞎折腾，先冷静想想最近做了什么变更，心里有个谱。

后端服务未正常启动

后端服务没正常跑，这绝对是排错里碰到最多的。比如刚上线新版本服务起不来，或者进程跑着跑着自己挂了，端口被其他程序抢占了，还有那种监听在127.0.0.1上代理从外部访问不到的情况。用supervisor管理的，有时候supervisor自己没起来，服务也就没拉起来。反向代理把请求转过去，结果目标服务压根不存在，那当然就502了。排查的时候直接ssh上去看服务状态，systemctl status或者ps查一下，再netstat确认端口，我习惯先翻服务日志，有时候一眼就能看出启动失败的原因，别急着动代理配置，不然白忙活。

反向代理配置参数异常

代理配置这块新手容易踩坑。转发端口写错，比如把8080敲成8000，或者upstream地址不对；超时参数设太短，大文件传输场景下后端还没处理完代理就断开连接了；缓冲区大小不合理，keepalive_timeout设太短也可能出问题。我见过有人proxy_pass写错一个字母，排查了半天才发现。所以服务状态确认没问题后，就该仔细核对代理的配置文件，尤其是最近改过的地方，多数时候毛病就出在这。

网络链路连通性故障

要是代理和后端部署在不同机器上，网络链路也得查。云环境的安全组没放行端口，机房防火墙拦了代理的IP，或者跨机房链路偶尔闪断，专线抖动一下，都会导致请求到不了后端。哪怕后端服务跑得好好的，链路不通照样502。排查的时候直接在代理节点上telnet后端端口，或者用nc、curl测一下，先把连通性排除了。之前我就碰到过安全组规则忘了加，折腾好久才发现，所以这一步别跳过。

服务器资源耗尽触发超时

流量突然暴涨的时候后端服务器资源可能会被打满，CPU、内存、连接数都飙到极限，新来的请求处理不过来，代理等超时就返回502了。有时候是某个接口被大量请求打爆，导致后端连接池耗尽，这种情况也得注意。这时候别光重启服务应付，得先看监控，判断是正常业务增长还是被攻击了。正常流量就考虑扩容加机器，恶意攻击赶紧上WAF或者限流规则，重启治标不治本，不然下次流量再来问题还会反复。

实际排错按顺序来，从易到难，先查服务状态，再看代理配置，最后测链路和资源占用，这样能省不少时间。不用一上来就把所有配置翻个遍，有章法地排查定位快得多，这些年总结下来的套路基本适用大多数502场景。