Nginx 的 client_max_body_size、client_body_timeout 和 proxy_read_timeout 是大文件上传超时的关键配置，PHP 的 max_execution_time 和 max_input_time 对上传阶段无效。
PHP 的 max_execution_time 和 max_input_time 对大文件上传无效
很多人以为调高 max_execution_time 就能解决上传超时，其实它只控制脚本执行时间，而文件上传阶段（Nginx 接收并转发到 PHP）根本没进 PHP 执行流程。真正卡住的地方在 Nginx 层——它默认 60 秒就断开连接，此时你甚至看不到 PHP 错误日志，只有 Nginx 的 408 Request Time-out 或直接中断。
实操建议：
-
max_execution_time可设为 0（不限制），但必须配合 Nginx 调整，否则毫无意义 -
max_input_time控制 POST 数据解析耗时，对大文件上传影响有限，不建议主攻这里 - 重点盯死 Nginx 的
client_max_body_size、client_body_timeout和proxy_read_timeout（如果用了反向代理）
Nginx 配置中哪些 timeout 参数必须改
ThinkPHP 本身不处理上传的网络层超时，全靠 Nginx 把文件完整接进来再交给 PHP-FPM。只要其中任意一个环节超时，上传就失败，且错误表现不一致（有时是空白页，有时是 502 Bad Gateway，有时是 413 Request Entity Too Large）。
关键配置项（写在 server 或 location ~ \.php$ 块内）：
立即学习“PHP免费学习笔记（深入）”；
-
client_max_body_size 100M：必须大于你要传的最大文件，单位可写M或G；不设或设太小会返回413 Request Entity Too Large -
client_body_timeout 300：Nginx 读取客户端请求体的超时时间，单位秒；上传慢速网络用户容易触发408 -
proxy_read_timeout 300（若用proxy_pass转发到 PHP-FPM）：Nginx 等待后端响应的时间，PHP 处理上传回调（如移动临时文件、验证）耗时长时需同步加大 - 避免只改
fastcgi_read_timeout却漏掉client_body_timeout——前者只管 PHP-FPM 返回，后者才管“上传过程中断”
ThinkPHP 自身上传逻辑的隐性瓶颈
即使 Nginx 和 PHP 层都调好了，ThinkPHP 的 think\File 或 $request->file() 在处理超大文件时仍可能因内存或临时目录权限出问题。
常见现象与对策：
- 上传中途报
upload_tmp_dir无写入权限或磁盘满：检查php.ini中的upload_tmp_dir指向路径是否可写、空间是否充足（不是系统/tmp，而是 PHP 实际使用的那个） - 内存溢出（
Fatal error: Allowed memory size exhausted）：ThinkPHP 默认会把整个文件内容读进内存做 MIME 检测；用moveTo()前加isValid()并确保不调用getInfo()或getContent() - 上传成功但
moveTo()失败：目标目录权限不足，或启用了 SELinux（Linux 上常见），用ls -Z查看上下文，必要时运行chcon -Rt httpd_sys_rw_content_t /path/to/upload
调试时怎么看哪个环节挂了
别靠猜。上传失败时，分三段查日志：
- Nginx 错误日志（
error_log）：搜408、413、502、upstream timed out—— 出现这些基本锁定 Nginx 配置 - PHP 错误日志（
error_log）：搜upload、tmp、move_uploaded_file—— 若完全没记录，说明请求压根没进 PHP - 浏览器开发者工具 Network 标签：看请求状态码和响应头；如果是
0 status或canceled，大概率是 Nginx 主动断连
最易被忽略的是：Nginx 配置 reload 后，要确认实际生效的是哪一份（nginx -t && nginx -s reload 不等于配置已更新，尤其有 include 多个 conf 文件时）。用 nginx -T | grep -A5 'client_body_timeout' 直接看最终合并后的配置更可靠。
