指令与上下文

默认情况下，nginx 配置文件可以位于

配置文件的位置取决于 Nginx 的安装过程。

此文件包含以下内容

指令

Nginx 中的配置选项称为指令。此选项具有名称和参数，并且必须以分号 (;) 结尾，否则 Nginx 将无法加载配置并产生错误。

示例

背景

当我们在文本编辑器中打开核心 Nginx 配置文件时，我们会注意到的第一件事是配置以树状结构组织，并用大括号 "{}" 包围。这些被大括号包围的位置称为放置配置指令的上下文。此外，配置指令及其参数以分号结尾。

这是我们可以声明指令的部分。它类似于编程语言中的作用域。

上下文可以嵌套在其他上下文中，从而创建上下文层次结构。

示例

以 # 开头的行是注释，Nginx 不会解析它们。

指令类型

由于不同指令的继承模型不同，因此在使用同一指令在多个上下文中时需要特别注意。指令共有三种类型，每种都有其继承模型。

正常

每个上下文只有一个值。并且我们只能在上下文中定义一次。子上下文可以覆盖父指令，但此覆盖仅在该给定子上下文中有效。

Array

在同一上下文中添加过多指令会增加值，而不是完全覆盖它们。在子上下文中定义指令将覆盖给定子上下文中父的所有值。

动作指令

动作是用于更改事物的指令。它们的继承行为将取决于模块。

例如：在 rewrite 指令的情况下，每个匹配的指令都将被执行。

如果我们尝试获取 /sample

• 执行了服务器重写，重写从 /sample 到 /foobar。
• 然后匹配到 /foobar 位置。
• 执行了第一个位置重写，从 /foobar 重写到 /foo。
• 执行了第二个位置重写，从 /foo 重写到 /bar。

让我们看看与 return 指令不同的行为

从上面的情况来看，200 状态码会立即返回。

上下文类型

让我们看一个示例。

从上面的例子可以看出，HTTP 上下文声明了 HTTP 协议的设置。虚拟主机设置在 server 上下文中声明，并且也包含在 http 上下文中。location 上下文用于存储 URL 设置，它们包含在 server 上下文中。

主上下文

最通用的上下文是主上下文。它也称为全局上下文。主上下文全局设置 Nginx 的设置，并且是唯一不包含在典型上下文块中且不被大括号包围的上下文。

主上下文位于核心 Nginx 配置文件 的开头。此上下文的指令不能被继承到任何其他上下文，因此也不能被覆盖。

主上下文用于配置影响整个应用程序基本细节的信息。在主上下文中配置的一些常见细节包括用于运行工作进程的用户和组、工作进程的总数以及用于保存主进程 ID 的文件。整个应用程序的默认错误文件可以在主上下文级别设置。

Events 上下文

events 上下文设置连接处理的全局选项。events 上下文包含在 main 上下文中。在 Nginx 配置中只能定义一个 events 上下文。

Nginx 使用基于事件的连接处理模型，因此此上下文中的指令决定了工作进程应如何处理连接。

HTTP 上下文

HTTP 上下文用于包含处理 HTTP 或 HTTPS 流量的指令。

HTTP 上下文是 events 上下文的同级，因此它们必须并列而不是嵌套。它们都是 main 上下文的子级。

较低的上下文处理请求，此级别的指令控制每个虚拟服务器的定义默认值。

Server 上下文

server 上下文在 http 上下文中声明。server 上下文用于定义 Nginx 虚拟主机设置。HTTP 上下文中可以有多个 server 上下文。server 上下文中的指令处理与特定域或 IP 地址相关的资源的请求。

此上下文中的指令可以覆盖 http 上下文中定义的许多指令，包括文档根目录、日志记录、压缩等。除了从 http 上下文中获取的指令外，我们还可以配置尝试响应请求的文件、发出重定向和重写，以及设置任意变量。

Location 上下文

Location 上下文定义了处理客户端请求的指令。当任何资源请求到达 Nginx 时，它将尝试将 URI（统一资源标识符）与其中一个 location 进行匹配并相应地进行处理。

可以在 server 块中定义多个 location 上下文。此外，一个 location 上下文也可以嵌套在另一个 location 上下文中。

Upstream 上下文

upstream 上下文用于配置和定义上游服务器。此上下文允许定义 Nginx 可以代理请求的后端服务器池。通常，我们在此配置各种类型的代理。

Upstream 上下文使 Nginx 在代理请求时能够执行负载均衡。此上下文定义在 HTTP 上下文中，并且不在任何 server 上下文之外。

upstream 上下文在 server 或 location 块中通过名称引用。然后将特定类型的请求传递给定义的服务器池。然后，upstream 将使用算法（默认为轮询）来确定使用哪个特定服务器来处理请求。

Mail 上下文

虽然 Nginx 最常用作 Web 或反向代理服务器，但它也可以用作高性能的邮件代理服务器。用于此类指令的上下文称为mail 上下文。mail 上下文定义在 main 或 global 上下文中，或者在 http 上下文之外。

mail 上下文的主要目的是为服务器上的邮件代理解决方案提供一个配置区域。Nginx 可以将身份验证请求重定向到外部身份验证服务器。然后，它可以提供对 POP3、SMTP 和 IMAP 邮件服务器的访问，用于提供实际的邮件数据。

通常，mail 上下文看起来像这样

If 上下文

if 上下文用于允许条件性地执行其中定义的指令。If 上下文就像任何其他编程语言的“if 语句”。如果给定条件返回 true，if 上下文将执行包含的指令。

应尽可能避免使用 if 上下文，因为它存在一些限制。使用此链接了解更多关于为什么应该避免 nginx 的信息，讨论在此 处。

Limit_except 上下文

limit_except 上下文用于阻止在 location 上下文中 all HTTP 方法的使用，除非我们明确允许的那些。例如，如果某些客户端应该能够访问 POST 内容，而所有人都应该能够读取内容，那么我们可以为此使用 limit_except 上下文。

上面的示例允许所有访问者在 location /wp-admin 中使用 GET 方法。如果其他 HTTP 方法源自本地地址，则允许使用。

其他上下文

除了上述上下文之外，Nginx 还有一些其他可用的上下文，如下所述。这些上下文依赖于可选模块，并且很少使用。

• split_clients： split_client 上下文将客户端的请求分成两类或更多类别。此上下文定义在 HTTP 上下文中，主要用于 A/B 测试。
• geo： geo 上下文对客户端 IP 地址进行分类。它用于根据连接的 IP 地址映射变量的值。
• charset_map： 此上下文用于将特定的字符集添加到“Content-Type”响应头字段。此外，使用此上下文，您可以在一定限制下将数据从一种字符集转换为另一种字符集。
• map： map 上下文用于创建其值取决于其他变量值且定义在 http 上下文中的变量。
• perl/perl_set： 它用于在 Perl 中实现 location 和变量处理程序，并将 Perl 调用插入 SSI。此外，借助 perl_set 上下文，我们可以为特定变量安装 Perl 处理程序。
• types： types 上下文将 MIME 类型与正确的文件扩展名进行映射。此上下文可以出现在 http 上下文、server 上下文或 location 上下文中。