nginx笔记1：nginx指令与上下文

1、Nginx 指令和上下文

本内容来源于菜鸟：https://www.cainiaojc.com/nginx/nginx-directive-and-context.html

1.1 Directive：

nginx中的配置选项称为指令。该选项有名称和参数，必须以分号（；）结尾，否则nginx将无法加载配置并产生错误。

例子：

gzip on；

1.2 context:

当我们在文本编辑器中打开核心nginx配置文件时，首先我们会注意到配置被组织成树状结构，并且被花括号包围，即“{ }”，这些被花括号包围的位置成为放置配置指令的上下文，此外，配置指令及其参数以分号结尾。

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

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

例子：

worker_processes 2;		# 全局上下文中的指令	
http {				   # http上下文
	gzip on;		   # http上下文中的指令
	server {		   # 服务器上下文
		listen 80;	   # 服务器上下文中的指令
	}
}

用 # 填充的行是注释，nginx 不会解释。

1.3 指令类型

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

1.3.1 普通的：

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

gzip on;
gzip off;# 在同一个上下文中有两个普通指令是非法的  
server {
	location /downloads {
	gzip off;
	}
	location /assets {
	# gzip 在这里有效
	}
}

1.3.2 array

在同一上下文中添加多条指令会增加值而不是完全覆盖他们，在子上下文中定义指令将覆盖给定子撒谎给你下问中父级的所有值。

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;
	}
}

1.3.3 action directive

动作是用于改变事务的指令，他们的继承行行为将取决于模块。

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

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

如果我们尝试访问 /sample:

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

1.4 上下文类型

1.4.1 全局上下文

全局上下文设置nginx的设置，并且是唯一没有被花括号包围的上下文。

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

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

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

1.4.2 事件上下文

事件上下文为连接处理设置全局选项，事件上下文包含在全局上下文中。nginx 配置中只能定义一个事件上下文。

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

# main context
events {
	# events context
	worker_connection 768;
	multi_accept on;
}

1.4.3 http上下文

http上下文用于保存处理 http 或 https 流量的指令

http上下文是事件上下文的兄弟，因此他们必须并排列出，而不是嵌套。他们都是全局上下文的孩子。

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

user nginx;
worker_processes auto;
pid /run/nginx.pid;
events {
	# events context
	worker_connection 768;
	multi_accept on;
}
http {
	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;
	keepalive_timeout 65;
}

1.4.4 服务器上下文

服务器上下文在http上下文中声明。服务器上下文用于定义nginx虚拟主机设置。http上下文中可以有多个服务器上下文。服务器上下文中的指令处理的是对与特定域名或IP地址关联的资源的请求。

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

user nginx;
worker_processes auto;
pid /run/nginx.pid;
events {
	# events context
	worker_connection 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;
	}
}

1.4.5 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 /another_url {
			# configuration for processing URIs starting with /another_url
		}
	}
}

1.4.6 upstream 上下文

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;
		}
	}
}

1.4.7 邮件上下文

尽管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 {

}

1.4.8 if上下文

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

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

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

1.4.9 limit_except 上下文

limit_except 上下文用于防止在 location 上下文中使用除我们明确允许的方法之外的所有 HTTP 方法。例如，如果某些客户端应该有权访问POST 内容并且每个人都应该有能力阅读内容，那么我们可以为此使用limit_except上下文。

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

1.2.10 杂项上下文

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

1、split_clients： split_client 上下文将客户端的请求拆分为两个或多个类别。该上下文定义在 HTTP 上下文中，主要用于 A/B 测试。
2、geo： geo 上下文对客户端 IP 地址进行分类。它用于根据连接的 IP 地址映射变量的值。
3、charset_map：此上下文用于将特定字符集添加到“Content-Type”响应头字段。此外，使用上下文，可以将数据从一个字符集转换为另一个字符集，但有一些限制。
4、map： map上下文用于创建变量，其值依赖于其他变量的值，并在http上下文中定义。
5、perl/perl_set：用于在 Perl 中实现位置和变量处理程序，并将 Perl 调用插入 SSI。此外，在 perl_set 上下文的帮助下，我们可以为特定变量安装 Perl 处理程序。
6、类型：类型上下文用正确的文件扩展名映射 MIME 类型。此上下文可能出现在 http 上下文、服务器上下文或位置上下文中。