Nginx处理大POST请求返回500错误的根本原因是工作进程对client_body_temp目录缺乏w+x权限；需确认运行用户与路径，执行chown nginx:nginx和chmod 750修复，并优化client_body_buffer_size与client_max_body_size减少磁盘写入。
当 Nginx 在处理大体积 POST 请求时返回 500 错误，并在 error.log 中出现 open() "/path/to/client_body_temp/xxx" failed (13: Permission denied)，根本原因是：Nginx 工作进程无法向 client_body_temp 目录写入临时文件。这不是配置写错了，而是操作系统层面的权限卡点。
确认 Nginx 运行用户和 client_body_temp 路径
先明确两个关键信息，避免盲目操作：
- 查 Nginx 实际运行用户：执行
ps aux | grep nginx | grep -v grep，看 worker 进程的 USER 列（常见为nginx、www-data或自定义用户如app） - 查 client_body_temp 实际路径：在
nginx.conf的http块中找client_body_temp_path指令；若未显式设置，则默认为安装目录下的client_body_temp子目录（如/usr/local/nginx/client_body_temp或/var/lib/nginx/client_body_temp）
检查并修复 client_body_temp 目录权限
该目录必须满足：Nginx 运行用户对该目录有 w（写）+ x（执行） 权限。x 权限不可省略，因为 Linux 要进入目录创建文件，必须有执行权限。
- 查看当前权限：
ls -ld /path/to/client_body_temp - 若属主不是 Nginx 用户，且组/其他无写权限，就必然失败
- 推荐修复方式（安全且清晰）：
sudo chown nginx:nginx /path/to/client_body_tempsudo chmod 750 /path/to/client_body_temp（确保 nginx 用户可读写执行，同组可读执行，其他无权） - 不推荐直接
chmod 777—— 会带来安全隐患
验证是否涉及其他临时目录连锁问题
Nginx 的各类临时目录（proxy_temp、fastcgi_temp、uwsgi_temp 等）共用同一套权限逻辑。如果同时遇到 net::ERR_INCOMPLETE_CHUNKED_ENCODING 或上游代理失败，很可能这些目录也存在权限问题。
- 一并检查：
ls -ld /path/to/{proxy,fastcgi,uwsgi}_temp - 统一修复（假设路径在同一父级下）：
sudo chown -R nginx:nginx /path/to/{client_body,proxy,fastcgi,uwsgi}_tempsudo chmod -R 750 /path/to/{client_body,proxy,fastcgi,uwsgi}_temp - 注意：不要对整个
/usr/local/nginx或/var/lib/nginx递归 chmod，只动 temp 类目录
配合配置优化减少临时文件依赖
权限修好只是治标，合理调大内存缓冲区能绕过磁盘写入，提升性能和稳定性：
- 在
http或server块中添加：client_body_buffer_size 8k;（增大单次内存缓冲，默认通常 8k 或 16k）client_max_body_size 20m;（设为业务所需最大值，如上传头像/文档） - 关键逻辑：当请求体 ≤
client_body_buffer_size，全程走内存，不碰磁盘；超了才落临时文件。因此把两者设为接近值（如都设为 8M），可大幅降低临时文件使用频率 - 修改后务必执行
sudo nginx -t && sudo nginx -s reload验证并重载
