Master进程不写业务日志，关键在于Worker进程能否对error_log、access_log及临时目录（如client_body_temp_path）执行写入操作；需确保路径存在、属主为Worker用户（如www-data）、权限为755，并通过sudo -u www-data touch测试验证。
Master进程本身不写业务日志，但若其配置的日志路径（如 error_log、access_log）或关联的临时目录（如 client_body_temp_path）权限设置不当，会导致降权后的Worker进程因无写入权限而静默失败——表现为日志缺失、上传中断、缓存不可用等现象。关键不是“Master有没有权限”，而是“Worker能不能写进去”。
确认日志与临时目录的实际归属和权限
不能只看配置文件写了什么路径，要检查这些路径在系统中是否真实存在、归属是否正确、权限是否放行：
- 执行
ls -ld /var/log/nginx /var/lib/nginx/tmp（路径以你的配置为准），确认目录所有者是Worker用户（如www-data或nginx），而非root - 目录权限建议为
755（owner可读写执行，group/o仅读执行）；若需组内协作，可用775，但避免777 - 检查
nginx -t是否通过；若报错 “open() ‘/var/log/nginx/error.log’ failed (13: Permission denied)”，说明Worker进程已尝试写入但被拒绝
修正user指令与目录所有权的匹配关系
user 指令必须位于 events 块之前，且明确指定Worker运行身份。常见错误是配置了 user www-data;，但没给该用户分配对应目录权限：
- 确保系统中存在该用户：
id www-data（Debian/Ubuntu）或id nginx（RHEL/CentOS） - 批量修复权限：
sudo chown -R www-data:www-data /var/log/nginx /var/lib/nginx/tmp - 禁用
user root;—— 这会让Worker也以root运行，违背最小权限原则，且仍可能因SELinux或容器环境策略被拦截
验证Worker进程的真实写入能力
配置改完不等于生效，必须验证Worker是否真能打开并写入目标路径：
- 查出一个Worker PID：
ps -o pid,user,comm -C nginx | grep -v master - 检查它打开的文件句柄：
lsof -p $PID | grep -E "(log|tmp)"，确认没有(DENIED)或报错 - 手动模拟写入：
sudo -u www-data touch /var/log/nginx/test-write && sudo -u www-data rm /var/log/nginx/test-write
注意容器与SELinux等增强机制的影响
在Docker或启用了SELinux的系统中，即使传统权限正确，也可能因上下文限制导致写入失败：
- Docker：挂载日志目录时加
:z或:Z标签（如-v /host/logs:/var/log/nginx:z），让SELinux自动打标 - SELinux：临时排查可设为宽容模式
setenforce 0，若问题消失，则需用audit2why分析AVC日志并生成策略 - Kubernetes：确保Pod Security Context中
runAsUser与Nginx配置的user一致，并为volumeMount设置合适fsGroup
