Linux 系统上的 Nginx 服务器，又或者 Apache HTTP 服务器，它们的主进程（Master Process）都是作为 root 身份运行的，但是它们会根据配置文件的设定，在非特权帐户下，启动工作进程（Worker Process），一般情况下，这样做并没有太大的问题，但是有同学可能想要让主进程运行在普通权限的帐户，这要怎么做呢？
或许有的同学会说，直接在普通权限的帐户下启动 Nginx 服务器不就好了吗？哈哈，这样做是可以的，不过，它不能监听标准的 HTTPS 端口，也就是 443 端口，这是因为 1024 以下的都是“特权端口”，只有“特权用户”（root）才可以使用，这样设计的目的是防止普通用户占用系统的重要端口。这样，我们就没有办法既使用普通帐户又使用特权端口了吗？不是的。
让我们兴奋的消息是，从 Linux 2.2 内核开始，系统支持了一种叫做 Capabilities 的功能，它可以将特权分为不同单元，我们可以只给程序授予有限度的特权，其中包括了特权端口的使用。我们要如何使用呢？
请键入这条指令：
setcap CAP_NET_BIND_SERVICE=+eip /usr/local/nginx/sbin/nginx
上面的指令中，只需要把 /usr/local/nginx/sbin/nginx 修改为你的 Nginx 可执行文件的完整路径即可。
最后，你开始这么做了，保护了服务器系统的安全，是不是一点问题都不存在呢？不是的，下面列举出一些你可能需要考虑的问题：
1. Nginx 运行时用到的所有文件，都必须能够被用来运行 Nginx 的帐户读取，日志文件与临时文件还要能够读写，要找出这些文件并设定正确的权限或许不是一件容易的事情。
2. Nginx 的日志文件现在可以被恶意删除，因为已经不能再用权限来保护它免受恶意的 PHP 脚本修改了，对于这个问题，可以考虑将 Nginx 的日志发送到 syslog 服务器。
3. 网站的 HTTPS 证书的私钥从此变得不再安全，现在，你的网站与 Nginx 运行在同样的帐户，如果禁止 Nginx 读取私钥，它无法提供 HTTPS 服务。要解决这个问题，可以运行一个单独的 Nginx 实力，它作为前端服务器，然后再运行其它的实力，作为后端服务器。前端服务器可以读取重要的 https 证书的私钥文件（这些证书直接用于服务器与客户端的通讯），前端服务器作为后端服务器的反向代理服务器，但不与后端服务器共享相同的系统权限。创建一个自签名证书，用于后端服务器与前端服务器通讯，即便秘钥泄露，也不至于造成很严重的后果。但是这样做，理论上会消耗比单个实力多一倍的系统性能。你也可以让前端服务器与后端服务器之间通讯时，使用开销更少的 http 协议，这样做或许会引来一些兼容问题。