⑴ [後端]nginx配置文件詳解
一個典型的nginx配置文件是由一系列的server塊組成。而每個server塊是有一系列的location塊組成。server塊是nginx從邏輯上劃分出來的一個個的虛擬伺服器，可以從邏輯上認為你的伺服器變成多個了。block塊定義了一個url路徑該如何定位到正式的文件。總體來說，nginx處理一個請求的時候，先根據(ip地址，port埠，domain域名)來確定下由哪一個server塊來進行處理，然後server塊再根據請求的地址來進行location塊的挑選，location塊內部的規則最終確定下這個請求怎麼返回（直接返迴文件內容，還是映射成其他請求，還是傳給其他服務執行）。
如果我們訪問鏈接 http://lab.example.com:80/cs/image.jpg 那麼就會由第一個server的第二個location來處理。流程是什麼樣的呢：
這樣就完成了一個完整的鏈接請求。
server塊最重要的兩個屬性是listen和server_name。當請求來臨時，listen屬性先用來匹配，如果匹配到唯一server塊那麼就是這個server塊進行服務（就不用考慮server_name是否匹配上了）；如果匹配不是唯一的，那麼就繼續使用server_name進行匹配。
當兩個表達帶通配符的形式相同的時候，匹配最長的那個。
語法中的optional_modifier是描述符，location_match是具體匹配的串形式，如果描述符是正則的一種，那麼就會以正則的方式來對待location_match，否則以普通方式用location_match來當前綴匹配。
|類型|含義|匹配方式|優先順序|例子|
|:--|:--|:--|:--|
|(none)|最普通的前綴匹配|前綴方式匹配|4|location / {}|
|=|要求絕對相等|前綴方式匹配|1|location = /image {}|
|~|區分大小寫的正則匹配|正則方式匹配|3|location ~ .(jpe?g)$ {}|
|~ |不區分大小寫的正則匹配|正則方式匹配|3|location ~ .(jpe?g)$ {}|
|^~|高優先順序的前綴匹配|前綴方式匹配|2|location ^~ /page {}|
如果我們要匹配\big\middle\small的話，是不會匹配到 location ^~ \big\middle {...} 這條規則的，因為當=規則匹配結束沒找到之後，就回去找(none)和^~中匹配最長的一條，這時候最長的是(none)的 location \big\middle\small {...} ，然後在進行正則匹配，發現沒有滿足的，於是就取(none)的這一條了。這一點要注意。
在上述步驟後，我們知道一個請求具體定位到location的過程，現在來繼續探究location之後的相應處理。首先是location中的資源應該對應在哪一個伺服器目錄中呢？這就需要root屬性來指定了。
root屬性可以定義在server塊中，也可以定義在location塊中。如果聲明在server塊中那麼所有的location都會繼承這個定義。同時若location中也定義了root屬性，那麼以location中的定義為主。
舉個例子
如果訪問/cs/vr/audio.mp3，那麼就會對應到伺服器上的/share/usr/cs/vr/audio.mp3的資源
如果訪問/eg/file/new.pdf，那麼就會對應到伺服器上的/var/www/html/eg/file/new.pdf的資源
再比如用nginx上架設codeigniter框架，我們需要重寫url那麼我們這樣
那麼這樣，對於一個非.php的文件，都為在第一個location中重寫成/index.php?$uri的形式重寫進行一次搜索。這時候必然被第二個location接收（前綴匹配的更長嘛），這樣就完成了codeigniter的定位。
比如我們訪問 ci.example.com/hello 就會被重定向到訪問var/www/example/index.php?hello同時被pass給php的cgi進行處理。
Understanding Nginx Server and Location Block Selection Algorithms
how-to-configure-nginx
⑵ nginx配置文件詳解
一、安裝Nginx
在安裝Nginx之前，需確保系統已經安裝了gcc、 openssl-devel、 pcre-devel和zlib-devel軟體庫。
其中， _with-http_stub_status_mole 可以用來啟用 Nginx 的 NginxStatus 功能，以監控 Nginx 的運行狀態。
二、Nginx的配置文件結構
Nginx的配置文件nginx.conf位於其安裝目錄的conf目錄下。
nginx.conf由多個塊組成，最外面的塊是main，main包含Events和HTTP，HTTP包含upstream和多個Server，Server又包含多個location。
main（全局設置）、server（主機設置）、upstream（負載均衡伺服器設置）和 location（URL匹配特定位置的設置）。
1、main塊設置的指令將影響其他所有設置。
2、server塊的指令主要用於指定主機和埠。
3、upstream指令主要用於負載均衡，設置一系列的後端伺服器。
4、location塊用於匹配網頁位置。
這四者之間的關系式：server繼承main，location繼承server，upstream既不會繼承其他設置也不會被繼承。
在這四個部分當中，每個部分都包含若干指令，這些指令主要包含Nginx的主模塊指令、事件模塊指令、HTTP核心模塊指令，同時每個部分還可以使用其他HTTP模塊指令，例如Http SSL模塊、HttpGzip Static模塊和Http Addition模塊等。
三、Nginx的全局配置
events事件指令是設定Nginx的工作模式及連接數上限：
use是個事件模塊指令，用來指定Nginx的工作模式。Nginx支持的工作模式有select、poll、kqueue、epoll、rtsig和/dev/poll。
其中select和poll都是標準的工作模式，kqueue和epoll是高效的工作模式，不同的是epoll用在Linux平台上，而kqueue用在BSD系統中。對於Linux系統，epoll工作模式是首選worker_connections也是個事件模塊指令，用於定義Nginx每個進程的最大連接數，默認是1024。
最大客戶端連接數由worker_processes和worker_connections決定，即Max_client=worker_processes*worker_connections。
在作為反向代理時，max_clients變為：max_clients = worker_processes * worker_connections/4。
進程的最大連接數受Linux系統進程的最大打開文件數限制，在執行操作系統命令「ulimit -n 65536」後worker_connections的設置才能生效。
四、下面配置Nginx的HttpGzip模塊。這個模塊支持在線實時壓縮輸出數據流。
通過/opt/nginx/sbin/nginx -V命令可以查看安裝Nginx時的編譯選項，由輸出可知，已經安裝了HttpGzip模塊。
五、負載均衡配置
下面設定負載均衡的伺服器列表：
upstream是Nginx的HTTP Upstream模塊，這個模塊通過一個簡單的調度演算法來實現客戶端IP到後端伺服器的負載均衡。
在上面的設定中，通過upstream指令指定了一個負載均衡器的名稱cs.com。這個名稱可以任意指定，在後面需要的地方直接調用即可，Nginx的負載均衡模塊目前支持4種調度演算法。
六、server虛擬主機配置
下面介紹對虛擬主機的配置。
建議將對虛擬主機進行配置的內容寫進另外一個文件，然後通過include指令包含進來，這樣更便於維護和管理。
server標志定義虛擬主機開始，listen用於指定虛擬主機的服務埠，server_name用來指定IP地址或者域名，多個域名之間用空格分 開。index用於設定訪問的默認首頁地址，root指令用於指定虛擬主機的網頁根目錄，這個目錄可以是相對路徑，也可以是絕對路徑。
Charset用於 設置網頁的默認編碼格式。access_log用來指定此虛擬主機的訪問日誌存放路徑，最後的main用於指定訪問日誌的輸出格式。
七、location URL匹配配置
URL地址匹配是進行Nginx配置中最靈活的部分。 location支持正則表達式匹配，也支持條件判斷匹配，用戶可以通過location指令實現Nginx對動、靜態網頁進行過濾處理。使用location URL匹配配置還可以實現反向代理，用於實現PHP動態解析或者負載負載均衡。
以下這段設置是通過location指令來對網頁URL進行分析處理，所有擴展名以.gif、.jpg、.jpeg、.png、.bmp、.swf結尾的靜態文件都交給nginx處理，而expires用來指定靜態文件的過期時間，這里是30天。
八、StubStatus模塊配置
StubStatus模塊能夠獲取Nginx自上次啟動以來的工作狀態，此模塊非核心模塊，需要在Nginx編譯安裝時手工指定才能使用此功能。
stub_status設置為「on」表示啟用StubStatus的工作狀態統計功能。access_log 用來指定StubStatus模塊的訪問日誌文件。auth_basic是Nginx的一種認證機制。
auth_basic_user_file用來指定認證的密碼文件，由於Nginx的auth_basic認證採用的是與Apache兼容的密碼文件，因此需要用Apache的htpasswd命令來生成密碼文件。
然後輸入兩次密碼後確認之後添加用戶成功。
要查看Nginx的運行狀態，可以輸入http://ip/NginxStatus，輸入創建的用戶名和密碼就可以看到Nginx的運行狀態。
Active connections表示當前活躍的連接數，第三行的三個數字表示 Nginx當前總共處理了34561個連接， 成功創建次握手， 總共處理了354399個請求。
最後一行的Reading表示Nginx讀取到客戶端Header信息數， Writing表示Nginx返回給客戶端的Header信息數，「Waiting」表示Nginx已經處理完，正在等候下一次請求指令時的駐留連接數。
在最後這段設置中，設置了虛擬主機的錯誤信息返回頁面，通過error_page指令可以定製各種錯誤信息的返回頁面。在默認情況下，Nginx會在主目錄的html目錄中查找指定的返回頁面。
特別需要注意的是，這些錯誤信息的返回頁面大小一定要超過512K，否者會被ie瀏覽器替換為ie默認的錯誤頁面。
⑶ 不容錯過的Nginx配置詳解，一文帶你搞懂Nginx
Nginx是一個高性能的HTTP和反向代理伺服器，特點是佔用內存少，並發能力強，事實上Nginx的並發能力確實在同類型的網頁伺服器中表現好。Nginx專為性能優化而開發，性能是其最重要的考量，實現上非常注重效率，能經受高負載的考驗，有報告表明能支持高達50000個並發連接數。
需要客戶自己在瀏覽器配置代理伺服器地址。
例如：在大陸訪問www.google.com，我們需要一個代理伺服器，我們通過代理伺服器去訪問谷歌，這個過程就是正向代理。
反向代理，客戶端對代理是無感知的，因為客戶端不需要任何配置就可以訪問，我們只需要將請求發送到反向代理伺服器，由反向代理伺服器去選擇目標伺服器獲取數據後，在返回給客戶端，此時反向代理伺服器和目標伺服器對外就是一個伺服器，暴露的是代理伺服器地址，隱藏了真實伺服器IP地址。
單個伺服器解決不了，我們增加伺服器的數量，然後將請求分發到各個伺服器上，將原先請求集中到單個伺服器上的情況改為將請求分發到多個伺服器上，將負載分發到不同的伺服器，也就是我們說的負載均衡。
為了加快網站的解析速度，可以把動態頁面和靜態頁面由不同的伺服器來解析，加快解析速度。降低原來單個伺服器的壓力。
進入到下面的目錄，然後使用命令
配置文件所在位置：/usr/local/nginx/conf/nginx.conf
由全局塊+events塊+http塊組成
從配置文件開始到events之間的內容，主要會設置一些影響Nginx伺服器整體運行的配置指令，主要包括配置運行Nginx伺服器的用戶（組）、允許生成的worker process數，進程pid存放路徑、日誌存放路徑和類型以及配置文件的引入等。
events塊設計的指令主要影響Nginx伺服器與用戶的網路連接，常用的設置包括是否開啟對多work process下的網路連接進行序列化，是否允許同時接收多個網路連接，選取哪種事件驅動模型來處理連接請求，每個work process可以同時支持的最大連接數等。下面的例子表示每個work process支持的最大連接數為1024。這部分配置對Nginx的性能影響較大，在實際中應該靈活配置。
Nginx伺服器配置中最頻繁的部分，代理、緩存和日誌定義等絕大多數功能和第三方模塊的配置都在這里，http塊又包括http全局塊和server塊。
http全局塊配置的指令包括文件引入、MIME-TYPE定義、日誌自定義、連接超時時間、單鏈接請求數上限等。
這塊和虛擬主機有密切關系，虛擬主機從用戶角度看，和一台獨立的硬體主機是完全一樣的，該技術的產生是為了節省互聯網伺服器硬體成本。
每個http塊可以包括多個server塊，而每個server塊就相當於一個虛擬主機。
每個server塊也可以分為全局server塊，以及可以同時包含多個location塊。
最常見的配置時本虛擬主機的監聽配置和本虛擬主機的名稱或IP配置。
一個server塊可以配置多個location塊。
這塊的主要作用是基於Nginx伺服器接收到的請求字元串（例如server_name/uri-string），對虛擬主機名稱（也可以是IP別名）之外的字元串（例如前面的/uri-string）進行匹配，對特定的請求進行處理。地址定向、數據緩存和應答控制等功能，還有許多第三方模塊的配置也在這里進行。
訪問http://ip，訪問到的是Tomcat的主頁面http://ip:8080。
Nginx+JDK8+Tomcat
訪問：http://192.168.71.167/，看到的是Tomcat的首頁。
根據訪問的路徑跳轉到不同的伺服器中去。
訪問http://ip:9001/e 直接跳到http://127.0.0.1:8080/e
訪問http://ip:9001/vod 直接跳到http://127.0.0.1:9090/vod
Nginx+JDK8+配置兩個Tomcat，Tomcat的配置不再講述。
訪問http://192.168.71.167:9001/e/a.html跳到了http://127.0.0.1:8080/e/a.html頁面。
訪問http://192.168.71.167:9001/vod/a.html跳到了http://127.0.0.1:9090/vod/a.html頁面。
假如Nginx代理伺服器Server的配置為：192.168.71.167:9001，跳到：127.0.0.1:8080，訪問者的IP為：192.168.71.200:20604。
通過訪問http://192.168.71.167/e/a.html，實現負載均衡的效果，平均分攤到8080和8081埠中。
Nginx+JDK8+2台Tomcat，一台8080，一台8081。
訪問：http://192.168.71.167/e/a.html，8080和8081交替訪問。
1 輪詢（默認）
每個請求按時間順序逐一分配到不同的後端伺服器，如果後端伺服器down掉，能自動剔除。
2 weight
weight代表權重，默認為1，權重越高被分配的客戶端越多。
指定輪詢幾率，weight和訪問比率成正比，用於後端伺服器性能不均的情況。
3 ip_hash
每個請求按訪問IP的hash結果分配，這樣每個訪客固定訪問一個後端伺服器，可以解決session的問題，示例如下：
4 fair（第三方）
按後端伺服器的響應時間來分配請求，響應時間短的優先分配。
訪問圖片：http://192.168.71.167/image/1.jpg
訪問頁面：http://192.168.71.167/www/a.html
訪問目錄：http://192.168.71.167/image/（因為設置了autoindex on;）
兩台機器，每台機器都裝有keepalived+Nginx+Tomcat。
主備keepalived伺服器中只有master一台機器會出現VIP地址，否則會出現腦裂問題。
【提示】腳本要加+x的執行許可權：chmod +x chk_nginx.sh
在Nginx里把虛擬IP配置進去即可。
一個Nginx是由一個master進程和多個worker進程組成的。
客戶端發送請求到Master，然後給worker，再由這些work爭搶處理這個請求。
1 可以使用nginx -s reload進行熱部署方式；
2 每個worker是獨立的進程，如果有其中的一個worker出現了問題，其他worker獨立的繼續進行爭搶，實現請求的過程，不會造成服務的中斷；
Nginx和Redis類似，都採用了io多路復用機制。每個worker進程都可以把CPU發揮到極致，一般來說worker數和伺服器的CPU數相等是最為適宜的。
發送請求：訪問靜態資源佔用2個連接，反向代理佔用4個連接。
【溫馨提示】
⑷ nginx配置location及rewrite
一個示例：
順序優先順序：
上面的匹配結果，按照上面的location寫法，以下的匹配示例成立：
直接匹配網站根，通過域名訪問網站首頁比較頻繁，使用這個會加速處理，這里是直接轉發給後端應用伺服器了，也可以是一個靜態首頁：
rewrite功能就是，使用nginx提供的全局變數或自己設置的變數，結合正則表達式和標志位實現url重寫以及重定向。rewrite只能放在server{},location{},if{}中，並且只能對域名後邊的除去傳遞的參數外的字元串起作用。
例如 http://aaa.com/a/we/index.php?id=1&u=str 只對/a/we/index.php重寫。語法rewrite regex replacement [flag];
如果相對域名或參數字元串起作用，可以使用全局變數匹配，也可以使用proxy_pass反向代理。
表明看rewrite和location功能有點像，都能實現跳轉，主要區別在於rewrite是在同一域名內更改獲取資源的路徑，而location是對一類路徑做控制訪問或反向代理，可以proxy_pass到其他機器。很多情況下rewrite也會寫在location里，它們的執行順序是：
如果其中某步URI被重寫，則重新循環執行1-3，直到找到真實存在的文件；循環超過10次，則返回500 Internal Server Error錯誤。
因為301和302不能簡單的只返回狀態碼，還必須有重定向的URL，這就是return指令無法返回301、302的原因了。這里last和break區別有點難以理解：
語法為if(condition){…}，對給定的條件condition進行判斷。如果為真，大括弧內的rewrite指令將被執行，if條件(conditon)可以是如下任何內容：
-f 和 !-f 用來判斷是否存在文件
-d 和 !-d 用來判斷是否存在目錄
-e 和 !-e 用來判斷是否存在文件或目錄
-x 和 !-x 用來判斷文件是否可執行
例如：
下面是可以用作if判斷的全局變數
例： http://localhost:88/test1/test2/test.php
小括弧 () 之間匹配的內容，可以在後面通過 $1 來引用， $2 表示的是前面第二個 () 里的內容。正則裡面容易讓人困惑的是 \ 轉義特殊字元。
例1：
對形如 /images/ef/uh7b3/test.png 的請求，重寫到 /data?file=test.png ，於是匹配到 location /data ，先看 /data/images/test.png 文件存不存在，如果存在則正常響應，如果不存在則重寫 tryfiles 到新的 image404 location ，直接返回404狀態碼。
例2：
對形如 /images/bla_500x400.jpg 的文件請求，重寫到 /resizer/bla.jpg?width=500&height=400 地址，並會繼續嘗試匹配 location 。
⑸ window 下怎麼配置nginx環境變數
從nginx官網下載相應的安裝包
建議下載 下載穩定版
解壓到相應的目錄，比如我是e盤 然後修改目錄名字為nginx
進入nginx目錄 雙擊nginx.exe 來啟動nginx
此時 直接在瀏覽器地址欄輸入：localhost 便能看到 歡迎頁面，說明你虛擬主機已經搭建好了
但是有時候 我們需要配置路徑 在默認情況下 他的root是 nginx目錄下的html文件夾
如若修改 則打開conf目錄下的nginx.conf
找到server 選項 修改咯location 中的root 選項。
比如我修改到D：/webroot
則修改為
⑹ nginx前端常用配置
nginx現在幾乎是眾多大型網站的必用技術，大多數情況下，我們不需要親自去配置它，但是了解它在應用程序中所擔任的角色，以及如何解決這些問題是非常必要的。
下面我將從nginx在企業中的真實應用來解釋nginx在應用程序中起到的作用。
為了便於理解，首先先來了解一下一些基礎知識， nginx是一個高性能的反向代理伺服器 那麼什麼是反向代理呢？
代理 是在伺服器和客戶端之間假設的一層伺服器， 代理 將接收客戶端的請求並將它轉發給伺服器，然後將服務端的響應轉發給客戶端。
不管是正向代理還是反向代理，實現的都是上面的功能。
正向代理 是為我們服務的，即為客戶端服務的，客戶端可以根據正向代理訪問到它本身無法訪問到的伺服器資源。
正向代理 對我們是透明的，對服務端是非透明的，即服務端並不知道自己收到的是來自代理的訪問還是來自真實客戶端的訪問。
反向代理 是為服務端服務的，反向代理可以幫助伺服器接收來自客戶端的請求，幫助伺服器做請求轉發，負載均衡等。
反向代理 對服務端是透明的，對我們是非透明的，即我們並不知道自己訪問的是代理伺服器，而伺服器知道反向代理在為他服務。
下面是一個nginx配置文件的基本結構：
下面是 nginx 一些配置中常用的內置全局變數，你可以在配置的任何位置使用它們。
| 變數名 | 功能 | | ------ | ------ | | $host | 請求信息中的 Host ，如果請求中沒有 Host 行，則等於設置的伺服器名 | | $request_method | 客戶端請求類型，如 GET 、 POST | $remote_addr | 客戶端的 IP 地址 | | $args | 請求中的參數 | | $content_length | 請求頭中的 Content-length 欄位 | | $http_user_agent | 客戶端agent信息 | | $http_cookie | 客戶端cookie信息 | | $remote_addr | 客戶端的IP地址 | | $remote_port | 客戶端的埠 | | $server_protocol | 請求使用的協議，如 HTTP/1.0 、·HTTP/1.1 | | server_name | 伺服器名稱| | $server_port`|伺服器的埠號|
先追本溯源以下，跨域究竟是怎麼回事。
同源策略限制了從同一個源載入的文檔或腳本如何與來自另一個源的資源進行交互。這是一個用於隔離潛在惡意文件的重要安全機制。通常不允許不同源間的讀操作。
如果兩個頁面的協議，埠（如果有指定）和域名都相同，則兩個頁面具有相同的源。
例如：
現在我在 fe.server.com 對 dev.server.com 發起請求一定會出現跨域。
現在我們只需要啟動一個nginx伺服器，將 server_name 設置為 fe.server.com ,然後設置相應的location以攔截前端需要跨域的請求，最後將請求代理回 dev.server.com 。如下面的配置：
這樣可以完美繞過瀏覽器的同源策略： fe.server.com 訪問 nginx 的 fe.server.com 屬於同源訪問，而 nginx 對服務端轉發的請求不會觸發瀏覽器的同源策略。
根據狀態碼過濾
根據URL名稱過濾，精準匹配URL，不匹配的URL全部重定向到主頁。
根據請求類型過濾。
GZIP 是規定的三種標准HTTP壓縮格式之一。目前絕大多數的網站都在使用 GZIP 傳輸 HTML 、 CSS 、 JavaScript 等資源文件。
對於文本文件， GZip 的效果非常明顯，開啟後傳輸所需流量大約會降至 1/4 ~ 1/3 。
並不是每個瀏覽器都支持 gzip 的，如何知道客戶端是否支持 gzip 呢，請求頭中的 Accept-Encoding 來標識對壓縮的支持。
啟用 gzip 同時需要客戶端和服務端的支持，如果客戶端支持 gzip 的解析，那麼只要服務端能夠返回 gzip 的文件就可以啟用 gzip 了,我們可以通過 nginx 的配置來讓服務端支持 gzip 。下面的 respone 中 content-encoding:gzip ，指服務端開啟了 gzip 的壓縮方式。
這里為什麼默認版本不是 1.0 呢？
HTTP 運行在 TCP 連接之上，自然也有著跟 TCP 一樣的三次握手、慢啟動等特性。
啟用持久連接情況下，伺服器發出響應後讓 TCP 連接繼續打開著。同一對客戶/伺服器之間的後續請求和響應可以通過這個連接發送。
為了盡可能的提高 HTTP 性能，使用持久連接就顯得尤為重要了。
HTTP/1.1 默認支持 TCP 持久連接， HTTP/1.0 也可以通過顯式指定 Connection: keep-alive 來啟用持久連接。對於 TCP 持久連接上的 HTTP 報文，客戶端需要一種機制來准確判斷結束位置，而在 HTTP/1.0 中，這種機制只有 Content-Length 。而在 HTTP/1.1 中新增的 Transfer-Encoding: chunked 所對應的分塊傳輸機制可以完美解決這類問題。
nginx 同樣有著配置 chunked的 屬性 chunked_transfer_encoding ，這個屬性是默認開啟的。
Nginx 在啟用了 GZip 的情況下，不會等文件 GZip 完成再返回響應，而是邊壓縮邊響應，這樣可以顯著提高 TTFB ( Time To First Byte ，首位元組時間，WEB 性能優化重要指標)。這樣唯一的問題是， Nginx 開始返回響應時，它無法知道將要傳輸的文件最終有多大，也就是無法給出 Content-Length 這個響應頭部。
所以，在 HTTP1.0 中如果利用 Nginx 啟用了 GZip ，是無法獲得 Content-Length 的，這導致HTTP1.0中開啟持久鏈接和使用 GZip 只能二選一，所以在這里 gzip_http_version 默認設置為 1.1 。
如上面的圖，前面是眾多的服務窗口，下面有很多用戶需要服務，我們需要一個工具或策略來幫助我們將如此多的用戶分配到每個窗口，來達到資源的充分利用以及更少的排隊時間。
把前面的服務窗口想像成我們的後端伺服器，而後面終端的人則是無數個客戶端正在發起請求。負載均衡就是用來幫助我們將眾多的客戶端請求合理的分配到各個伺服器，以達到服務端資源的充分利用和更少的請求時間。
Upstream指定後端伺服器地址列表
在server中攔截響應請求，並將請求轉發到Upstream中配置的伺服器列表。
上面的配置只是指定了nginx需要轉發的服務端列表，並沒有指定分配策略。
輪詢策略
默認情況下採用的策略，將所有客戶端請求輪詢分配給服務端。這種策略是可以正常工作的，但是如果其中某一台伺服器壓力太大，出現延遲，會影響所有分配在這台伺服器下的用戶。
最小連接數策略
將請求優先分配給壓力較小的伺服器，它可以平衡每個隊列的長度，並避免向壓力大的伺服器添加更多的請求。
最快響應時間策略
依賴於NGINX Plus，優先分配給響應時間最短的伺服器。
客戶端ip綁定
來自同一個ip的請求永遠只分配一台伺服器，有效解決了動態網頁存在的session共享問題。
匹配以 png|gif|jpg|jpeg 為結尾的請求，並將請求轉發到本地路徑， root 中指定的路徑即nginx本地路徑。同時也可以進行一些緩存的設置。
nginx的功能非常強大，還有很多需要探索，上面的一些配置都是公司配置的真實應用（精簡過了），如果您有什麼意見或者建議，歡迎在下方留言...
⑺ 初識Nginx配置文件以及基本命令
配置文件名為 nginx.conf ，Linux放在目錄： /usr/local/nginx/conf 、 /etc/nginx , 或 /usr/local/etc/nginx 中；Windows放在 安裝目錄conf 中。 依據實際安裝情況決定
nginx由配置文件中指定的指令控制模塊組成。 指令分為 簡單指令 和 塊指令 ：
簡單指令 由空格分隔的名稱和參數組成，並以分號 ; 結尾；
塊指令 具有與簡單指令相同的結構，但是是以大括弧 { 和 } 包圍的一組附加指令。 如果塊指令在大括弧內部有其他指令，則稱為上下文(例如： events ， http ， server 和 location )；
配置文件中放置在任何上下文之外的偽指令都被認為是主上下文。 events 和 http 指令駐留在主上下文中， server 在 http 中的，而 location 在 server 塊中。一個配置文件一個 http ，一個及以上個 server ，一個 server 運行一個工作進程並代表一個虛擬伺服器；
# 號所在的一行被視為注釋；
幾個頂級指令將適用於不同流量類型的指令組合在一起：
對於大多數指令，在子上下文中定義的上下文將繼承父級中包含的偽指令的值，要覆蓋從父進程繼承的值，子上下文中需要包含該指令（即子上下文要顯式聲明）。
打開配置文件(如 /usr/local/nginx/conf/nginx.conf )，默認的配置文件已經包含了伺服器塊的幾個示例，大部分是注釋掉的。 現在注釋掉所有這樣的塊，並啟動一個新的伺服器塊：
每個 server 上下文都可以指定要監聽的埠、server_name，當nginx決定哪個伺服器處理請求後，它會根據伺服器塊內部定義的location指令的參數測試請求頭中指定的URI， 比如如下配置，系統中創建 /data 目錄及其子目錄 /www ：
第一個 location 塊指定與請求中的URI比較 / 前綴。 對於匹配請求，URI將被添加到 root 指令中指定的路徑(即 /data/www )，形成本地文件系統中的請求文件路徑。 如果有幾個匹配的location塊，nginx將選擇具有最長前綴來匹配location塊。 上面第一個 location 塊提供最短的前綴長度為1，因此只有當所有其他location塊不能提供匹配時，才會使用該塊。第二個 location ,將是以 /images/ 的請求來匹配，位置 / 也匹配這樣的請求，但具有較短前綴，也就是 /images/ 比 / 長。
這已經是一個在標准埠 80 上偵聽並且可以在本地機器上訪問的伺服器 http://localhost/ 的工作配置， 埠 80 和 server_name localhost 可以省略，它們為默認值 。 響應以/images/開頭的URI的請求，伺服器將從 /data/images 目錄發送文件。 例如，響應 http://localhost/images/logo.png 請求，nginx將發送服務上的 /data/images/logo.png 文件。 如果文件不存在，nginx將發送一個指示 404 錯誤的響應。 不以 /images/ 開頭的URI的請求將映射到 /data/www 目錄。 例如，響應 http://localhost/about/example.html 請求時，nginx將發送 /data/www/about/example.html 文件。
反向代理應該是Nginx做的最多的一件事了，反向代理(Reverse Proxy)方式是指以代理伺服器來接受internet上的連接請求，然後將請求轉發給內部網路上的伺服器，並將從伺服器上得到的結果返回給internet上請求連接的客戶端，此時代理伺服器對外就表現為一個反向代理伺服器。簡單來說就是真實的伺服器不能直接被外部網路訪問，所以需要一台代理伺服器，而代理伺服器能被外部網路訪問的同時又跟真實伺服器在同一個網路環境，當然也可能是同一台伺服器，埠不同而已。
通過向nginx配置文件添加一個server塊來定義代理伺服器，其中包含以下內容：
這將是一個監聽埠 8080 的簡單伺服器，並將所有請求映射到本地文件系統上的 /data/up1 目錄。 請注意，root指令位於server塊上下文中，當選擇用於服務請求的 location 塊不包含自己的 root 指令時，將使用此root指令。創建 /data/up1 目錄然後可以將一個靜態網頁比如 index.html 文件放入其中，然後訪問 http://localhost:8080/ 即可訪問該文件。
目前為止，還是配置的靜態資源訪問，並不是代理伺服器，然後增加或修改現有 location 上下文，改為如下：
當用戶訪問 http://localhost:8080/ 時，會返回 http://localhost:8181 伺服器的的資源。
location 上下文後面的參數，可以是正則表達式，如果是正則表達式，前面要加 ~ ，比如：
以上配置表示，nginx接收到所有以.gif，.jpg或.png結尾的URI，相應的請求將映射到/data/images目錄。當nginx選擇一個location塊來提供請求時，它首先檢查指定前綴的location指令，記住具有最長前綴的location，然後檢查正則表達式。 如果與正則表達式匹配，nginx會選擇此location，否則選擇之前記住的那一個。
要找到最符合URI的位置，NGINX首先將URI與前綴字元串的位置進行比較。然後用正則表達式搜索位置。除非使用^~修飾符對正則表達式給予更高的優先順序。在前綴字元串中，NGINX選擇最具體的字元串(也就是最長和最完整的字元串)。 下面給出了選擇處理請求的位置的確切邏輯：
測試所有URI的前綴字元串。 = (等號)修飾符定義了URI和前綴字元串完全匹配。如果找到完全匹配，則搜索停止。如果 ^~ (插入符號)修飾符預先添加最長匹配前綴字元串，則不會檢查正則表達式。存儲最長匹配的前綴字元串。根據正則表達式測試URI。斷開第一個匹配的正則表達式並使用相應的位置。如果沒有正則表達式匹配，則使用與存儲的前綴字元串相對應的位置。
= 修飾符的典型用例是 / (正斜杠)的請求。 如果請求/是頻繁的，則指定 = / 作為location指令的參數加速處理，因為搜索匹配在第一次比較之後停止。
要啟動nginx，請運行可執行文件。 當nginx啟動後，可以通過使用-s參數調用可執行文件來控制它。 使用以下語法：
信號(signal)的值可能是以下之一：
當主進程收到要重新載入配置的信號，它將檢查新配置文件的語法有效性，並嘗試應用其中提供的配置。 如果這是成功的，主進程將啟動新的工作進程，並向舊的工作進程發送消息，請求它們關閉。 否則，主進程回滾更改，並繼續使用舊配置。 老工作進程，接收關閉命令，停止接受新連接，並繼續維護當前請求，直到所有這些請求得到維護。 之後，舊的工作進程退出。
兩者在 location 中，指定一個路徑，其中使用 alias 做如下配置：
若按照上述配置的話，則訪問/img/目錄裡面的文件時，ningx會自動去/var/www/image/目錄找文件
若按照這種配置的話，則訪問/img/目錄下的文件時，nginx會去/var/www/image/img/目錄下找文件。alias是一個目錄別名的定義，root則是最上層目錄的定義，指的是 /var/www/image/img/ 。還有一個重要的區別是alias後面必須要 / 結束，否則會找不到文件，而root則可有可無。
另外對於index，含義如下
這樣，當用戶請求 / 地址時，Nginx 就會自動在 root 配置指令指定的文件系統目錄下依次尋找 index.htm 和 index.html 這兩個文件。如果 index.htm 文件存在，則直接發起「內部跳轉」到 /index.htm 這個新的地址；而如果 index.htm 文件不存在，則繼續檢查 index.html 是否存在。如果存在，同樣發起「內部跳轉」到 /index.html ；如果 index.html 文件仍然不存在，則放棄處理權給 content 階段的下一個模塊。
參考地址1
參考地址2:B站
⑻ nginx啟動，重啟，重新載入，以及前綴路徑設置
命令行里對nginx操作都需要運行nginx安裝目錄下的 sbin/nginx，默認會放在 /usr/local/openresty/nginx/sbin 目錄下，如果不是openresty里裝的nginx，應該就是沒有openresty這一層目錄的位置
這個路徑比較長，所以一般會把它配在環境變數里
之後就可以在任意目錄下直接使用nginx命令了，但是這種方法在關閉窗口後就沒有用了。
修改環境變數有多種方法，這里貼個別的博客的 鏈接 ，寫的比較詳細
我這里使用了修改/etc/profile的方法，修改後，重啟，對所有用戶都生效
但是一般來說，我們肯定是需要啟動我們自己編寫的nginx.conf，所以需要在啟動的時候指定nginx.conf的位置
這樣寫的話必須寫絕對路徑，寫相對路徑會被拼接到/usr/local/。。。的nginx默認路徑後面去，肯定就找不到nginx.conf了，就報錯了。同時在nginx.conf文件中的一些東西也必須寫絕對路徑，例如我寫個content_by_lua_file，後面的路徑也不能是相對路徑
這是因為沒有指定前綴路徑，就會使用默認的前綴路徑，導致所有相對路徑都出現問題，通過 -p指定路徑，這樣就可以愉快地寫相對路徑啦
修改了文件後，需要讓nginx載入這些修改了的信息，可以通過重啟nginx的方式，但是nginx也可以不重啟，直接重新載入這些內容
當然也可以查找nginx的進程號，再用kill 指令向它發送消息，實現讓它停止，重啟，重載入等等。