无涯教程： Nginx - 指令与上下文

无涯教程网​​​​​​​：默认情况下，nginx配置文件可以位于:

/etc/nginx/nginx.conf,
/usr/local/etc/nginx/nginx.conf, or
/usr/local/nginx/conf/nginx.conf

配置文件的位置将根据Nginx的安装过程而有所不同。

该文件具有以下内容:

Directive

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

示例:

gzip on;

Context

当我们在文本编辑器中打开核心Nginx配置文件时，我们首先会注意到配置以树状结构组织，并用花括号包围，即" {"和"}"。这些用大括号括起来的位置称为 context ，用于放置配置指令。此外，配置指令及其参数以分号结尾。

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

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

示例:

worker_processes 2; # directive in the global context
http {              # http context
    gzip on;        # directive in http context

  server {          # server context
    listen 80;      # directive in server context
  }
}

用＃填充的行是注释。

Directive Types

由于不同指令的继承模型不同，因此，在多个上下文(context)中使用同一指令时，我们必须注意。共有三种类型的指令，每种指令都有其继承模型。

Normal

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

gzip on;
gzip off; # illegal to have two normal directives in the same context 

server {
  location /downloads {
    gzip off;
  }

  location /assets {
    # gzip is in here
  }
}

Array

在相同上下文(context)中添加太多指令将增加值，而不是完全覆盖它们。在子上下文(context)中定义指令将覆盖给定子上下文中父代的所有值。

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 {
    # this will override all the parent directives
    error_log /var/log/nginx/error_downloads.log;
  }
}

Action Directive

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

例如:在重写指令的情况下，将执行每个匹配的指令。

server {
  rewrite ^ /foobar;

  location /foobar {
    rewrite ^ /foo;
    rewrite ^ /bar;
  }
}

如果我们尝试获取/sample :

  • 执行服务器重写，重写从/sample 跳转到 /foobar 。
  • 然后匹配位置/foobar 。
  • 执行1 st 位置重写，从/foobar 重写到 /foo 。
  • 执行第二个 nd 位置重写，从/foo 重写到 /bar 。

让我们看看不同于 return 指令提供的行为:

server {
  location/{
    return 200;
    return 404;
  }
}

在上述情况下，立即返回200状态。

Context Type

让我们来看一个例子。

# Global context
 ...
 ...
 # http context
http{
     ...
     ...
     # Server context
     server {
              listen 80;
              server_name example.com;
              ...
              ...
              # Location context
              location/{            
                          root /var/www/html;            
                          try_files $uri $uri/ =404;        
                          ...
                          ...
             }
    }
    # Server context
    server {
             ...
             ...
             # Location context
             location/{ 
                         ...
                         ...
             }
    }
    ...
    ...
}

从上面的示例中，我们可以看到HTTP上下文声明了HTTP协议的设置。虚拟主机设置在服务器上下文中声明，并且也包含在http上下文中。服务器上下文中包含用于存储URL设置的位置上下文。

Main Context

最一般的上下文是main context。也称为全局上下文(global context)。main context全局设置Nginx的设置，并且是唯一不包含在典型上下文块中并且也不被花括号包围的上下文。

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

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

user nginx;
worker_processes auto;
pid /run/nginx.pid;
...
...

Events Context

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

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

# main context
events {
        # events context
      	worker_connections 768;	
      	multi_accept on;
}
...
...

HTTP Context

HTTP 上下文(context)用于保存用于处理HTTP或HTTPS流量的指令。

HTTP 上下文(context)是事件上下文的同级，因此必须将它们并排列出，而不是嵌套列出。它们都是主要环境的孩子。

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

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 Context

服务器上下文(context)在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 Context

Location 上下文(context)定义了用于处理客户端请求的指令。当任何资源请求到达Nginx时，它将尝试将URI(统一资源标识符)与位置之一进行匹配并进行相应的处理。

可以在服务器块内定义多个位置上下文。此外，位置上下文也可以嵌套在另一个位置上下文中。

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 Context

Upstream 上下文(context)用于配置和定义Upstream服务器。允许此上下文定义后端服务器池，Nginx可以在请求时代理使用的后端服务器。通常，这种情况是我们正在配置各种类型的代理。

Upstream上下文使Nginx可以在代理请求时执行负载平衡。此上下文在HTTP上下文内部和任何服务器上下文外部定义。

在服务器或位置块中按名称引用Upstream上下文。然后将某种类型的请求传递到已定义的服务器池。然后，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;
             }
  }
}

Mail Context

尽管Nginx最常用作Web或反向代理服务器，但它也可以用作高性能邮件代理服务器。用于此类指令的上下文称为Mail Context。邮件上下文在主或全局上下文内或在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 Context

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

由于上下文的某些限制，应尽可能避免使用if上下文。

http {
        server {
                     location /some_url {
                     if (test_condition) {
                          # do some stuff here
                   }

         }
    }
}

Limit_except Context

limit_except上下文(context)用于防止在位置上下文中使用除我们明确允许的方法以外的所有HTTP方法。例如，如果某些客户端应有权访问 POST内容，而每个人都应具有阅读内容的能力，则我们可以为此使用 limit_except 上下文。

...
...
location /wp-admin/ { 
    limit_except GET { 
      allow 127.0.0.1; 
      deny all; 
    } 
}
...
...

上面的示例允许所有访问者在/wp-admin位置使用 GET 标头。如果其他HTTP标头仅源自本地地址，则允许使用其他HTTP标头。

Miscellaneous Context

除了以上上下文，Nginx中几乎没有其他可用上下文，下面将对其进行描述。这些上下文取决于可选模块，很少使用。

  • split_clients   -  split_client上下文将客户的请求分为两个或多个类别。此上下文在HTTP上下文中定义，主要用于A/B测试。
  • geo                   -  地理位置上下文对客户端IP地址进行了分类。它用于根据连接的IP地址来映射变量的值。
  • charset_map -  此上下文用于将特定的字符集添加到" Content-Type"响应头字段中。另外，使用上下文，可以将数据从一个字符集转换为另一种字符集，但有一些限制。
  • map                  -  映射上下文用于创建变量，其值取决于其他变量的值，并在http上下文中定义。
  • perl/perl_set  -  它用于在Perl中实现位置和变量处理程序，并将Perl调用插入SSI。此外，借助perl_set上下文，我们可以为特定的安装Perl处理程序。
  • types               - 类型上下文会使用正确的文件扩展名映射MIME类型。该上下文可以出现在http上下文，服务器上下文或位置上下文中。
posted @ 2021-07-16 11:02  无涯教程  阅读(562)  评论(0)    收藏  举报