Nginx中的概念
Nginx指令
Nginx 中的配置选项称为指令。该选项有名称和参数，必须以分号 (😉 结尾，否则 Nginx 将无法加载配置并产生错误。
例子：
gzip on;
普通指令
每个上下文有一个值。我们只能在上下文中定义它一次。子上下文可以覆盖父指令，但此覆盖仅在给定的子上下文中有效。
gzip on; gzip off; # 在同一个上下文中有两个普通指令是非法的 server { location /downloads { gzip off; } location /assets { # gzip 在这里有效 } }
数组指令
在同一上下文中添加多条指令会增加值而不是完全覆盖它们。在子上下文中定义指令将覆盖给定子上下文中父级的所有值。
error_log /var/log/nginx/error.log; error_log /var/log/nginx/error_notive.log notice; error_log /var/log/nginx/error_debug.log debug; server { location /downloads { # 这将覆盖父级所有指令 error_log /var/log/nginx/error_downloads.log; } }
行动指令
动作是用于改变事物的指令。它们的继承行为将取决于模块。
**例如：**在 rewrite 指令的情况下，每个匹配的指令都会被执行。
server { rewrite ^ /foobar; location /foobar { rewrite ^ /foo; rewrite ^ /bar; } }
如果我们尝试访问**/sample**：
- 执行服务器重写，重写从 /sample 到 /foobar。
- 然后匹配位置 /foobar。
- location 里第一个重写被执行，从重写 /foobar 到 /foo。
- location 里第二个重写被执行，从重写 /foo 到 /bar。
让我们看看return指令提供的不同行为：
server { location / { return 200; return 404; } }
从上面的情况来看，200 状态立即返回。
root, location 和 try_files 指令
root指令
root 指令用于设置请求的根目录，允许 nginx 将传入的请求映射到文件系统。
server { listen 80; server_name cainiaojc.com; root /var/www/cainiaojc.com; }
它允许nginx根据请求返回服务器内容：
cainiaojc.com/index.html # returns /var/www/cainiaojc.com/index.html cainiaojc.com/foo/index.html # returns /var/www/cainiaojc.com/foo/index.html
Location指令（介绍）
location 指令用于根据请求的 URI（统一资源标识符）设置配置。
语法是：
location [modifier] path
例子：
location /foo { # ... }
当没有给出修饰符时，路径被视为前缀，之后可以跟任何东西。上面的例子将匹配：
/foo /fooo /foo123 /foo/bar/index.html ...
我们还可以在给定的上下文中使用多个位置指令：
server { listen 80; server_name cainiaojc.com; root /var/www/cainiaojc.com; location / { return 200 "root"; } location /foo { return 200 "foo"; } } cainiaojc.com/ # => "root" cainiaojc.com/foo # => "foo" cainiaojc.com/foo123 # => "foo" cainiaojc.com/bar # => "root"
Nginx 还提供了一些可以与location指令结合使用的修饰符。
try_files 指令（避免使用）
该指令尝试不同的路径，并将返回找到的任何一个。
try_files $uri index.html =404;
所以 /foo.html 将尝试按以下顺序返回文件：
- $uri (/foo.html);
- index.html
- If none is found:404
如果我们在服务器上下文中定义 try_files，然后定义一个查找所有请求的blocation，我们的 try_files 将不会被执行。发生这种情况是因为服务器上下文中的 try_files 定义了伪 location，这是可能的最不具体的 location。因此，定义 location / 将比伪 location 更具体。
Nginx上下文
当我们在文本编辑器中打开核心 Nginx 配置文件时，首先我们会注意到配置被组织成树状结构，并被花括号包围，即“{”和“}”。这些被大括号包围的位置称为放置配置指令的上下文。此外，配置指令及其参数以分号结尾。
这是我们可以声明指令的部分。它类似于编程语言中的作用域。
上下文可以嵌套在其他上下文中，从而创建上下文层次结构。
例子：
worker_processes 2; # 全局上下文中的指令 http { # http 上下文 gzip on; # http 上下文中的指令 server { # 服务器上下文 listen 80; # 服务器上下文中的指令 } }
用# 填充的行是注释，Nginx 不会解释。
让我们看一个例子。
# 全局上下文 ... ... # http 上下文 http{ ... ... # 服务器上下文 server { listen 80; server_name example.com; ... ... # Location 上下文 location / { root /var/www/html; try_files $uri $uri/ =404; ... ... } } # 服务器上下文 server { ... ... # Location 上下文 location / { ... ... } } ... ... }
从上面的例子中，我们可以看到 HTTP 上下文声明了 HTTP 协议的设置。虚拟主机设置在服务器上下文中声明，包含在 http 上下文中。用于存储 URL 设置的 location 上下文包含在服务器上下文中。
主要上下文
最一般的上下文是主上下文。它也称为全局上下文。主上下文全局设置 Nginx 的设置，并且是唯一未被花括号包围的上下文。
主上下文位于核心 Nginx 配置文件的开头。此上下文的指令不能在任何其他上下文中继承，因此不能被覆盖。
主上下文用于配置在基本级别上影响整个应用程序的详细信息。在主上下文中配置的一些常见详细信息是运行工作进程的用户和组、工作进程总数以及保存主进程 ID 的文件。可以在主上下文级别设置整个应用程序的默认错误文件。
user nginx; worker_processes auto; pid /run/nginx.pid; ... ...
事件上下文
事件上下文为连接处理设置全局选项。事件上下文包含在主上下文中。Nginx 配置中只能定义一个事件上下文。
Nginx 使用基于事件的连接处理模型，因此在此上下文中定义的指令决定了工作进程应如何处理连接。
# main context events { # events context worker_connections 768; multi_accept on; } ... ...
HTTP 上下文
HTTP 上下文用于保存处理 HTTP 或 HTTPS 流量的指令。
HTTP 上下文是事件上下文的兄弟，因此它们必须并排列出，而不是嵌套。他们都是主要上下文的孩子。
较低的上下文处理请求，此级别的指令控制每个虚拟服务器的定义默认值。
ser nginx; worker_processes auto; pid /run/nginx.pid; ... ... events { # events context worker_connections 768; multi_accept on; ... ... } http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; ... ... }
服务器上下文
服务器上下文在 http 上下文中声明。服务器上下文用于定义 Nginx 虚拟主机设置。HTTP 上下文中可以有多个服务器上下文。服务器上下文中的指令处理对与特定域名或 IP 地址关联的资源的请求的处理。
此上下文中的指令可以覆盖许多可能在 http 上下文中定义的指令，包括文档位置、日志记录、压缩等。 除了从 http 上下文中获取的指令之外，我们还可以配置文件以尝试响应请求、发出重定向和重写，并设置任意变量。
user nginx; worker_processes auto; pid /run/nginx.pid; ... ... events { # events context worker_connections 768; multi_accept on; ... ... } http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; ... ... server { listen 80; server_name domain1.com; root /var/www/html/wordpress; ... } server { listen 80; server_name domain2.com; root /var/www/html/drupal; ... } }
location上下文
location上下文定义指令来处理客户端的请求。当任何对资源的请求到达 Nginx 时，它会尝试将 URI（统一资源标识符）与其中一个location匹配并相应地处理它。
可以在服务器块内定义多个location上下文。此外，一个location上下文也可以嵌套在另一个location上下文中。
http { ... ... server { listen 80; server_name domain1.com; root /var/www/html/wordpress; ... location /some_url { # configuration for processing URIs starting with /some_url } location /another_url { # configuration for processing URIs starting with /another_url } } server { listen 80; server_name domain2.com; root /var/www/html/drupal; ... location /some_url { # configuration for processing URIs starting with /some_url } location /some_other_url { # configuration for processing URIs starting with /some_other_url } } }
upstream上下文
upstream 上下文用于配置和定义上游服务器。允许此上下文定义后端服务器池，Nginx 可以代理请求时使用的后端服务器。这个上下文通常是我们正在配置的各种类型的代理。
upstream 上下文使 Nginx 能够在代理请求的同时执行负载平衡。此上下文在 HTTP 上下文内部和任何服务器上下文外部定义。
upstream 上下文在服务器或 location 块中按名称引用。然后将某种类型的请求传递给定义好的服务器池。然后 upstream 将使用算法（默认为轮询）来确定需要使用哪个特定服务器来处理请求。
http{ ... ... upstream backend_servers { server host1.example.com; server host2.example.com; server host3.example.com; } server { listen 80; server_name example.com; location / { proxy_pass http://backend_servers; } } }
邮件上下文
尽管 Nginx 最常用作 Web 或反向代理服务器，但它也可以用作高性能邮件代理服务器。用于此类指令的上下文称为邮件上下文。邮件上下文定义在主上下文或全局上下文内或 http 上下文外。
邮件上下文的主要目的是为在服务器上配置邮件代理解决方案提供一个区域。Nginx 可以将身份验证请求重定向到外部身份验证服务器。然后，它可以提供对 POP3、SMTP 和 IMAP 邮件服务器的访问，以提供实际邮件数据。
通常，邮件上下文如下所示：
# main context mail { server_name mail.example.com; auth_http localhost:9000/cgi-bin/nginxauth.cgi; proxy_pass_error_message on; ... } http { } ... ...
if 上下文
if 上下文用于允许有条件地执行其中定义的指令。if 上下文就像任何其他编程语言的“if 语句”。如果给定条件返回 true，则 if 上下文将执行包含的指令。
由于某些限制，应尽可能避免使用 if 上下文。
http { server { location /some_url { if (test_condition) { # do some stuff here } } } }
limit_except 上下文
limit_except 上下文用于防止在 location 上下文中使用除我们明确允许的方法之外的所有 HTTP 方法。例如，如果某些客户端应该有权访问POST 内容并且每个人都应该有能力阅读内容，那么我们可以为此使用limit_except上下文。
... ... location /wp-admin/ { limit_except GET { allow 127.0.0.1; deny all; } } ... ...
杂项上下文
除了上述上下文之外，Nginx 中可用的上下文很少，如下所述。这些上下文依赖于可选模块并且很少使用。
- split_clients： split_client 上下文将客户端的请求拆分为两个或多个类别。该上下文定义在 HTTP 上下文中，主要用于 A/B 测试。
- geo： geo 上下文对客户端 IP 地址进行分类。它用于根据连接的 IP 地址映射变量的值。
- **charset_map：**此上下文用于将特定字符集添加到“Content-Type”响应头字段。此外，使用上下文，可以将数据从一个字符集转换为另一个字符集，但有一些限制。
- map： map上下文用于创建变量，其值依赖于其他变量的值，并在http上下文中定义。
- **perl/perl_set：**用于在 Perl 中实现位置和变量处理程序，并将 Perl 调用插入 SSI。此外，在 perl_set 上下文的帮助下，我们可以为特定变量安装 Perl 处理程序。
- **类型：**类型上下文用正确的文件扩展名映射 MIME 类型。此上下文可能出现在 http 上下文、服务器上下文或位置上下文中。
