默認情況下，nginx 配置文件可以位于：
/etc/nginx/nginx.conf /usr/local/etc/nginx/nginx.conf /usr/local/nginx/conf/nginx.conf
配置文件的位置會根據(jù) Nginx 的安裝過程而有所不同。
該文件具有以下內容：
Nginx 中的配置選項稱為指令。該選項有名稱和參數(shù)，必須以分號 (;) 結尾，否則 Nginx 將無法加載配置并產(chǎn)生錯誤。
例子：
gzip on;
當我們在文本編輯器中打開核心 Nginx 配置文件時，首先我們會注意到配置被組織成樹狀結構，并被花括號包圍，即“{”和“}”。這些被大括號包圍的位置稱為放置配置指令的上下文。此外，配置指令及其參數(shù)以分號結尾。
這是我們可以聲明指令的部分。它類似于編程語言中的作用域。
上下文可以嵌套在其他上下文中，從而創(chuàng)建上下文層次結構。
例子：
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 指令的情況下，每個匹配的指令都會被執(zhí)行。
server {
rewrite ^ /foobar;
location /foobar {
rewrite ^ /foo;
rewrite ^ /bar;
}
}
如果我們嘗試訪問/sample：
讓我們看看return指令提供的不同行為：
server {
location / {
return 200;
return 404;
}
}
從上面的情況來看，200 狀態(tài)立即返回。
讓我們看一個例子。
# 全局上下文
...
...
# 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 協(xié)議的設置。虛擬主機設置在服務器上下文中聲明，包含在 http 上下文中。用于存儲 URL 設置的 location 上下文包含在服務器上下文中。
最一般的上下文是主上下文。它也稱為全局上下文。主上下文全局設置 Nginx 的設置，并且是唯一未被花括號包圍的上下文。
主上下文位于核心 Nginx 配置文件的開頭。此上下文的指令不能在任何其他上下文中繼承，因此不能被覆蓋。
主上下文用于配置在基本級別上影響整個應用程序的詳細信息。在主上下文中配置的一些常見詳細信息是運行工作進程的用戶和組、工作進程總數(shù)以及保存主進程 ID 的文件?？梢栽谥魃舷挛募墑e設置整個應用程序的默認錯誤文件。
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 地址關聯(lián)的資源的請求的處理。
此上下文中的指令可以覆蓋許多可能在 http 上下文中定義的指令，包括文檔位置、日志記錄、壓縮等。 除了從 http 上下文中獲取的指令之外，我們還可以配置文件以嘗試響應請求、發(fā)出重定向和重寫，并設置任意變量。
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（統(tǒng)一資源標識符）與其中一個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 能夠在代理請求的同時執(zhí)行負載平衡。此上下文在 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 上下文外。
郵件上下文的主要目的是為在服務器上配置郵件代理解決方案提供一個區(qū)域。Nginx 可以將身份驗證請求重定向到外部身份驗證服務器。然后，它可以提供對 POP3、SMTP 和 IMAP 郵件服務器的訪問，以提供實際郵件數(shù)據(jù)。
通常，郵件上下文如下所示：
# main context
mail {
server_name mail.example.com;
auth_http localhost:9000/cgi-bin/nginxauth.cgi;
proxy_pass_error_message on;
...
}
http {
}
...
...
if 上下文用于允許有條件地執(zhí)行其中定義的指令。if 上下文就像任何其他編程語言的“if 語句”。如果給定條件返回 true，則 if 上下文將執(zhí)行包含的指令。
由于某些限制，應盡可能避免使用 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 中可用的上下文很少，如下所述。這些上下文依賴于可選模塊并且很少使用。