413错误需同时修改Nginx的client_max_body_size（必须在server块内）和PHP的upload_max_filesize与post_max_size（后者≥前者），并确认配置生效、路径权限正确。
phpEnv 里改 client_max_body_size 无效？先确认你改的是谁的配置
phpEnv 是 Windows 下集成环境，自带 Nginx + PHP，但它的 Nginx 配置文件位置和加载逻辑容易被误判。很多人直接去修改 nginx.conf，却发现重启后上传还是 413 错误——因为 phpEnv 实际加载的是 vhosts.conf 或某个 include 的站点配置，而不是主配置文件。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 打开 phpEnv 安装目录 →
nginx/conf/vhosts.conf（或conf/sites-enabled/下对应站点文件） - 找到你要改的
server块，在里面加client_max_body_size 50M;，不是在http块顶层加 - 确保这行不在
location ~ \.php$里面，而是在同级的server块内（否则可能不生效） - 改完后必须执行
nginx -t检查语法，再用 phpEnv 控制面板「重启 Nginx」，不能只点「重载」
为什么改了 client_max_body_size 还报 413？检查 PHP 层限制
Nginx 拦截前，PHP 自身也有上传限制，两个都得过。Nginx 返回 413 是它自己拦的；但如果 Nginx 放行了、PHP 拒绝，通常会是 500 或空白页，但某些 phpEnv 版本下也可能表现为超时或静默失败。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 编辑
php/php.ini（注意：是 phpEnv 当前启用的 PHP 版本目录下的那个），搜upload_max_filesize和post_max_size - 两者都要调大，且
post_max_size必须 ≥upload_max_filesize（比如设成upload_max_filesize = 50M，post_max_size = 52M） - 改完重启 php-fpm：在 phpEnv 控制面板里「重启 PHP」，或手动执行
php/php-fpm.exe -t+ 重启服务 - 用
phpinfo()页面确认这些值是否已生效，别只信配置文件内容
client_max_body_size 放错作用域会导致完全不生效
这个参数支持写在 http、server、location 三个层级，但行为不同：越靠近请求路径的层级优先级越高，且 location 块里设了，只对匹配该 location 的请求生效。
常见错误：
- 把
client_max_body_size 50M;写在location ~ \.php$里 → 失效，Nginx 不允许在此处设置该指令 - 写在
http块但 phpEnv 的 vhosts 是通过include加载的，结果被 server 块里的默认值（1M）覆盖 - 写了但没分号，或者用了中文标点 →
nginx -t会报错，但 phpEnv 界面未必提示
推荐做法：固定写在 server 块开头，紧挨着 listen 和 server_name 下方，格式严格为 client_max_body_size 50M;
临时文件路径和权限问题在 Windows phpEnv 上容易被忽略
当上传文件超过 client_body_buffer_size（默认 8K 或 16K），Nginx 会写临时文件到 client_body_temp_path 指定目录。Windows 下如果该路径不存在、无写入权限、或含空格/中文，就会静默失败，有时表现为上传卡住或返回 413。
解决方法：
- 在
server块里显式指定：client_body_temp_path D:/phpEnv/nginx/client_body_temp; - 手动创建该目录，并确保运行 nginx.exe 的用户（通常是当前 Windows 登录用户）有完全控制权限
- 避免路径含中文、空格或盘符后直接跟冒号以外的符号（比如
D:\temp可能不如D:/phpEnv/nginx/temp稳定）
这个点在 Linux 环境下常被强调，但在 phpEnv 的 Windows 场景里，几乎没人查，却高频导致上传失败。
