直接修复 client_body_temp 目录权限是解决上传失败和性能倒退最快速有效的手段，需确认路径与worker用户（如www-data），创建目录并设chown www-data:www-data与chmod 700，SELinux/AppArmor环境下还需配置对应策略，最后重启Nginx验证。
直接修复 client_body_temp 目录权限，是解决上传失败和性能倒退最快速有效的手段。问题不在于参数调得不够大，而在于 Nginx worker 进程根本写不进临时目录——所有本该落盘的上传请求都会卡住、超时、报 500 或 413（实际是 Permission denied），导致连接堆积、CPU 空转、吞吐骤降。
确认当前配置与运行身份
先别急着改权限，得知道改哪儿、给谁改：
- 运行
nginx -T | grep client_body_temp_path查出实际使用的路径；未显式配置则默认为/var/nginx/client_body_temp或编译时 prefix 对应路径（如/usr/local/nginx/client_body_temp） - 查主配置中
user指令（如user www-data;），再用ps aux | grep nginx确认 worker 进程真实用户（常见为www-data、nginx或nobody） - 检查该用户对目标目录是否具备写权限：用
ls -ld /path/to/client_body_temp看属主和权限位
创建并设置目录权限
路径存在且归属正确，是 Nginx 写入临时文件的前提：
- 若目录不存在，执行
sudo mkdir -p /var/nginx/client_body_temp（注意-p创建完整路径） - 设属主：
sudo chown www-data:www-data /var/nginx/client_body_temp（把www-data替换为你查到的实际 worker 用户） - 设权限：
sudo chmod 700 /var/nginx/client_body_temp——仅属主可读写执行，既满足 Nginx 写入需求，又避免 777 带来的安全风险 - 切勿跳过父目录检查：确保上层路径（如
/var/nginx/）对 worker 用户有执行权限（x），否则无法进入子目录
绕过 SELinux 或 AppArmor 干预
在 CentOS/RHEL 或 Ubuntu 上，即使文件权限全对，安全模块也可能静默拦截写操作：
- CentOS/RHEL：
sudo ausearch -m avc -ts recent | grep nginx，若看到avc: denied ... name="client_body_temp"，需打标签：sudo semanage fcontext -a -t httpd_var_run_t "/var/nginx/client_body_temp(/.*)?"，再sudo restorecon -Rv /var/nginx/client_body_temp - Ubuntu：
sudo aa-status | grep nginx确认是否 enforce 模式；若启用，编辑/etc/apparmor.d/usr.sbin.nginx，在已有/var/nginx/** rw,行附近补充/var/nginx/client_body_temp/ rw,，然后sudo systemctl reload apparmor
验证与防复发
改完不是终点，要确认真正生效且长期稳定：
- 重启 Nginx：
sudo nginx -t && sudo systemctl restart nginx - 模拟上传：
curl -X POST --data-binary @10MB-file.bin http://yourdomain/upload，观察是否返回 200 或预期 413（而非 500/403） - 检查日志：
tail -f /var/log/nginx/error.log，确认不再出现open() ".../client_body_temp/..." failed (13: Permission denied) - 定期巡检：把
ls -ld /var/nginx/client_body_temp加入运维检查清单，防止他人误改权限
