默認(rèn)情況下，nginx 配置文件可以位于：
/etc/nginx/nginx.conf /usr/local/etc/nginx/nginx.conf /usr/local/nginx/conf/nginx.conf
配置文件的位置會(huì)根據(jù) Nginx 的安裝過程而有所不同。
該文件具有以下內(nèi)容：
Nginx 中的配置選項(xiàng)稱為指令。該選項(xiàng)有名稱和參數(shù)，必須以分號(hào) (;) 結(jié)尾，否則 Nginx 將無法加載配置并產(chǎn)生錯(cuò)誤。
例子：
gzip on;
當(dāng)我們?cè)谖谋揪庉嬈髦写蜷_核心 Nginx 配置文件時(shí)，首先我們會(huì)注意到配置被組織成樹狀結(jié)構(gòu)，并被花括號(hào)包圍，即“{”和“}”。這些被大括號(hào)包圍的位置稱為放置配置指令的上下文。此外，配置指令及其參數(shù)以分號(hào)結(jié)尾。
這是我們可以聲明指令的部分。它類似于編程語言中的作用域。
上下文可以嵌套在其他上下文中，從而創(chuàng)建上下文層次結(jié)構(gòu)。
例子：
worker_processes 2; # 全局上下文中的指令
http { # http 上下文
gzip on; # http 上下文中的指令
server { # 服務(wù)器上下文
listen 80; # 服務(wù)器上下文中的指令
}
}
用# 填充的行是注釋，Nginx 不會(huì)解釋。
由于不同指令的繼承模型不同，因此在多個(gè)上下文中使用同一個(gè)指令時(shí)要注意。共有三種類型的指令，每種類型都有其繼承模型。
每個(gè)上下文有一個(gè)值。我們只能在上下文中定義它一次。子上下文可以覆蓋父指令，但此覆蓋僅在給定的子上下文中有效。
gzip on;
gzip off; # 在同一個(gè)上下文中有兩個(gè)普通指令是非法的
server {
location /downloads {
gzip off;
}
location /assets {
# gzip 在這里有效
}
}
在同一上下文中添加多條指令會(huì)增加值而不是完全覆蓋它們。在子上下文中定義指令將覆蓋給定子上下文中父級(jí)的所有值。
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 {
# 這將覆蓋父級(jí)所有指令
error_log /var/log/nginx/error_downloads.log;
}
}
動(dòng)作是用于改變事物的指令。它們的繼承行為將取決于模塊。
例如：在 rewrite 指令的情況下，每個(gè)匹配的指令都會(huì)被執(zhí)行。
server {
rewrite ^ /foobar;
location /foobar {
rewrite ^ /foo;
rewrite ^ /bar;
}
}
如果我們嘗試訪問/sample：
讓我們看看return指令提供的不同行為：
server {
location / {
return 200;
return 404;
}
}
從上面的情況來看，200 狀態(tài)立即返回。
讓我們看一個(gè)例子。
# 全局上下文
...
...
# http 上下文
http{
...
...
# 服務(wù)器上下文
server {
listen 80;
server_name example.com;
...
...
# Location 上下文
location / {
root /var/www/html;
try_files $uri $uri/ =404;
...
...
}
}
# 服務(wù)器上下文
server {
...
...
# Location 上下文
location / {
...
...
}
}
...
...
}
從上面的例子中，我們可以看到 HTTP 上下文聲明了 HTTP 協(xié)議的設(shè)置。虛擬主機(jī)設(shè)置在服務(wù)器上下文中聲明，包含在 http 上下文中。用于存儲(chǔ) URL 設(shè)置的 location 上下文包含在服務(wù)器上下文中。
最一般的上下文是主上下文。它也稱為全局上下文。主上下文全局設(shè)置 Nginx 的設(shè)置，并且是唯一未被花括號(hào)包圍的上下文。
主上下文位于核心 Nginx 配置文件的開頭。此上下文的指令不能在任何其他上下文中繼承，因此不能被覆蓋。
主上下文用于配置在基本級(jí)別上影響整個(gè)應(yīng)用程序的詳細(xì)信息。在主上下文中配置的一些常見詳細(xì)信息是運(yùn)行工作進(jìn)程的用戶和組、工作進(jìn)程總數(shù)以及保存主進(jìn)程 ID 的文件?？梢栽谥魃舷挛募?jí)別設(shè)置整個(gè)應(yīng)用程序的默認(rèn)錯(cuò)誤文件。
user nginx; worker_processes auto; pid /run/nginx.pid; ... ...
事件上下文為連接處理設(shè)置全局選項(xiàng)。事件上下文包含在主上下文中。Nginx 配置中只能定義一個(gè)事件上下文。
Nginx 使用基于事件的連接處理模型，因此在此上下文中定義的指令決定了工作進(jìn)程應(yīng)如何處理連接。
# main context
events {
# events context
worker_connections 768;
multi_accept on;
}
...
...
HTTP 上下文用于保存處理 HTTP 或 HTTPS 流量的指令。
HTTP 上下文是事件上下文的兄弟，因此它們必須并排列出，而不是嵌套。他們都是主要上下文的孩子。
較低的上下文處理請(qǐng)求，此級(jí)別的指令控制每個(gè)虛擬服務(wù)器的定義默認(rèn)值。
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;
...
...
}
服務(wù)器上下文在 http 上下文中聲明。服務(wù)器上下文用于定義 Nginx 虛擬主機(jī)設(shè)置。HTTP 上下文中可以有多個(gè)服務(wù)器上下文。服務(wù)器上下文中的指令處理對(duì)與特定域名或 IP 地址關(guān)聯(lián)的資源的請(qǐng)求的處理。
此上下文中的指令可以覆蓋許多可能在 http 上下文中定義的指令，包括文檔位置、日志記錄、壓縮等。 除了從 http 上下文中獲取的指令之外，我們還可以配置文件以嘗試響應(yīng)請(qǐng)求、發(fā)出重定向和重寫，并設(shè)置任意變量。
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上下文定義指令來處理客戶端的請(qǐng)求。當(dāng)任何對(duì)資源的請(qǐng)求到達(dá) Nginx 時(shí)，它會(huì)嘗試將 URI（統(tǒng)一資源標(biāo)識(shí)符）與其中一個(gè)location匹配并相應(yīng)地處理它。
可以在服務(wù)器塊內(nèi)定義多個(gè)location上下文。此外，一個(gè)location上下文也可以嵌套在另一個(gè)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 上下文用于配置和定義上游服務(wù)器。允許此上下文定義后端服務(wù)器池，Nginx 可以代理請(qǐng)求時(shí)使用的后端服務(wù)器。這個(gè)上下文通常是我們正在配置的各種類型的代理。
upstream 上下文使 Nginx 能夠在代理請(qǐng)求的同時(shí)執(zhí)行負(fù)載平衡。此上下文在 HTTP 上下文內(nèi)部和任何服務(wù)器上下文外部定義。
upstream 上下文在服務(wù)器或 location 塊中按名稱引用。然后將某種類型的請(qǐng)求傳遞給定義好的服務(wù)器池。然后 upstream 將使用算法（默認(rèn)為輪詢）來確定需要使用哪個(gè)特定服務(wù)器來處理請(qǐng)求。
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 或反向代理服務(wù)器，但它也可以用作高性能郵件代理服務(wù)器。用于此類指令的上下文稱為郵件上下文。郵件上下文定義在主上下文或全局上下文內(nèi)或 http 上下文外。
郵件上下文的主要目的是為在服務(wù)器上配置郵件代理解決方案提供一個(gè)區(qū)域。Nginx 可以將身份驗(yàn)證請(qǐng)求重定向到外部身份驗(yàn)證服務(wù)器。然后，它可以提供對(duì) POP3、SMTP 和 IMAP 郵件服務(wù)器的訪問，以提供實(shí)際郵件數(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í)行包含的指令。
由于某些限制，應(yīng)盡可能避免使用 if 上下文。
http {
server {
location /some_url {
if (test_condition) {
# do some stuff here
}
}
}
}
limit_except 上下文用于防止在 location 上下文中使用除我們明確允許的方法之外的所有 HTTP 方法。例如，如果某些客戶端應(yīng)該有權(quán)訪問POST 內(nèi)容并且每個(gè)人都應(yīng)該有能力閱讀內(nèi)容，那么我們可以為此使用limit_except上下文。
...
...
location /wp-admin/ {
limit_except GET {
allow 127.0.0.1;
deny all;
}
}
...
...
除了上述上下文之外，Nginx 中可用的上下文很少，如下所述。這些上下文依賴于可選模塊并且很少使用。