Nginx Master进程不真正降权，而是保留root权限完成绑定80/443端口、读取600权限私钥、调用setuid/setgid三件事；Worker进程通过全局块顶部的user指令（如user www-data）降权运行，配合setcap授予CAP_NET_BIND_SERVICE能力可进一步收紧Master权限。
Nginx 的 Master 进程本身不真正降级权限，而是保留必要特权完成关键初始化后，将实际请求处理工作交由降权的 Worker 进程承担。所谓“权限降级”，本质是权限分离与最小化——Master 保持 root 身份做它必须做的事，Worker 则严格以低权限运行。
Master 必须保留 root 权限的三件事
这些操作在 Linux 内核层面要求 CAP_NET_BIND_SERVICE、读取受保护文件或切换用户身份，普通用户无法完成：
- 绑定 80、443 等小于 1024 的特权端口
- 读取私钥文件（如 /etc/ssl/private/example.key，通常权限为 600，仅 root 可读）
- 调用 setuid()/setgid() 创建并管控 Worker 进程
真正的降权发生在 Worker 进程启动时
靠的是 user 指令，且必须写在 nginx.conf 的全局块顶部（events 块之前）：
- user www-data;（Debian/Ubuntu）或 user nginx nginx;（RHEL/CentOS）
- Master 启动后解析该指令，fork 出 Worker 进程前，主动调用系统调用切换 UID/GID
- 未配置 user 指令时，Worker 会继承 Master 的 root 权限，这是严重安全隐患
进一步收紧 Master 自身能力（可选但推荐）
若希望 Master 不以完整 root 身份运行，可借助 Linux capabilities 剥离冗余权限：
- 执行 sudo setcap 'cap_net_bind_service=+ep' /usr/sbin/nginx，使 Nginx 仅保有绑定端口能力
- 配合 systemd 启动时设置 AmbientCapabilities=CAP_NET_BIND_SERVICE 和 NoNewPrivileges=yes
- 此时 Master 可以非 root 用户启动（如 User=nginx），但仍需 user 指令确保 Worker 进程身份正确
配套措施决定降权是否真正生效
光有 user 指令不够，还需验证和加固：
- 用 ps aux | grep nginx 查看：应有一行 root 开头的 master process，其余多行为指定用户（如 www-data）开头的 worker process
- SSL 私钥文件权限必须为 600，属主 root；网站根目录建议 755（属主 root，属组为 Worker 用户）；日志目录设为 750，属主 root:worker_group
- systemd 启动时启用 ProtectSystem=strict 和 RestrictSUIDSGID=yes，防止权限绕过
