Nginx启动失败主因是工作进程用户（如www-data）对路径各级目录缺乏执行权限。需检查user配置、进程属主，逐级赋予x权限或修改归属，同时排查SELinux/AppArmor拦截，并验证日志、网站根目录及临时目录权限。
Nginx 启动失败，报错提示类似 open() "/var/log/nginx/access.log" failed (13: Permission denied) 或 chdir() to "/var/www/html" failed (13: Permission denied)，大概率是目录或文件权限/归属设置不当。核心问题不是“能不能读”，而是“Nginx 工作进程（通常是 www-data 或 nginx 用户）有没有权限进入路径中的每一级目录”。
确认 Nginx 运行用户和组
先查配置中指定的用户，再验证实际运行身份：
- 运行
grep "user " /etc/nginx/nginx.conf，例如输出user www-data;，说明工作进程以www-data身份运行 - 执行
ps aux | grep nginx | grep -v grep，看 master 进程属主是否一致；worker 进程应显示为该用户（如www-data） - 若未显式配置
user指令，Nginx 默认使用启动它的用户（常见于源码编译未指定时），但多数包管理安装已预设为www-data或nginx
检查日志与网站根目录的完整路径权限
权限问题常出在“路径中任一父目录不可进入”，而不仅是目标目录本身。以典型路径 /var/www/example.com/public 为例：
- 确保
/var、/var/www、/var/www/example.com、/var/www/example.com/public每一级对 Nginx 用户都至少有x（执行）权限（即“可进入”） - 常用修复命令：
sudo chmod o+x /var/www /var/www/example.com（开放其他用户执行权限） - 更安全做法是改归属：
sudo chown -R www-data:www-data /var/www/example.com，再设权限：sudo chmod 755 /var/www/example.com（目录）和644（静态文件） -
特别注意：日志目录（如
/var/log/nginx）必须允许 Nginx 用户写入，通常设为sudo chown www-data:adm /var/log/nginx并sudo chmod 755 /var/log/nginx
验证 SELinux 或 AppArmor 是否拦截（仅限对应系统）
在 CentOS/RHEL（SELinux）或 Ubuntu（AppArmor）上，即使传统权限正确，安全模块也可能阻止访问：
- CentOS：运行
sudo ausearch -m avc -ts recent | grep nginx，若有拒绝记录，临时测试可sudo setenforce 0；确认后用sudo semanage fcontext -a -t httpd_log_t "/var/log/nginx(/.*)?"等修复上下文 - Ubuntu：检查
sudo aa-status | grep nginx，若启用且受限，可临时禁用配置：sudo ln -sf /etc/apparmor.d/usr.sbin.nginx /etc/apparmor.d/disable/，再sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.nginx
快速复位常用目录权限参考
适用于 Debian/Ubuntu（www-data）或 CentOS（nginx）默认场景：
-
网站根目录：
sudo chown -R www-data:www-data /var/www/example.com+sudo find /var/www/example.com -type d -exec chmod 755 {} \;+sudo find /var/www/example.com -type f -exec chmod 644 {} \; -
日志目录：
sudo chown www-data:adm /var/log/nginx+sudo chmod 755 /var/log/nginx -
临时文件目录（如
client_body_temp_path）：sudo chown www-data:www-data /var/lib/nginx+sudo chmod 755 /var/lib/nginx - 完成后务必
sudo nginx -t测试配置，再sudo systemctl restart nginx
