502 Bad Gateway表示网关服务器未能从上游服务获得有效响应。需依次排查：用户端缓存与网络、Nginx错误日志、后端服务状态、数据库/Redis资源、WAF回源IP拦截。
如果您尝试访问某个网站，但浏览器显示“502 Bad Gateway”，说明请求已到达代理或网关服务器，但该服务器未能从上游服务器（如应用服务器、PHP-FPM、Node.js等）获得有效响应。以下是理解与定位该问题的关键步骤：
一、502错误的本质含义
502 Bad Gateway是HTTP协议定义的状态码，表示当前作为网关或代理的服务器（如Nginx、Cloudflare、负载均衡器）在转发用户请求时，收到来自后端服务的无效、不完整或根本未返回的响应。它不是客户端问题，而是服务器链路中“中间层”与“上游层”通信失败的明确信号。
二、用户端快速自查方法
此方法用于判断问题是否源于本地环境，避免误判为网站全局故障。原理是排除缓存污染、网络干扰和浏览器兼容性等可逆因素，缩小问题范围。
1、按 Ctrl + F5 强制刷新页面，绕过浏览器缓存重新发起请求。
2、打开命令提示符或终端，执行 ping -c 4 www.baidu.com 验证基础网络连通性；若丢包率高或超时，则本地网络异常。
3、进入浏览器设置，清除全部缓存、Cookie及浏览历史记录，尤其注意勾选“托管插件数据”和“下载历史”选项（部分浏览器需手动展开高级选项）。
4、切换至手机热点或另一Wi-Fi网络，再次访问目标网站；若仅原网络下复现502，则DNS污染或本地防火墙策略可能拦截了回源流量。
三、网站管理员级日志排查路径
该方法面向具备服务器访问权限的运维人员，核心是通过错误日志定位具体失败环节。Nginx的error.log文件通常直接指出上游连接拒绝、超时或协议错误类型，是诊断起点。
1、使用SSH登录服务器，执行 tail -n 50 /var/log/nginx/error.log 查看最近50行错误日志。
2、搜索关键词 upstream timed out —— 表明Nginx等待后端响应超时，需检查fastcgi_read_timeout或proxy_read_timeout配置。
3、搜索关键词 Connection refused —— 表明后端服务进程未运行或端口未监听，需立即验证PHP-FPM、Tomcat等服务状态。
4、执行 systemctl status php-fpm 或 ps aux | grep node 确认关键后端进程存活且无OOM被kill痕迹。
四、常见上游服务故障修复操作
当确认后端服务异常时，需针对性恢复其可用性。不同服务崩溃表现不同，但重启与资源释放是最直接有效的干预手段。
1、若PHP-FPM进程停止：执行 systemctl restart php-fpm 并检查 systemctl is-active php-fpm 返回active。
2、若Node.js应用崩溃：进入项目目录，执行 pm2 restart app_name（使用PM2管理时），或 kill -9 $(pgrep -f "node server.js") && node server.js（裸启模式）。
3、若数据库连接池耗尽：登录MySQL执行 SHOW PROCESSLIST; 查看长连接与Sleep状态数，必要时执行 KILL [ID] 终止阻塞会话。
4、若Redis响应延迟过高：执行 redis-cli ping 测试连通性，再运行 redis-cli info memory | grep used_memory_human 检查内存是否接近maxmemory阈值。
五、安全防护软件导致的拦截处理
当网站部署了WAF类安全产品（如云盾、安全狗、360网站卫士），其回源IP段可能被源站防火墙或安全软件误判为攻击源并主动拦截，造成Nginx无法建立到后端的TCP连接，从而返回502。
1、查阅所用WAF控制台文档，获取其官方公布的回源IP白名单段（例如阿里云WAF常见回源段为100.64.0.0/10）。
2、登录源站服务器，执行 iptables -L -n | grep DROP 检查是否存在针对该IP段的DROP规则。
3、在防火墙中添加放行规则：iptables -I INPUT -s 100.64.0.0/10 -j ACCEPT（以实际回源段为准）。
4、若使用云锁、安全狗等主机防护软件，进入其Web管理界面，在“网络防护→IP黑白名单”中将对应WAF回源IP段设为永久白名单。
