無涯教程： Nginx - 指令與上下文
預設情況下，nginx配置檔案可以位於:
/etc/nginx/nginx.conf,/usr/local/etc/nginx/nginx.conf, or/usr/local/nginx/conf/nginx.conf
配置檔案的位置將根據Nginx的安裝過程而有所不同。
該檔案具有以下內容:
Directive
Nginx中的配置選項稱為指令(Directive)。該選項具有名稱和引數，並且必須以分號(;)結尾，否則Nginx將無法載入配置併產生錯誤。
示例:
gzip on;
Context
當我們在文字編輯器中開啟核心Nginx配置檔案時，我們首先會注意到配置以樹狀結構組織，並用花括號包圍，即" {"和"}"。這些用大括號括起來的位置稱為 context ，用於放置配置指令。此外，配置指令及其引數以分號結尾。
這是我們可以宣告指令的部分。它類似於程式語言中的範圍。
context可以巢狀在其他上下文(context)中，從而建立上下文(context)層次結構。
示例:
worker_processes 2; # directive in the global contexthttp { # http context
gzip on; # directive in http context
server { # server context
listen 80; # directive in server context
}
}
用＃填充的行是註釋。
Directive Types
由於不同指令的繼承模型不同，因此，在多個上下文(context)中使用同一指令時，我們必須注意。共有三種型別的指令，每種指令都有其繼承模型。
Normal
每個上下文(context)有一個值。而且我們只能在上下文(context)中定義一次。子上下文(context)可以覆蓋父指令，但是此覆蓋僅在給定的子上下文(context)中有效。
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
}
}
Array
在相同上下文(context)中新增太多指令將增加值，而不是完全覆蓋它們。在子上下文(context)中定義指令將覆蓋給定子上下文中父代的所有值。
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;
}
}
Action Directive
Active是用於更改事物的指令。它們的繼承行為將取決於模組。
例如:在重寫指令的情況下，將執行每個匹配的指令。
server { rewrite ^ /foobar; location /foobar { rewrite ^ /foo; rewrite ^ /bar;
}
}
如果我們嘗試獲取/sample :
執行伺服器重寫，重寫從/sample 跳轉到 /foobar 。
然後匹配位置/foobar 。
執行1 st 位置重寫，從/foobar 重寫到 /foo 。
執行第二個 nd 位置重寫，從/foo 重寫到 /bar 。
讓我們看看不同於 return 指令提供的行為:
server {
location/{ return 200; return 404;
}
}
在上述情況下，立即返回200狀態。
Context Type
讓我們來看一個例子。
# Global context
...
... # http contexthttp{
...
... # 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設定的位置上下文。
Main Context
最一般的上下文是main context。也稱為全域性上下文(global context)。main context全域性設定Nginx的設定，並且是唯一不包含在典型上下文塊中並且也不被花括號包圍的上下文。
main context位於核心Nginx配置檔案的開頭。此上下文的指令不能在任何其他上下文中繼承，因此不能被覆蓋。
main context用於配置在基本級別上影響整個應用程式的詳細資訊。在main context中配置的一些常見的詳細資訊是執行工作程式的使用者和組，工作程式的總數以及用於儲存主程式ID的檔案。整個應用程式的預設錯誤檔案可以在main context級別設定。
user nginx;worker_processes auto;pid /run/nginx.pid;......
Events Context
事件上下文設定用於連線處理的全域性選項。事件上下文包含在main context中。 Nginx配置中只能定義一個事件上下文。
Nginx使用基於事件的連線處理模型，因此在此上下文中定義的指令確定工作程式應如何處理連線。
# main contextevents { # events context
worker_connections 768;
multi_accept on;}......
HTTP Context
HTTP 上下文(context)用於儲存用於處理HTTP或HTTPS流量的指令。
HTTP 上下文(context)是事件上下文的同級，因此必須將它們並排列出，而不是巢狀列出。它們都是主要環境的孩子。
較低的上下文處理請求，此級別的指令控制每個虛擬伺服器的定義預設值。
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 Context
伺服器上下文(context)在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 Context
Location 上下文(context)定義了用於處理客戶端請求的指令。當任何資源請求到達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
}
}}
Upstream Context
Upstream 上下文(context)用於配置和定義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
}
}}
Mail Context
儘管Nginx最常用作Web或反向代理伺服器，但它也可以用作高效能郵件代理伺服器。用於此類指令的上下文稱為Mail Context。郵件上下文在主或全域性上下文內或在http上下文外定義。
郵件上下文的主要目的是提供一個用於在伺服器上配置郵件代理解決方案的區域。 Nginx可以將身份驗證請求重定向到外部身份驗證伺服器。然後，它可以提供對POP3，SMTP和IMAP郵件伺服器的訪問，以提供實際的郵件資料。
通常，郵件上下文如下所示:
# main contextmail {
server_name mail.example.com;
auth_http localhost:9000/cgi-bin/nginxauth.cgi;
proxy_pass_error_message on;
...}http {}......
If Context
if Context用於允許有條件地執行其中定義的指令。 If上下文就像其他任何程式語言的" if語句"一樣。如果給定條件返回true，則if上下文將執行所包含的指令。
由於上下文的某些限制，應儘可能避免使用if上下文。
http {
server {
location /some_url {
if (test_condition) { # do some stuff here
}
}
}}
Limit_except Context
limit_except上下文(context)用於防止在位置上下文中使用除我們明確允許的方法以外的所有HTTP方法。例如，如果某些客戶端應有權訪問 POST內容，而每個人都應具有閱讀內容的能力，則我們可以為此使用 limit_except 上下文。
......location /wp-admin/ {
limit_except GET {
allow 127.0.0.1;
deny all;
} }......
上面的示例允許所有訪問者在/wp-admin位置使用 GET 標頭。如果其他HTTP標頭僅源自本地地址，則允許使用其他HTTP標頭。
Miscellaneous Context
除了以上上下文，Nginx中幾乎沒有其他可用上下文，下面將對其進行描述。這些上下文取決於可選模組，很少使用。
split_clients - split_client上下文將客戶的請求分為兩個或多個類別。此上下文在HTTP上下文中定義，主要用於A/B測試。
geo - 地理位置上下文對客戶端IP地址進行了分類。它用於根據連線的IP地址來對映變數的值。
charset_map - 此上下文用於將特定的字符集新增到" Content-Type"響應頭欄位中。另外，使用上下文，可以將資料從一個字符集轉換為另一種字符集，但有一些限制。
map - 對映上下文用於建立變數，其值取決於其他變數的值，並在http上下文中定義。
perl/perl_set - 它用於在Perl中實現位置和變數處理程式，並將Perl呼叫插入SSI。此外，藉助perl_set上下文，我們可以為特定的安裝Perl處理程式。
types - 型別上下文會使用正確的副檔名對映MIME型別。該上下文可以出現在http上下文，伺服器上下文或位置上下文中。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/756/viewspace-2797480/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 無涯教程:Node.js - OSNode.js
- 無涯教程：Docker - Python安裝DockerPython
- 無涯教程：Docker - Java安裝DockerJava
- 無涯教程: Laravel 8 - 模型觀察者Laravel模型
- 無涯教程: Node.js - Web模組Node.jsWeb
- 無涯教程: Node.js - 事件傳送Node.js事件
- 無涯教程: Laravel 8 - 自定義函式介紹Laravel函式
- nginx location指令Nginx
- nginx的gzip指令介紹，Nginx的gzip指令使用小結Nginx
- nginx的listen指令解析Nginx
- nginx重啟指令碼Nginx指令碼
- 知無涯，行者之路莫言終（我的程式設計之路）程式設計
- Nginx Location 指令語法解析Nginx
- nginx常用配置教程。Nginx
- Nginx 極簡教程Nginx
- Nginx 詳細教程Nginx
- 小心Nginx的add_header指令NginxHeader
- Nginx的mirror指令能幹啥？Nginx
- 如何用好Nginx的gzip指令Nginx
- nginx gzip on 無效Nginx
- Nginx，Charles與Webpack配置前端API代理教程(超詳細)NginxWeb前端API
- nginx的反向代理proxy_pass指令Nginx
- shell指令碼一鍵安裝nginx指令碼Nginx
- CentOS7 nginx啟動指令碼CentOSNginx指令碼
- nginx listen指令淺析之add listenNginx
- 谷歌推出無限上下文的新Transformer谷歌ORM
- iOS彙編教程（六）CPU 指令重排與記憶體屏障iOS記憶體
- Linux系統Nginx最佳化與防盜鏈詳細教程LinuxNginx
- ffmpeg與nginxNginx
- 史丹佛新作：無指令調優的指令遵循
- nginx反向代理快取教程。Nginx快取
- Nginx快取設定教程Nginx快取
- mac無坑安裝nginxMacNginx
- 《Bash 指令碼教程》釋出了指令碼
- 在指令碼中呼叫git命令：指定git命令執行上下文指令碼Git
- Nginx 學習系列（三） ------------- alias、root指令區別Nginx
- shell指令碼一鍵安裝nginx-1.18.0指令碼Nginx
- 圖解Javascript上下文與作用域圖解JavaScript