Nginx 502错误排查方法详解

Nginx 502错误并非简单的“后端挂了”，而是代理层与上游服务之间通信失败的综合体现——可能是网络不通、配置失配、超时过短、缓冲区不足、端口耗尽，或是后端资源濒临崩溃的隐性告警；本文直击排查核心：从实时盯紧error.log日志入手，依据upstream prematurely closed connection、Connection refused等关键线索快速分层定位，再结合curl实测连通性、HTTPS SNI配置校验、timeout与buffer参数调优、PHP-FPM/Java资源水位分析，层层剥茧，帮你把飘忽不定的“偶发502”变成可监控、可复现、可根治的确定性问题。

502 错误本质是 Nginx 作为代理，收不到后端的有效响应 —— 不是后端挂了，就是 Nginx 没配对，或者中间被拦住了。

查 Nginx 错误日志定位第一线索

错误日志里那行 upstream prematurely closed connection 或 Connection refused 或 Cannot assign requested address，直接决定你下一步往哪查。别跳过这步，90% 的排查卡在没看日志。

• /var/log/nginx/error.log 是默认路径，用 tail -f /var/log/nginx/error.log 实时盯住它
• 如果日志里反复出现 connect() failed (111: Connection refused)，说明 Nginx 根本连不上 upstream 地址（端口错、服务没启、防火墙挡了）
• 如果出现 recv() failed (104: Connection reset by peer)，大概率是后端进程崩溃或主动断连（比如 PHP-FPM worker 被杀、Java 应用 OOM）
• 如果出现 Cannot assign requested address，不是配置问题，是本地端口耗尽（短连接高并发场景），要调 net.ipv4.ip_local_port_range 和 net.ipv4.tcp_tw_reuse

验证 upstream 是否可达且响应正常

别信配置文件里写的地址，要用 Nginx 所在机器的视角真实发起请求。

• 先 curl -v http://127.0.0.1:8080/health（替换成你的 upstream 地址和端口），看是否返回 200。如果超时或拒绝，检查后端服务状态：systemctl status php-fpm 或 ss -tlnp | grep :8080
• 如果是 HTTPS upstream，必须加 proxy_ssl_server_name on;，否则 SNI 不匹配，后端 TLS 握手失败直接关连接 —— 这是 HTTPS 域名反向代理最常漏的配置
• 如果 upstream 是域名，确认 Nginx 机器能正确解析：运行 nslookup your-upstream-domain，别依赖本地 hosts；DNS 解析慢也会拖垮 proxy_connect_timeout

检查 timeout 和 buffer 相关参数是否过小

后端处理稍慢或返回头/体稍大，Nginx 就会主动断开并报 502，不是后端有问题，是你给的时间和空间不够。

• FastCGI 场景（PHP）重点调这三个：fastcgi_connect_timeout、fastcgi_send_timeout、fastcgi_read_timeout，建议统一设为 300（单位秒）
• 普通 proxy 场景（Java/Node.js 等）对应的是：proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout
• Header 太大？加 large_client_header_buffers 4 16k; 到 http 块；后端返回的 header 超过默认 1k，Nginx 会直接拒收
• Buffer 不够？常见于大文件上传或长响应体：proxy_buffer_size 128k; + proxy_buffers 8 128k;，避免 “upstream sent too big header” 类错误

确认后端资源是否真能承载当前流量

很多 502 表面是网络问题，实际是后端被压垮了 —— 它还活着，但已无法响应新请求。

• PHP-FPM：检查 pm.max_children 是否被占满，看 pm.status_path 输出里的 active processes 是否接近上限
• Java 应用：用 jstat -gc 看是否频繁 Full GC，或 dmesg | grep -i "killed process" 查 OOM Killer 日志
• Nginx 自身 CPU 打满？top -p $(pgrep nginx) 看 worker 进程占用，若持续 100%，可能是正则重写太重、log_format 含大量变量、或 SSL 握手压力过大
• 别忽略 swap：free -h 看 SwapUsed，如果非零且持续增长，物理内存不足会导致进程被随机 kill，表现为“间歇性 502”

真正难缠的 502 往往藏在时间窗口和资源边界上 —— 比如只在每小时整点压测时出现，或是某次部署后第 37 分钟开始飘红。这时候日志时间戳、后端监控曲线、Nginx worker 连接数趋势，三者得对齐着看。

好了，本文到此结束，带大家了解了《Nginx 502错误排查方法详解》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！