502错误本质是Nginx作为代理收不到后端有效响应，需分层排查：先直连验证后端真实健康状态（curl/health、日志、资源监控），再收紧Nginx通信配置（keepalive、合理超时、主动健康检查），接着限流隔离防雪崩（max_fails、limit_req、PHP-FPM调优），最后验证代理链路完整性（header透传、HTTPS/SNI、tcpdump抓包比对）。
502 错误本质是 Nginx 作为代理，收不到后端服务的有效响应——它不是 Nginx 挂了，而是后端“失联”或“失能”。排查要从后端真实状态出发，分层验证，避免只调大超时或反复重启。
直连后端，确认真实健康状态
别信进程在、端口通，要验证它真能处理请求：
- 用 curl -I http://后端IP:端口/health 绕过 Nginx 直连每个节点，看 HTTP 状态码和响应时间是否正常
- 查后端日志，重点搜 "connection refused"、"too many open files"、"OOM killed process"
- 运行 ss -s 或 lsof -nPi | wc -l 查文件描述符是否耗尽；用 free -h 和 top 看内存/CPU 是否打满
收紧 Nginx 与后端的通信配置
默认超时太激进，高并发下容易误判；但盲目拉长会掩盖问题：
- 在 upstream 块中加 keepalive 32; 复用连接，减少 TCP 握手开销
- 设合理超时：proxy_connect_timeout 15s（建连）、proxy_send_timeout 60s（发数据）、proxy_read_timeout 60s（等响应）
- 启用主动健康检查：health_check interval=3 fails=2 passes=2;，让 Nginx 自动剔除失联节点
控制流量，防止后端雪崩
502 往往是压垮前的最后一秒，入口需有缓冲和隔离：
- 在 upstream 中加 max_fails=2 fail_timeout=30s，快速标记并隔离故障节点
- 用 limit_req zone=burst burst=20 nodelay 限制单 IP 并发请求数，防爬虫或异常流量冲击
- 若后端是 PHP-FPM，检查 pm.max_children 是否足够，并适当提高 pm.start_servers 和 pm.min_spare_servers
验证代理链路是否完整
问题有时藏在中间环节，比如 TLS 或 header 透传异常：
- 确认已配置 proxy_set_header Host $host; 和 proxy_set_header X-Real-IP $remote_addr;，避免后端因缺失关键 header 拒绝处理
- 若后端是 HTTPS，加 proxy_ssl_server_name on; 和 proxy_ssl_name 后端域名; 解决 SNI 问题
- 用 tcpdump -i any port 后端端口 -w debug.pcap 抓包，比对 Nginx 发出的请求和后端实际收到的是否一致
