fastcgi_send_timeout 控制 Nginx 向 PHP-FPM 发送请求的最长时间，单位秒，默认作用于写操作阶段，超时返回 504/502；需与 client_body_timeout、fastcgi_read_timeout 及 PHP 层超时协同配置。
fastcgi_send_timeout 控制 Nginx 向 PHP-FPM 发送请求（包括请求头和请求体）的最长时间。它不是脚本执行超时，而是“发数据”阶段的写操作超时——一旦超时，Nginx 会中断连接，可能返回 504 或 502 错误。
配置位置和语法
该指令可放在 http、server 或 location 块中，但实际生效需落在处理 PHP 的上下文中。常见写法：
- 在站点配置的
location ~ \.php(.*)$ { }块内直接设置 - 若用于全局 PHP 处理逻辑，也可放在 server 块中（确保覆盖到 PHP 路由）
- 语法为：
fastcgi_send_timeout 300;（单位默认是秒，支持m、h，如5m）
合理取值建议
该值应与 fastcgi_read_timeout 和 PHP 层超时协调，但通常不需要设得比后者更大。参考场景：
- 普通 Web 请求（表单提交、小文件上传）：60～120 秒足够
- 含大 POST 数据或慢网络上传：可设为 300（5 分钟），但需同步检查
client_body_timeout是否允许客户端花时间发完数据 - 同机部署（127.0.0.1 或 Unix socket）：一般不会卡在发送阶段，设 120 秒已偏保守
- 若频繁触发超时，优先排查网络抖动、PHP-FPM 进程阻塞、或客户端异常断连，而非盲目调大
必须同步检查的关联项
单独改 fastcgi_send_timeout 很难解决问题，容易掩盖真实瓶颈：
-
client_body_timeout：客户端发请求体的超时，若它比fastcgi_send_timeout小，Nginx 在收到完整 body 前就断开，后者根本没机会生效 -
fastcgi_read_timeout：必须 ≥fastcgi_send_timeout，否则刚发完就立刻开始读超时倒计时，逻辑断裂 - PHP 层
max_execution_time和 PHP-FPM 的request_terminate_timeout：它们共同决定整个请求生命周期上限，fastcgi_send_timeout只管“发”的一环
验证是否生效
修改后重载 Nginx（nginx -s reload 或宝塔点【重载配置】），再通过以下方式确认：
- 临时让 PHP-FPM 暂停响应（如注释掉 fastcgi_pass 行或停服务），观察 error.log 中是否出现
upstream timed out (110: Connection timed out) while sending request to upstream - 用大体积 POST 请求测试（如上传 50MB 文件），配合
curl -v看连接是否在预期时间中断 - 注意：不要依赖 ab 或 wrk 压测判断，它们可能复用连接或忽略写超时细节
