必须同步调整Nginx、PHP-FPM和PHP三层配置：Nginx设client_max_body_size≥post_max_size，PHP调大upload_max_filesize与post_max_size并保障tmp目录权限，PHP-FPM放开request_terminate_timeout且Nginx配齐fastcgi_connect/send/read_timeout三值一致。
Nginx 本身不解析 PHP 文件，上传限制和超时控制是多层协同的结果：Nginx 拦截请求体、PHP-FPM 管理执行生命周期、PHP 内核解析 multipart 数据。单改某一层配置无效，必须三者对齐。
上传大小限制需三层同步放开
文件上传失败（如 413 错误、$_FILES 为空）往往卡在第一道关卡：
-
Nginx 层：通过
client_max_body_size限制整个 HTTP 请求体（含文件 + 表单字段 + boundary），必须设为 ≥ PHP 的post_max_size。建议加在server块或location ~ \.php$内，例如：client_max_body_size 512M; -
PHP 层：两个关键参数必须同时调大：
–upload_max_filesize = 512M（单文件上限）
–post_max_size = 520M（整段 POST 数据，含多个字段开销）
仅改一个，PHP 会静默丢弃整个请求。 -
临时目录保障：PHP 将上传文件先写入
upload_tmp_dir（如/var/www/uploads/tmp）。该目录必须存在、www 用户可写、空间充足。否则move_uploaded_file()会失败且$_FILES['error']仍为 0。
超时问题本质是三段通信未对齐
大文件上传途中返回 504 Gateway Timeout，不是 PHP 脚本卡住，而是 Nginx 与 PHP-FPM 在某次交互中主动断开：
-
Nginx → PHP-FPM 发送阶段：用
fastcgi_send_timeout 600控制 Nginx 向 PHP-FPM 发送完整请求（含大文件流）的最长时间； -
Nginx ← PHP-FPM 响应阶段：用
fastcgi_read_timeout 600控制等待 PHP-FPM 返回响应的时长； -
连接建立阶段：用
fastcgi_connect_timeout 600防止高负载下握手失败； -
PHP-FPM 自身熔断：
request_terminate_timeout（在www.conf中）必须 ≥ 上述 timeout，否则 PHP-FPM 会在 Nginx 之前强制杀掉进程；max_execution_time在此之下失效。
缓冲区与临时路径常被忽略
即使大小和超时都设对，上传仍可能卡死或报 upstream buffer is too small：
立即学习“PHP免费学习笔记（深入）”；
- 在 Nginx 的
location ~ \.php$块中添加缓冲配置：fastcgi_buffer_size 128k;fastcgi_buffers 4 256k;fastcgi_busy_buffers_size 512k;fastcgi_temp_file_write_size 512k; - 确保
fastcgi_temp_path（默认在 Nginx 安装目录下）对 www 用户可写；若使用自定义upload_tmp_dir，也要同步确认权限； - CDN 或负载均衡器前端也需设置
client_max_body_size，否则请求在入口就被拦截。
每改一项配置后，必须分别重载对应服务：nginx -t && systemctl reload nginx、systemctl restart php8.2-fpm（版本号需匹配），不能只 reload PHP-FPM 或只重启 Nginx。
