📅 最后修改于: 2021-01-07 06:08:30 🧑 作者: Mango
默认情况下，nginx配置文件可以位于：
/etc/nginx/nginx.conf,
/usr/local/etc/nginx/nginx.conf, or
/usr/local/nginx/conf/nginx.conf
配置文件的位置将根据Nginx的安装过程而有所不同。
该文件具有以下内容：
Nginx中的配置选项称为指令。该选项具有名称和参数，并且必须以分号(;)结尾，否则Nginx将无法加载配置并产生错误。
例：
gzip on;
当我们在文本编辑器中打开核心Nginx配置文件时，我们首先会注意到配置是用大括号(即“ {”和“}”)包围的树状结构组织的。用括号括起来的这些位置称为放置配置指令的上下文。此外，配置指令及其参数以分号结尾。
这是我们可以声明指令的部分。它类似于编程语言中的范围。
上下文可以嵌套在其他上下文中，从而创建上下文层次结构。
例：
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
}
}
用＃填充的行是注释，Nginx不解释。
由于不同指令的继承模型不同，因此，在多个上下文中使用同一指令时，我们必须注意。共有三种类型的指令，每种指令都有其继承模型。
每个上下文有一个值。而且我们只能在上下文中定义一次。子上下文可以覆盖父指令，但是此覆盖仅在给定的子上下文中有效。
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
}
}
在相同上下文中添加太多指令将增加值，而不是完全覆盖它们。在子上下文中定义指令将覆盖给定子上下文中父代的所有值。
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;
}
}
动作是用于更改事物的指令。它们的继承行为将取决于模块。
例如：在重写指令的情况下，将执行每个匹配的指令。
server {
rewrite ^ /foobar;
location /foobar {
rewrite ^ /foo;
rewrite ^ /bar;
}
}
如果我们尝试获取/ sample ：
让我们看看不同于return指令提供的行为：
server {
location / {
return 200;
return 404;
}
}
在上述情况下，立即返回200状态。
让我们来看一个例子。
# 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设置的位置上下文。
最一般的上下文是主要上下文。也称为全局上下文。主上下文全局设置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或HTTPS流量的指令。
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;
...
...
}
服务器上下文在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;
...
}
}
位置上下文定义指令以处理客户端的请求。当任何资源请求到达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
}
}
}
上游上下文用于配置和定义上游服务器。允许此上下文定义后端服务器池，Nginx可以在请求时代理使用的后端服务器。通常，这种情况是我们正在配置各种类型的代理。
上游上下文使Nginx可以在代理请求时执行负载平衡。此上下文在HTTP上下文内部和任何服务器上下文外部定义。
在服务器或位置块中按名称引用上游上下文。然后将某种类型的请求传递到已定义的服务器池。然后，上游将使用一种算法(默认为循环轮询)来确定需要使用哪个特定服务器来处理请求。
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语句”一样。如果给定条件返回true，则if上下文将执行所包含的指令。
由于上下文的某些限制，应尽可能避免使用if上下文。使用此链接可了解更多关于为什么应避免使用nginx的信息，这将在此处进行讨论。
http {
server {
location /some_url {
if (test_condition) {
# do some stuff here
}
}
}
}
limit_except上下文用于防止在位置上下文中使用除我们明确允许的方法以外的所有HTTP方法。例如，如果某些客户端应该有权访问POST内容，而每个人都应该具有读取内容的能力，那么我们可以为此使用limit_except上下文。
...
...
location /wp-admin/ {
limit_except GET {
allow 127.0.0.1;
deny all;
}
}
...
...
上面的示例允许所有访问者在/ wp-admin位置使用GET标头。如果其他HTTP标头仅源自本地地址，则允许使用其他HTTP标头。
除了以上上下文，Nginx中几乎没有其他可用上下文，下面将对其进行描述。这些上下文取决于可选模块，很少使用。