默认情况下，nginx 配置文件可以位于：
/etc/nginx/nginx.conf /usr/local/etc/nginx/nginx.conf /usr/local/nginx/conf/nginx.conf
配置文件的位置会根据 Nginx 的安装过程而有所不同。
该文件具有以下内容：
Nginx 中的配置选项称为指令。该选项有名称和参数，必须以分号 (;) 结尾，否则 Nginx 将无法加载配置并产生错误。
例子：
gzip on;
当我们在文本编辑器中打开核心 Nginx 配置文件时，首先我们会注意到配置被组织成树状结构，并被花括号包围，即“{”和“}”。这些被大括号包围的位置称为放置配置指令的上下文。此外，配置指令及其参数以分号结尾。
这是我们可以声明指令的部分。它类似于编程语言中的作用域。
上下文可以嵌套在其他上下文中，从而创建上下文层次结构。
例子：
worker_processes 2; # 全局上下文中的指令
http { # http 上下文
gzip on; # http 上下文中的指令
server { # 服务器上下文
listen 80; # 服务器上下文中的指令
}
}
用# 填充的行是注释，Nginx 不会解释。
由于不同指令的继承模型不同，因此在多个上下文中使用同一个指令时要注意。共有三种类型的指令，每种类型都有其继承模型。
每个上下文有一个值。我们只能在上下文中定义它一次。子上下文可以覆盖父指令，但此覆盖仅在给定的子上下文中有效。
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：
让我们看看return指令提供的不同行为：
server {
location / {
return 200;
return 404;
}
}
从上面的情况来看，200 状态立即返回。
让我们看一个例子。
# 全局上下文
...
...
# 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 或 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上下文定义指令来处理客户端的请求。当任何对资源的请求到达 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 上下文用于配置和定义上游服务器。允许此上下文定义后端服务器池，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 语句”。如果给定条件返回 true，则 if 上下文将执行包含的指令。
由于某些限制，应尽可能避免使用 if 上下文。
http {
server {
location /some_url {
if (test_condition) {
# do some stuff here
}
}
}
}
limit_except 上下文用于防止在 location 上下文中使用除我们明确允许的方法之外的所有 HTTP 方法。例如，如果某些客户端应该有权访问POST 内容并且每个人都应该有能力阅读内容，那么我们可以为此使用limit_except上下文。
...
...
location /wp-admin/ {
limit_except GET {
allow 127.0.0.1;
deny all;
}
}
...
...
除了上述上下文之外，Nginx 中可用的上下文很少，如下所述。这些上下文依赖于可选模块并且很少使用。