根本原因是Nginx、PHP-FPM与PHP三层超时未对齐：max_input_time控制PHP解析POST体（含音频流式写入tmp），fastcgi_read_timeout控制Nginx等待PHP响应，request_terminate_timeout由PHP-FPM强制终止进程，三者必须同步设为一致值（如600秒），缺一即触发504或空白页。
PHP上传音频时超时的根本原因在哪
音频文件上传卡在 99%、返回 504 Gateway Timeout 或直接空白页，通常不是 PHP 脚本执行慢，而是整个请求链路中某一层提前终止了连接。关键要分清：是 PHP 解析请求超时？还是 Nginx 等代理等不及？或是 PHP-FPM 主动 kill？三者独立生效，改错一个就白调。
必须同步调整的四个 PHP 超时参数
max_execution_time 和 max_input_time 常被混淆，但它们控制完全不同的阶段：
-
max_execution_time：从脚本开始执行（move_uploaded_file()或后续处理）起计时，对纯上传动作影响小，但音频转码、FFmpeg 调用等会触发它 -
max_input_time：专控“PHP 解析整个 POST 请求体”的耗时，包括读取 multipart boundary、流式写入临时文件的过程——大音频上传最常卡在这里 -
upload_max_filesize和post_max_size虽非超时参数，但若设得太小，PHP 在解析前就静默丢弃请求，现象和超时一模一样（$_FILES为空、$_POST为空） -
memory_limit不足不会报超时，但会导致Allowed memory size exhausted；上传阶段本身不占大内存，但后续用file_get_contents()读整段音频就会崩
推荐配置（以 500MB 音频为例）：
upload_max_filesize = 512M post_max_size = 512M max_execution_time = 600 max_input_time = 600 memory_limit = 1G
Nginx 层超时设置不能漏
即使 PHP 参数全调高，Nginx 在收到完整请求前就可能中断连接。常见错误是只加了 client_max_body_size，却忘了超时项：
立即学习“PHP免费学习笔记（深入）”；
-
client_body_timeout 600：防止用户网络抖动导致上传暂停后被断开 -
client_max_body_size 512M：必须 ≥ PHP 的post_max_size，否则请求根本到不了 PHP - 若用
fastcgi_pass（常见于 PHP-FPM），必须配fastcgi_read_timeout 600；若用proxy_pass，则用proxy_read_timeout 600 - CDN 或负载均衡器（如阿里云 SLB、AWS ALB）也有自身超时限制，需单独确认并同步调大
PHP-FPM 的 request_terminate_timeout 更容易被忽略
PHP-FPM 进程管理器有自己的超时兜底机制，它不看 max_execution_time，而是直接杀进程：
-
request_terminate_timeout默认常为 30s 或 0（禁用），若设为非零值（如 60s），哪怕 PHP 脚本还在跑，FPM 也会强制终止并返回502 Bad Gateway - 检查路径：
/etc/php/8.2/fpm/pool.d/www.conf（版本路径依环境而定） - 修改后必须重启 FPM：
sudo systemctl restart php8.2-fpm，reload 不生效 - 同时建议调大
request_slowlog_timeout，便于后续排查哪一步真正慢
真正上传音频时，最易出问题的是 max_input_time 和 fastcgi_read_timeout 这两个时间点不一致，导致 Nginx 已经断连，PHP 还在等数据流——这种错位比单纯调大数值更难定位。
