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 块之前）：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 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，防止权限绕过