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

状态： 已弃用

本文介绍了不再受支持的 Ubuntu 版本。 如果您当前正在运行运行 Ubuntu 12.04 的服务器，我们强烈建议您升级或迁移到受支持的 Ubuntu 版本：

• 升级到 Ubuntu 14.04。
• 从 Ubuntu 14.04 升级到 Ubuntu 16.04
• 将服务器数据迁移到支持的版本

原因： Ubuntu 12.04 已于 2017 年 4 月 28 日终止生命周期 (EOL) and no longer receives security patches or updates. This guide is no longer maintained.

请参阅：
本指南可能仍可用作参考，但可能不适用于其他 Ubuntu 版本。 如果可用，我们强烈建议使用为您正在使用的 Ubuntu 版本编写的指南。 您可以使用页面顶部的搜索功能来查找更新的版本。

什么是 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”目录会很熟悉。

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

“conf.d”目录也可用于站点配置。 该目录中以“.conf”结尾的每个文件都会在 Nginx 启动时读入配置，因此请确保每个文件都定义了有效的 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 版本 6 时禁用 gzip 压缩，因为该浏览器不支持 gzip 压缩。

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

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

在“nginx.conf”文件中，我们可以看到“http”块的末尾有：

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

这告诉我们，定义特定站点和 url 匹配位置的服务器和位置块将发生在该文件之外。

这使我们能够维护模块化配置安排，当我们想为新站点提供服务时，我们可以在其中创建新文件。 它允许我们将相关内容组合在一起，同时隐藏在大多数情况下不会改变的细节。

退出“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 之间使用等号 (=) 以指定完全匹配，或使用波浪号 (~) 字符表示常规表达式匹配。

一个普通的波浪号表示区分大小写的匹配，一个波浪号后跟一个星号 (~*) 表示不区分大小写，一个波浪号前面有一个克拉 (^~) 告诉 Nginx 如果 uri 匹配这个位置，则不执行正则表达式搜索。

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

如果查询与带有等号的位置匹配，则使用该位置并停止搜索。 如果不是，则搜索常规文字 uri 位置。 如果使用了克拉波浪号 (^~) 并且 uri 位置匹配，则将选择此块。

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

总之，Nginx 更喜欢精确匹配，然后是正则表达式匹配，然后是文字 URI 匹配，但文字 URI 匹配可以通过在它们前面加上“^~”来显式地提高它们的重要性。

此列表定义了这些首选项：

<ol>
    <li>Equal sign matches</li>
    <li>Literal URI matches with "^~"</li>
    <li>Most specific regular expression match</li>
    <li>Most specific literal URI match</li>
</ol>

尽管这可能看起来令人困惑，但这些定义的规则是必要的，以便 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;

如果用户请求不存在的资源，这将向用户抛出相应的错误页面。

其他选项

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

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

在我们的示例中，“/doc/”中请求的资源将由“/usr/share/doc/”提供。

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

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

结论

Nginx 对其某些功能使用了不同的术语，但它是一个非常强大的服务器，具有许多配置选项。

学习如何正确配置 Nginx Web 服务器将使您能够充分利用一个同时功能非常强大且资源非常少的软件。 这使其成为任何规模网站的理想选择。

贾斯汀·艾林伍德