systemd管理Nginx启动失败时，应依次检查服务状态与日志、配置语法及路径、用户权限与运行目录、端口占用及SELinux/AppArmor限制。
当使用 systemd 管理 Nginx 服务时，启动失败是常见问题。核心排查思路是：先看服务状态和日志，再检查配置语法与文件权限，最后确认端口、用户及依赖项是否就绪。
查看服务状态与错误日志
执行 systemctl status nginx 查看当前状态和最近几行错误信息。若显示 failed 或 exited，重点关注 “Process:” 后的 PID 和 “Main PID” 行，以及 “Failed with result” 提示。
进一步用 journalctl -u nginx -n 50 -e 查看完整日志（-n 50 表示最近 50 行，-e 跳至末尾）。常见线索包括：
- “failed to start” + “address already in use” → 端口被占用
- “invalid number of arguments” 或 “unknown directive” → 配置语法错误
- “permission denied” 或 “no such file or directory” → 文件路径错误或权限不足
验证 Nginx 配置语法与主配置加载路径
systemd 启动失败常因配置不合法。先手动运行 nginx -t 检查语法。若报错，按提示定位 /etc/nginx/nginx.conf 或子配置文件（如 /etc/nginx/conf.d/*.conf）中的问题。
注意：systemd 的 nginx 单元文件（/usr/lib/systemd/system/nginx.service 或 /etc/systemd/system/nginx.service）中可能指定了自定义配置路径（如 -c /path/to/nginx.conf），需确认该路径存在且可读。运行 systemctl cat nginx 可查看实际启用的 service 文件内容。
检查用户、权限与运行时目录
Nginx 主进程通常以 root 运行，但工作进程默认切换为 nginx 用户（在 nginx.conf 中由 user 指令指定）。需确保：
- 用户 nginx 存在：id nginx；不存在则创建：useradd -r -s /sbin/nologin nginx
- /var/log/nginx/ 目录存在，且 nginx 用户有写权限：chown -R nginx:nginx /var/log/nginx
- /var/run/nginx.pid 所在目录（通常是 /var/run/）可被 nginx 用户写入；若使用 RuntimeDirectory=nginx，需确认 systemd 版本支持且未被覆盖
确认端口占用与 SELinux/AppArmor 干扰
执行 ss -tlnp | grep ':80\|:443' 检查 80/443 端口是否被其他进程（如另一个 nginx、httpd、docker 容器）占用。若有，停止冲突服务或修改 nginx 监听端口。
若系统启用了 SELinux（RHEL/CentOS/Fedora）或 AppArmor（Ubuntu/Debian），可能阻止 nginx 绑定端口或访问文件：
- SELinux：临时设为 permissive 模式测试：setenforce 0；若启动成功，说明策略限制，可用 ausearch -m avc -ts recent | audit2why 分析并生成策略
- AppArmor：检查 aa-status，查看 nginx 是否受限；临时禁用 profile 测试：sudo aa-disable /usr/sbin/nginx
不复杂但容易忽略。定位清楚是哪一环断开，修复就快了。
