Nginx 中 upload_max_filesize 不生效是因为真正限制上传的是 client_max_body_size，需在 http/server/location 块中显式配置并重载；Apache 需检查 LimitRequestBody；PHP-FPM 需同步调整 fastcgi_read_timeout、request_terminate_timeout 等参数；多级代理下各层限制取最小值。
nginx 里 upload_max_filesize 不生效？其实是 client_max_body_size
php 的 upload_max_filesize 只管 php 层解析，真正拦住大文件的是 web 服务器。nginx 默认只允许 1mb，超了直接返回 413 request entity too large。
必须在 http、server 或 location 块里显式设 client_max_body_size：
client_max_body_size 100M;
- 放在
http块是全局生效；放在location块可针对上传接口单独放开（比如只给/api/upload设 500M） - 值后面单位必须写清楚：
100M可以，100默认是字节，别漏单位 - 改完记得
nginx -t && nginx -s reload，不重载配置不会生效
Apache 启用 mod_rewrite 后 POST 大文件失败？检查 LimitRequestBody
Apache 默认不限制请求体大小，但很多发行版或安全加固模板会悄悄加 LimitRequestBody，它比 PHP 配置更早拦截请求。
查当前值：运行 apachectl -M | grep rewrite 确认模块已加载后，在对应 VirtualHost 或 .htaccess 中补上：
LimitRequestBody 0
-
0表示不限制（注意不是省略，省略时 Apache 会用默认值 0，但某些旧版本有 bug，显式写更稳） - 如果只允许特定目录上传，把这行放进对应
<Directory>块里，避免全局放开带来风险 - 和 Nginx 不同，Apache 不需要重启，改完 .htaccess 就生效（前提是
AllowOverride All）
PHP-FPM 超时导致上传中断？fastcgi_read_timeout 不是唯一瓶颈
用户拖着 2GB 文件上传，等了 3 分钟卡住——大概率不是网络问题，而是 PHP-FPM 在等 CGI 响应时超时了。
关键参数有三个，缺一不可：
-
fastcgi_read_timeout（Nginx）：从 PHP-FPM 读响应的超时，建议设为上传最大耗时 + 30 秒缓冲 -
request_terminate_timeout（PHP-FPM pool 配置）：单个请求总执行时间上限，必须 ≥ Nginx 的fastcgi_read_timeout -
max_execution_time（PHP ini）：脚本级超时，它只在 PHP 开始执行后才计时，对上传阶段无效，别指望靠它延长上传时间
典型组合示例（支持 10 分钟上传）：
# nginx.conf<br>fastcgi_read_timeout 630;<br><br># www.conf<br>request_terminate_timeout = 630
多级代理下 client_max_body_size 会被覆盖？优先级和继承规则要理清
前端是 Nginx → 中间是 Traefik → 后端是 Apache，结果上传卡在第二层？因为每层代理都可能独立校验请求体大小，且后端的限制不会自动继承前端的设置。
必须逐层确认并显式配置：
- Traefik v2+：在
http.routers的middlewares中加buffering，并设maxRequestBodyBytes - Cloudflare 免费版默认限制 100MB，若需更大，得升 Pro 或绕过其代理（比如直连源站 IP）
- Docker 容器内运行 Nginx 时，宿主机防火墙或
iptables有时会截断大包，可临时关掉 conntrack 测试：sysctl -w net.netfilter.nf_conntrack_enable=0
最麻烦的不是某一层没配，而是几层都配了但数值不一致——最终生效的是路径上**最小的那个限制值**。
