如何在虚拟专用服务器上配置Nginx Web服务器

Nginx是一个Web服务器和反向代理服务器。本指南将检查一些Nginx的默认配置文件,以便更好地了解服务器的工作原理。

什么是Nginx?

Nginx是一个Web服务器和反向代理服务器。 它经历了广泛的采用,并取代了许多其他共同的选择。

虽然Nginx是一个强大的工具,其配置可能会吓到那些来自其他服务器,或一般是新的Web服务器。 在本指南中,我们将探讨主要的Nginx配置文件和去神秘化一些语法和选项。

我们将使用Ubuntu 12.04安装,但大多数发行版将配置类似的文件位置。

Nginx配置目录层次

Nginx将其配置文件存储在“/ etc / nginx”目录中。

在此目录中,您将找到几个目录和各种模块化配置文件:

cd /etc/nginx
ls -F
conf.d/         koi-win           naxsi.rules   scgi_params       uwsgi_params
fastcgi_params  mime.types        nginx.conf    sites-available/  win-utf
koi-utf         naxsi_core.rules  proxy_params  sites-enabled/

如果你是来自Apache,“网站可用”和“网站启用”目录将是熟悉的。

这些目录用于定义您的网站的配置。 文件通常在“sites-available”目录中创建,然后在准备就绪时可以符号链接到“sites-enabled”目录。

“conf.d”目录也可用于站点配置。 当Nginx启动时,该目录中以“.conf”结尾的每个文件都被读入配置,因此请确保每个文件定义有效的Nginx配置语法。

“/ etc / nginx”目录中的大多数其他文件包含特定进程或可选组件的配置详细信息。

但是,“nginx.conf”文件是主配置文件。 我们将更深入地探索这个文件。

探索nginx.conf文件

nginx.conf文件是Nginx的主控制点。 此文件读取所有其他相应的配置文件,并在服务器启动时将它们组合成一个单片配置文件。

打开文件,以便我们可以讨论一般格式:

sudo nano /etc/nginx/nginx.conf
user www-data;
worker_processes 4;
pid /var/run/nginx.pid;

events {
        worker_connections 768;
        # multi_accept on;
}

