可用站点与启用站点与conf.d目录（Nginx）的区别？

#1 楼

sites- *文件夹由nginx_ensite和nginx_dissite管理。对于通过搜索找到该目录的Apache httpd用户，等效项是a2ensite / a2dissite。

sites-available文件夹用于存储所有vhost配置，无论它们当前是否已启用。

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

conf.d可以完成此工作，但是当您需要禁用某些内容时，您必须将其移出文件夹，删除它或对其进行更改。 。 sites- *文件夹抽象使事情变得井井有条，并允许您使用单独的支持脚本进行管理。

（除非您像我一样，并且是许多仅管理符号链接的debian管理员之一）直接，不知道脚本...）

#2 楼

我想在前面的答案中补充一点，最重要的不是您如何调用目录（尽管这是非常有用的约定），而是您实际在nginx.conf中输入的内容。配置示例：

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.

因此，要回答原始问题：没有内部差异，您可能会以最佳方式使用它们，记住其他答案的建议。而且，请不要忘记选择“正确”的答案。

#3 楼

通常，sites-enabled文件夹用于虚拟主机定义，而conf.d用于全局服务器配置。如果您支持多个网站（即虚拟主机），则每个网站都有自己的文件，因此您可以通过将文件移入和移出sites-enabled（或创建和删除符号链接）来轻松启用和禁用它们。可能是一个更好的主意。默认配置引用www数据用户？我必须
创建该用户吗？


您应该让nginx以非root用户身份运行。在某些情况下，其名称为conf.d，但您可以根据需要命名。


如何为该用户授予运行nginx的最佳权限？


我不太确定答案问题（目前我不在运行nginx），但是如果它类似于Apache，则答案是www-data用户只需要对您正在服务的任何静态文件（以及目录中的read + execute）具有读权限，或者/ execute权限（例如CGI脚本），而其他任何地方都没有权限。

#4 楼

您必须使用Debian或Ubuntu，因为来自http://nginx.org/packages/的nginx上游包装没有使用邪恶的sites-available / sites-enabled逻辑。 />
在这两种情况下，都可以通过include中的标准/etc/nginx/nginx.conf指令将它们作为配置约定来实现。

这是来自nginx的nginx官方上游软件包的/etc/nginx/nginx.conf的摘要.org：

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的角度来看，唯一的不同是conf.d中的文件将得到更快的处理，因此，如果您的配置相互之间无声冲突，则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脚本-这些脚本的名称甚至比其余的崩溃更糟-但这些脚本也无处可寻-他们即使在Debian（甚至可能在Ubuntu）中，nginx软件包中也不存在，并且也不存在于它们自己的软件包中，此外，您是否真的需要一个完整的非标准第三方脚本来简单地移动和//或链接两个目录之间的文件？！

而且，如果您不使用脚本（实际上，这是上面的明智选择），那么就会出现如何管理站点的问题：


您创建了从sites-available到sites-enabled的符号链接？
复制文件？
移动文件？
在sites-enabled中编辑文件吗？



以上内容似乎是要解决的一些小问题，直到有几个人开始管理该系统，或者直到您做出快速决定，才将其忘却几个月或几年……

这使我们想到：


从sites-enabled删除文件是否安全？它是软链接吗？硬链接？还是配置的唯一副本？配置地狱的一个典型例子。
哪些站点已被禁用？ （使用conf.d时，只需对不以.conf结尾的文件进行反向搜索-find /etc/nginx/conf.d -not -name "*.conf"或使用grep -v即可。）

不仅要以上所有，还要注意Debian / Ubuntu使用的特定include指令— /etc/nginx/sites-enabled/* —与sites-enabled不同，没有为conf.d指定文件名后缀。


这意味着，如果有一天您决定快速编辑/etc/nginx/sites-enabled中的一两个文件，而您的emacs创建一个类似default~的备份文件，然后突然将default和default~都包含为活动配置，根据所使用的指令，它们甚至可能不会给您任何警告，并且会导致长时间的调试会话。 （是的，这确实发生在我身上；那是在一次黑客马拉松期间，我完全困惑为什么我的conf无法正常工作。）

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