nginx worker进程必须以非特权用户运行，主进程由root启动但worker需通过user指令降权（如user nginx nginx;），并配合最小权限文件系统设置、selinux/apparmor策略及严格路径权限控制，确保安全纵深防御。
Nginx 启动时默认以 非特权用户 运行，这是其安全设计的关键一环。直接使用 root 运行 Nginx 会极大增加系统被攻击后提权的风险。正确配置 user 和 group 指令，能有效限制 worker 进程的文件系统与网络访问权限，是生产环境必须落实的基础安全措施。
明确区分主进程与工作进程的运行身份
Nginx 主进程（master process）始终由 root 启动（仅在绑定 1–1023 端口或加载某些模块时需要），但所有实际处理请求的 worker 进程应降权运行。通过 user 指令指定 worker 进程的 UID/GID，例如：
-
user www-data www-data;（Debian/Ubuntu 默认） -
user nginx nginx;（CentOS/RHEL 默认） - 避免写成
user root root;或留空（此时部分发行版会回退为 nobody，但行为不可靠）
确保用户和组真实存在且权限最小化
配置前需确认系统中已创建专用用户与组，不复用其他服务账户（如 apache、mysql）。建议操作步骤：
- 创建独立用户：
useradd -r -s /sbin/nologin -d /var/www nginx - 仅赋予对必要目录的读取权限（如静态资源目录）、对日志目录的写入权限（
/var/log/nginx） - 禁止该用户登录、禁止 shell 访问、不分配家目录
- 检查 Nginx 配置文件、SSL 证书等敏感路径是否被该用户意外可读（如私钥文件权限应为
600，属主为 root）
配合文件系统权限与 SELinux/AppArmor 使用
仅靠 user 指令不够，需协同操作系统级权限控制：
- Web 根目录（如
/var/www/html）应设置为755，属主为 root，属组可设为nginx，并启用setgid保证新文件继承组；静态资源文件设为644，脚本类（如 CGI）严格限制执行权限 - 若启用 SELinux（RHEL/CentOS），确认 Nginx 进程运行在
httpd_t域，并允许其访问自定义路径（用semanage fcontext和restorecon） - AppArmor（Ubuntu）需更新 profile，显式声明允许读取的路径和网络能力
验证配置生效并持续监控异常行为
修改后务必验证实际运行身份是否符合预期：
- 重启 Nginx：
nginx -t && systemctl reload nginx - 检查进程 UID：
ps aux | grep nginx | grep -v grep，确认 worker 进程显示为指定用户（如 nginx），而非 root - 测试静态文件访问、PHP-FPM 通信、日志写入是否正常；若报
Permission denied，优先检查路径权限和 selinux 上下文，而非降权回 root - 将
user配置纳入配置管理（Ansible/Terraform）和上线检查清单，防止人工误改
不复杂但容易忽略——一个正确的 user/group 设置，是 Nginx 安全纵深防御的第一道门。