http {
. . .

前几行用于定义关于Nginx将如何操作的一些一般事实。

例如,服务器决定什么用户通过“user www-data”行运行。 这是Ubuntu的典型Web服务器用户。

“pid”指令指定进程pid将存储为内部引用的位置。 “worker_processes”定义Nginx将使用多少并发进程。

配置文件的这一部分还可以使用“error_log”指令包括错误日志位置等内容。

我们文件中的下一部分是事件部分。 这是一个特殊的位置,控制Nginx如何处理连接。 在我们的示例中,我们不需要在此部分中进行任何调整,因此我们将继续。

以下部分是http块。 这导致更复杂的讨论关于如何格式化Nginx配置文件。

Nginx配置文件布局

Nginx配置文件在“块”中管理。

我们看到的第一个块是事件块。 下一个是http块,以及配置文件中的主层次结构的开始。

http块中的配置细节是分层的,其中封闭的块从它们所在的块继承属性。大多数Nginx的一般配置发生在http块中,该块包含服务器块,服务器块又包含位置块。

重要的是,您应该始终将配置详细信息放置到它们应用的最高容器中。 这意味着如果您希望参数X应用于每个服务器块,则将其放置在http块中将导致它传播到每个服务器配置。

如果你看看我们的文件,你会注意到它有许多选项,决定软件应该作为一个整体。 这是这些类型的指令的适当位置。

例如,我们使用这些行设置文件压缩选项:

gzip on;
gzip_disable "msie6";

这告诉Nginx启用gzip来压缩发送到客户端的数据,但是当客户端是Internet Explorer V6时禁用gzip压缩,因为该浏览器不理解gzip压缩。

如果某些服务器块的选项应该具有不同的值,那么可以在更高级别指定它们,然后在服务器块中覆盖它们。 Nginx将采用适用于设置的最低级别规范。

这种在尽可能高的级别应用设置的方式使您不必管理多个相同的声明。 它还具有提供默认值的优点,可以在您忘记在“服务器”块级别或更低级别上声明某些内容时使用。

在“nginx.conf”文件中,我们可以看到“http”块的结尾有:

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

这告诉我们,定义特定网站和网址匹配位置的服务器和位置块将在此文件之外发生。

这允许我们维护一个模块化的配置安排,当我们想要服务新的网站时,我们可以创建新的文件。 它允许我们将相关内容组合在一起,而隐藏在大多数情况下不会改变的细节。

退出“nginx.conf”文件,以便我们可以在下一部分中检查单个站点配置。

探索默认服务器块

Nginx使用服务器块来完成Apache的虚拟主机中的功能。 将服务器块视为服务器可以托管的各个网站的规范。

我们将看看包含在“sites-available”目录中的默认服务器块配置。 此文件包含服务默认网页所需的所有必要信息。

cd sites-available
sudo nano default
server {
	root /usr/share/nginx/www;
	index index.html index.htm;

	server_name localhost;

	location / {
		try_files $uri $uri/ /index.html;
	}

	location /doc/ {
		alias /usr/share/doc/;
		autoindex on;
		allow 127.0.0.1;
		deny all;
	}
}

默认文件是非常好的评论,但我已经删除了这里的意见,以节省空间,并演示如何简单的网站的定义可以。

我们有一个服务器块,其中包括开头和相关的闭括号之间的所有内容:

server {
	. . .
}

通过使用“include”指令,这个块被放置在http块末尾附近的“nginx.conf”文件中,我们在上一节中讨论过。

“root”指令定义网站内容所在的目录。 这是Nginx将开始查找浏览器请求的文件的位置。 默认网站在“/ usr / share / nginx / www”中搜索其内容。

注意每行以分号(;)结尾。 这是Nginx知道一个指令完成,下一个指令将开始。 不要忘记分号,否则Nginx会将后面的行作为指令的附加参数。 它会这样做,直到它达到一个分号。

下一行涉及“index”指令。

这将配置为域提供的默认页面。 如果没有请求页面,服务器块将搜索一个名为“index.html”的文件并返回。 如果它找不到该文件,它将尝试提供一个名为“index.htm”的文件。

使用server_name指令

“server_name”指令包含将从此服务器块提供的域名列表。 您可以包含尽可能多的名称,用空格分隔。

您还可以在服务器名称的开头或结尾使用星号字符作为匹配一切的通配符。 例如,“* .example.com”会匹配“forum.example.com”和“animals.example.com”的请求。

如果请求的URL匹配多个“server_name”指令,它将选择与第一个匹配的那个。 如果没有完全匹配,它将选择以星号开头的最长通配符名称。

如果它仍然没有找到匹配,它将查找以星号结尾的最长匹配通配符名称。 如果没有找到,它将返回第一个匹配的正则表达式匹配。

使用正则表达式匹配的服务器名称以波浪号(〜)字符开头。 正则表达式非常强大,但超出了本文的范围。

使用位置块

配置文件的下一部分打开位置块。 位置块用于指定在服务器中如何处理某些资源请求。

行“location /”指定括号内的指令将应用于客户端请求的不匹配其他位置块的所有资源。

位置块可以包含一个uri路径,如文件中进一步指定的“/ doc /”路径,可以在位置和uri之间使用等号(=)来指定完全匹配,或使用波形(〜)字符指示正则表达式匹配。

平假号表示区分大小写匹配,波浪号后跟星号(〜*)表示不区分大小写的匹配,波浪号前面加上一个克拉(^〜)表示如果uri匹配此位置,Nginx不执行正则表达式搜索。

位置匹配与server_name匹配类似,因为Nginx有一个明确定义的进程来决定使用哪个块。

如果查询匹配具有等号的位置,则使用该位置,并停止搜索。 如果不是,则搜索常规文字uri位置。 如果使用克拉角(^〜),并且uri位置匹配,则将选择此块。

如果不使用该选项,它将选择最具体的匹配并保持该值。 然后它将执行正则表达式匹配,以查看它是否可以匹配任何这些模式。 如果找到,则使用正则表达式块。 如果不是,则使用先前匹配的uri位置。

总之,Nginx更喜欢精确匹配,接着是正则表达式匹配,然后是文字URI匹配,但是字面URI匹配可以通过在前面使用“^〜”来显式地更重要。

此列表定义了以下首选项:

  1. 等号匹配
  2. 文字URI与“^〜”匹配
  3. 最具体的正则表达式匹配
  4. 最具体的文字URI匹配

虽然这可能看起来很混乱,但是这些定义的规则是必要的,因此Nginx可以做出不含糊的决定。

如何使用try_files

try_files指令是一个非常有用的工具,用于定义应该对资源请求进行的尝试链。

这意味着你可以声明你将如何希望Nginx尝试通过一系列替代选项来提供请求。

默认配置文件中的示例为:

try_files $uri $uri/ /index.html;

这意味着当请求由该位置块提供服务时,Nginx将首先尝试将文本uri作为文件提供。 这是使用“$ uri”变量声明的,它将保存正在请求的资源。

如果没有文件匹配$ uri的值,那么它将尝试使用uri作为目录。 它将尝试为uri目录提供默认文件(我们的是index.html,如果你记得)。

如果没有与$ uri值匹配的目录,则它使用默认文件,它是服务器块根目录中的“index.html”文件。 每个“try_files”指令使用最后一个参数作为后退默认值,因此它必须是已知的真实文件。

另一个选项如果不希望返回一个文件,如果前面的参数不匹配是返回一个错误页面。 这是使用等号和错误代码。

例如,如果我们希望我们的“location /”块返回404错误,如果无法找到资源,而不是提供默认的“index.html”页面,我们可以替换最后一个文件为“= 404”:

try_files $uri $uri/ =404;

如果他们请求一个不存在的资源,这将抛出相应的错误页面给用户。

附加选项

配置文件的其余部分包含一些其他有趣的指令。

“alias”指令告诉Nginx该位置块的页面应该在指定的目录之外。 这些可以在根目录之外。

在我们的示例中,“/ doc /”中请求的资源将在“/ usr / share / doc /”之外。

“autoindex on”指令允许Nginx为指定的位置生成目录列表。 当请求目录时将返回。

“allow”和“deny”行为目录设置访问控制。 当用户尝试从本地服务器访问该位置时,文件中的行允许读取内容。

结论

Nginx对其某些功能使用不同的术语,但是它是一个具有许多配置选项的极具功能的服务器。

学习如何正确配置Nginx Web服务器将允许您充分利用同时非常强大和资源非常低的一块软件。 这使它成为任何大小网站的理想选择。

作者:Justin Ellingwood