nginx_ensite *文件夹由nginx_ensite和nginx_dissitepipe理。 对于通过search查find的Apache httpd用户，等价物是a2ensite / a2dissite 。

sites-available文件夹用于存储所有的虚拟主机configuration，不pipe它们是否当前启用。

已sites-enabled文件夹包含站点可用文件夹中的文件的符号链接。 这使您可以通过删除符号链接select性地禁用虚拟主机。

conf.d完成了这项工作，但是当你需要禁用某些东西的时候，你必须将某些东西移出文件夹，删除它，或者修改它。 sites- *文件夹抽象使事情更有条理，并允许您使用单独的支持脚本来pipe理它们。

（除非你像我一样，许多debianpipe理员直接pipe理符号链接，不知道脚本…）

我想补充以前的答案，最重要的不是你如何调用目录（虽然这是一个非常有用的约定），但你实际上放在nginx.conf 。 configuration示例：

 http { include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*.conf; include /etc/nginx/sites-enabled/my_own_conf; ... } 

这里使用的唯一指令是include ，所以在conf.d/和sites-enabled/之间没有内部的区别。

从上面的文档：

 Syntax: include file | mask; Default: — Context: any Includes another file, or files matching the specified mask, into configuration. Included files should consist of syntactically correct directives and blocks. 

所以，要回答原来的问题：没有内在的差异，你可以用最好的方式使用它们，记住其他答案的build议。 而且，请不要忘记select“正确”的答案。

通常， sites-enabled文件夹用于虚拟主机定义，而conf.d用于全局服务器configuration。 如果您支持多个网站（即虚拟主机），则每个网站都有自己的文件，因此您可以通过将文件移入或移出sites-enabled （或创build和删除符号链接，这可能是一个更好的主意）。

将conf.d用于诸如模块加载，日志文件以及其他非特定于单个虚拟主机的事情。

默认configuration引用了www-data用户？ 我是否必须创build该用户？

你应该让nginx以非root用户的身份运行。 这在某些情况下被命名为www-data ，但是您可以将其命名为任何您想要的名称。

如何给这个用户运行nginx的最佳权限？

我不太确定这个问题的答案（我目前没有运行nginx），但是如果它是类似Apache的答案，那么www-data用户只需要读取任何静态文件的权限（并且读取+在目录上执行），或者读取/执行像CGI脚本这样的权限，而在其他任何地方都没有权限。

这是怎么回事？

您必须使用Debian或Ubuntu，因为来自http://nginx.org/packages/ 的nginx的上游封装没有使用邪恶 sites-available / sites-enabled逻辑。

无论哪种情况，都可以通过/etc/nginx/nginx.conf中的标准include指令作为configuration约定来实现。

下面是一个来自/etc/nginx/nginx.conf的官方上游nginx包的/etc/nginx/nginx.conf的代码片段：

 http { … include /etc/nginx/conf.d/*.conf; } 

这里是Debian / Ubuntu中的/etc/nginx/nginx.conf的一段代码：

 http { … include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; } 

所以，从NGINX的angular度来看，唯一的区别就是conf.d文件得到了更快的处理，因此，如果你的configuration默默地相互冲突，那么来自conf.d优先于那些在sites-enabled 。

最佳实践是conf.d

你应该使用/etc/nginx/conf.d ，因为这是一个标准的约定，应该在任何地方工作。

如果您需要禁用某个站点，只需将文件名重新命名为不再具有.conf后缀，这非常简单，直接且防错：

sudo mv -i /etc/nginx/conf.d/default.conf{,.off}

或者相反， 启用一个网站：

sudo mv -i /etc/nginx/conf.d/example.com.conf{.disabled,}

不惜一切代价避免sites-available和sites-enabled 。

我看到绝对没有理由使用sites-available / sites-enabled ：

• 有些人提到了nginx_ensite和nginx_dissite脚本 – 这些脚本的名字甚至比这个崩溃的其他部分还要糟糕 – 但是这些脚本也没有find – 即使在Debian中它们也不在nginx包中（可能在Ubuntu中），而不是在他们自己的包中，另外，你真的需要一个完整的非标准的第三方脚本来简单地移动和/或链接两个目录之间的文件？！

• 如果你不使用这些脚本（事实上，这是一个明智的select），那么你将如何pipe理站点：

  • 你是否从sites-available创build符号链接sites-available用于sites-enabled ？
  • 复制文件？
  • 移动文件？
  • 在sites-enabled位置编辑文件？

上述看起来像是一些小问题需要解决，直到几个人开始pipe理系统，或者直到你做出一个快速的决定，只是忘记了几个月或几年的时间…

这使我们能够：

• 从sites-enabled的文件中删除文件是否安全？ 它是软链接吗？ 一个硬链接？ 还是唯一的configuration副本？ configuration地狱的一个主要例子。

• 哪些网站已被禁用？ （使用conf.d ，只需要反向search不以.conf结尾的文件 – find /etc/nginx/conf.d -not -name "*.conf" ，或者使用grep -v 。）

不仅如此，还要注意Debian / Ubuntu使用的具体include指令 – /etc/nginx/sites-enabled/* – 与conf.d不同，没有为sites-enabled指定文件名后缀。

• 这意味着如果有一天你决定在/etc/nginx/sites-enabled快速编辑一个或两个文件，并且你的emacs创build了一个类似于emacs的备份文件，那么你突然间就会同时拥有default和default~作为主动configuration，根据使用的指令，可能甚至不会给你任何警告，并导致长时间的debugging会话发生。 （是的，它确实发生在我身上，那是在一次黑客马拉松比赛中，我完全不明白为什么我的conf没有工作。）

因此，我确信sites-enabled是纯粹的邪恶！