502 Bad Gateway超时需按日志精准调参：connect失败调proxy_connect_timeout，读响应头超时调proxy_read_timeout，发请求卡住调proxy_send_timeout；PHP-FPM还需同步设fastcgi_*系列超时；调后须语法检查并验证。

502 Bad Gateway 出现超时类报错，核心是 Nginx 等不及后端响应就主动断开连接。关键不是盲目调大所有 timeout，而是根据错误日志中明确指出的超时类型，精准调整对应参数。

看日志，先分清是哪一环超时

打开 /var/log/nginx/error.log，重点识别以下三类典型提示：

• “connect() failed ... while connecting to upstream” → 连接建立失败，问题在 proxy_connect_timeout
• “upstream timed out (110: connection timed out) while reading response header from upstream” → 已连上但等不到响应头，问题在 proxy_read_timeout
• “upstream timed out ... while sending request to upstream” → Nginx 向后端发请求时卡住，问题在 proxy_send_timeout

按需调整三个核心超时值

在 location 或 server 块中设置，避免全局粗放修改：

GateCrash Forms

以 CLI 为先的表单构建器，采用 BYOK 理念。通过JSON Schema 生成美观的 HTML 表单，使用您自己的 SMTP 服务器处理提交，存储响应...

下载

• proxy_connect_timeout：设为 30–60 秒。适用于后端启动慢、网络抖动或 TLS 握手延迟场景
• proxy_read_timeout：普通 API 接口建议 120 秒起步；流式接口（如 SSE、长轮询）或导出类任务必须设为 3600 秒甚至 86400 秒
• proxy_send_timeout：一般与 read timeout 保持一致即可；仅当前端上传大文件且后端接收极慢时才需单独加大

FastCGI 场景要单独处理

若后端是 PHP-FPM，不能只改 proxy_* 参数，必须同步调整 FastCGI 专用超时：

• fastcgi_connect_timeout：对应连接阶段，建议 30 秒
• fastcgi_read_timeout：对应等待 PHP 执行结果，必须 ≥ PHP 的 max_execution_time，常见设为 300 秒
• fastcgi_send_timeout：较少调整，通常保持默认或与 read 一致

调完务必验证再上线

参数不是越大越好，过长的超时会拖垮 worker 进程，加剧资源堆积：

• 执行 nginx -t 检查语法
• 用 curl -v http://your-domain/health 模拟请求，观察是否仍返回 502
• 检查后端服务实际耗时（如 PHP 日志里的脚本执行时间），确保 Nginx 超时值比它多留 20%–50% 缓冲