如何处理 Nginx 反向代理中的 502 Bad Gateway 错误-Nginx-PHP中文网

502 bad gateway 错误本质是 nginx 作为代理未能从后端服务获取有效响应，需从“能不能通”“会不会等”“够不够用”“配没配对”四方面排查：直连验证后端可用性、调整超时参数、校验代理头与协议配置、扩大缓冲区及资源限制。

如何处理 nginx 反向代理中的 502 bad gateway 错误

502 Bad Gateway 错误本质是 Nginx 作为代理，没能从后端服务拿到有效响应。它不说明 Nginx 本身坏了，而是上游出了问题或转发过程卡住了。排查要从“能不能通”“会不会等”“够不够用”“配没配对”四个角度入手。

这是最基础也最容易被跳过的一步。别只看进程在不在，要看它是否真在监听、能否响应请求：

用 curl -v http://127.0.0.1:端口/健康检查路径 直连后端，看是否返回 200 和预期内容
执行 netstat -tuln | grep :端口 或 ss -tuln | grep :端口，确认监听地址是 0.0.0.0 或 127.0.0.1，而不是仅 localhost 或特定 IP
检查后端日志（如 Node.js 的 stdout、PHP-FPM 的 error log），看是否有启动失败、崩溃或拒绝连接的记录
如果是容器环境，确认容器已运行且端口已正确映射（docker ps + docker logs 容器名）

后端响应慢、连接建立慢或长连接维持不住，都会触发 502。默认值往往不适合实际业务：

gate-info-macroimpact

通过Gate-Info和Gate-News MCP进行宏观驱动的加密货币分析，用于CPI、NFP、美联储、利率、工资等宏观因素与加密货币、日历或指标的关联。

下载

proxy_connect_timeout：设为 30–60 秒，避免因网络抖动或后端启动慢导致连接失败
proxy_read_timeout：对普通 API 设 120 秒起步；对 WebSocket 或流式接口必须设大（如 86400），否则空闲后自动断连引发后续 502
proxy_send_timeout：一般保持与 read timeout 一致即可，除非后端接收请求特别慢
所有超时值需大于后端自身处理耗时，并留出缓冲余量

很多 502 其实是“配错了头”，Nginx 没把请求原样或合规地转给后端：

HTTPS 反代带 SNI 的站点，必须加 proxy_ssl_server_name on;，否则 TLS 握手失败直接报 502
WebSocket 场景下，缺一不可：proxy_http_version 1.1;、proxy_set_header Upgrade $http_upgrade;、proxy_set_header Connection "upgrade";
Host 头错误很常见：若后端依赖 Host 判断租户或路由，别用 $host，应写死为后端期望的域名，如 proxy_set_header Host api.example.com;
路径转发注意尾部斜杠：location /api/ { proxy_pass http://backend; } 是正确透传；若写成 proxy_pass http://backend/;，会把 /api/abc 剪成 /abc，导致后端找不到路由

后端返回头过大、响应体太大或并发高了，Nginx 默认缓冲和连接池撑不住：

响应头超 1KB 就可能触发 upstream sent too big header：调大 proxy_buffer_size（建议 32k–64k）
响应体大或并发高：增加 proxy_buffers（如 16 32k）和 proxy_busy_buffers_size（如 64k）
PHP-FPM 场景下，检查 pm.max_children 是否足够，内存是否溢出（看 slowlog 和 dmesg）
Nginx 自身 worker_connections 和 keepalive 连接数也要匹配业务并发量，避免连接耗尽