站点访问报502错误怎么操作，沿链路排查少做无用功

很多运维看到502的第一反应就是敲重启、加机器，说实话我刚入行那会儿也这样干过，结果折腾半小时不仅没恢复，还把现场日志冲得干干净净，后面想查都费劲。其实502这玩意儿，说白了就是网关把请求转发给上游服务，结果上游要么没回应，要么回了个网关认不出的东西，代理层就直接扔出这个状态码。你只要顺着请求路径一层层摸过去，从网关配置到后端状态，很快就能把问题圈出来，真没必要慌张地一通乱操作。

网关配置与协议握手

配置写错是触发502的大头，尤其Nginx那堆转发规则，一个小细节就能让你怀疑人生。就拿proxy_pass那个末尾斜杠来说，带不带斜杠，转发的路径逻辑完全两码事。比如你配了location /api/，proxy_pass http://backend/; 请求/api/user会变成http://backend/user，看着正常；可要是写成proxy_pass http://backend; 少了那个斜杠，请求直接变成http://backend/api/user，后端根本没这个路径，返回个404或者400，网关收不到200就报502。这种坑我踩过好几回，后来学乖了，改完配置先跑一遍nginx -t，语法校验能拦住八成低级手误。协议混用也是常见毛病，有次排查一个502，查了半小时配置没问题，最后发现后端服务偷偷切成了HTTPS，网关这边还傻傻地用HTTP转发，协议对不上，握手直接就断了，连接被重置。所以协议得确认清楚，别犯这种手滑的错。超时参数也别全照搬默认值，默认proxy_read_timeout就60秒，常规API调用是够，但碰上报表导出、大表查询这类慢操作，后端吭哧吭哧跑一分多钟，网关等不及就把连接掐了，直接甩个502出来。这时候把proxy_connect_timeout和proxy_read_timeout调大些，比如设成300秒，给上游留足喘息时间，能少很多无谓的断连。调完这些基础配置要是还报502，也别死磕配置文件了，顺手在网关机器上curl一下后端地址，看看端口通不通，防火墙有没有拦。再登录后端服务器瞅一眼，进程还在不在，内存CPU是不是打满了，连接池耗没耗尽。一步步剥离干扰项，很快就能揪出真正的故障点，比你闷头重启强得多。