① 初識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 配置文件
參考資料1
參考資料2
參考資料3
主配置文件 /etc/nginx/nginx.conf 。
配置文件中的 path，既可以是絕對路徑也可以是相對路徑，相對路徑相對 /usr/share/nginx 目錄。
通過 default_server 參數，指定當前 server 為對應 IP:PORT 對的默認伺服器。當一個請求匹配到 IP:PORT，但是 Host 欄位不匹配任何一個 server_name，則應用默認伺服器 server。假設 http://www.lishiqing.com 請源輪仔求的 IP:PORT 為 192.168.100.104:80，但是沒有對應的 server_name 匹配 www.lishiqing.com ，則應用默認伺服器。
如果沒有一個 listen 指令具有 default_server 參數，則具有 IP:PORT 對的第一個 server 將是該 IP:PORT 對的默認伺服器。
以下配置忽略 server_name，所有指向 192.168.100.105 的域名都能應用該 server
以下配置訪問 lishiqing.com 應用默認 server，也就是第一個 server
參考資料
location 指令可以跟字元串，也可以跟正則表達式
location string_path {} 區分大小寫的字元串
location = string_path {} 嚴格匹配字元串
location ~ reg_path {} 區分大小寫的正則表達式
location ~* reg_path {} 不區分大小寫的正則表達式
http://lishiqing.com/shop/images/1.png 這個請求的 query 為 /shop/images/1.png 。
當 location 後面是字元串的時候，如果某個請求的 query 以該字元串開頭，則匹配該 location，比如 /shop/images/1.png 的請求匹配 location /shop {} ，也匹配 location / {} ，但是不匹配 location /blog 。
當 location 後面是正則表達式的時候，如果某個請求的 query 匹配該正則表達式，則匹配該 location，比如 /shop/images/1.png 的請求匹配 location ~ \.(jpg|jpeg|png)$ {} 。
如果某個 query 匹配多個字元串的 location，那麼應用匹配度最高的一個 location，與 location 的順序無關。比如 /shop/images/1.png 的請求匹配 location / {} 和 location /shop {} ，但是應用 location /shop {} 。
如果某個 query 匹配多個正則表達式的 location，那麼按照 location 的順序應用第一個匹配的 location。比如雹汪 /shop/images/1.png 的請求匹配 location ~ \.(jpg|jpeg|png)$ {} 和 location ~ .*/images/.* {} ，但是應用第一個匹配的 location ~ \.(jpg|jpeg|png)$ {} 。因為在 query 在檢查正則表達式的時候，遇見第一匹配的 location 就停止繼續查找了。
如果某個 query 既匹配某個字元串的 location，又匹配某個正則表達式的 location，那麼應用正則表達式的 location，與順序無關。比如 /shop/images/1.png 的請求匹配 location /shop {} 和 location ~ \.(jpg|jpeg|png)$ {} ，但是會應用 location ~ \.(jpg|jpeg|png)$ {} 。這是因為某個請求會先檢查跟著字元串的 location，不管是桐行否找到匹配的字元串 location，都會繼續按照順序查找跟著正則表達式 location，因此正則表達式的優先順序高於字元串。如果找到了匹配的正則表達式，則立即停止查找，應用該 location，如果沒找到匹配的正則表達式，則應用剛才找到的匹配度最高的字元串 location。
location = string_path {} 為嚴格匹配，query 必須與 string_path 完全一致才能匹配。如果 query 與某個 = string_path 匹配，則立即停止查找，應用該 location。意味著不會去查找正則表達式 location。比如 /shop/images/1.png 匹配 location = /shop/images/1.png {} ，不匹配 location = /shop {} 和 location = /shop/images 。一般用來設置 location = / {} 來匹配 / 的 query，因為 / 的 query 會很頻繁，因此將 location = / {} 放在第一條 location 可以提高匹配查詢的效率。
location ^~ string_path {} 這種字元串匹配的優先順序高於正則表達式，當某個 query 匹配該 location 的時候，不會繼續查找正則表達式的 location 了。比如 /shop/images/1.png 的 query 滿足 location ^~ /shop {} 和 location ~ \.(jpg|jpeg|png)$ {} ，但是會應用 location ^~ /shop {} 。
總結：
③ 不容錯過的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配置文件詳解
說到該指令 ，首先得闡述一下什麼是所謂的 「驚群問題」，可以參考 WIKI網路的解釋。就Nginx的場景來解釋的話大致的意思就是：當一個新網路連接來到時，多個worker進程會被同時喚醒，但僅僅只有一個進程可以真正獲得連接並處理之。如果每次喚醒的進程數目過多的話，其實是會影響一部分性能的。
所以在這里，如果accept_mutex on，那麼多個worker將是以串列方式來處理，其中有一個worker會被喚醒；反之若accept_mutex off，那麼所有的worker都會被喚醒，不過只有一個worker能獲取新連接，其它的worker會重新進入休眠狀態。
用rewrite轉發的話，url會發生變化的，那就用proxy_pass吧，於是添加了如下的配置：
在現有環境的nginx里添加這段配置之後，訪問卻始終轉不過去，查看nginx日誌也只能看到是404信息，並沒有更多定位問題的信息。檢查了許久也沒找到原因，於是重新裝了一台新nginx，裡面只加上面這段配置，結果nginx是能夠轉發成功的，這說明單獨來看這條location的配置是沒有問題的，很有可能是現有環境nginx里的某些配置影響到了這個轉發。
為了定位問題原因，我將aaa.example.com虛擬主機下的其他配置注意注釋掉來調試，最後發現當注釋掉proxy_set_header Host $http_host ;這條配置之後，就能成功轉發了。這才注意到是反向代理配置的問題。現有環境中原有的配置也不能隨便刪掉，上網查了下原因，找到下面這種解決方案：
即，在location裡面添加一條proxy_set_header Host http_host時，則不改變請求頭的值，所以當要轉發到bbb.example.com的時候，請求頭還是aaa.example.com的Host信息，就會有問題；當Host設置為$proxy_host時，則會重新設置請求頭為bbb.example.com的Host信息。
另外，關於proxy_pass轉發url的參數，可以通過在location中用rewrite來做，所以完善後的配置如下：
在location用rewrite改變了URI之後，proxy_pass將使用改變後的URI。上面例子(.*)是將所有參數傳給 1會拼接在 http://bbb.example.com 後面。
先來看下proxy_set_header的語法
允許重新定義或者添加發往後端伺服器的請求頭。value可以包含文本、變數或者它們的組合。 當且僅當當前配置級別中沒有定義proxy_set_header指令時，會從上面的級別繼承配置。 默認情況下，只有兩個請求頭會被重新定義：
當匹配到/customer/straightcustomer/download時，使用crmtest處理，到upstream就匹配到crmtest.aty.sohuno.com，這里直接轉換成IP進行轉發了。假如crmtest.aty.sohuno.com是在另一台nginx下配置的，ip為10.22.10.116，則$proxy_host則對應為10.22.10.116。此時相當於設置了Host為10.22.10.116。如果想讓Host是crmtest.aty.sohuno.com，則進行如下設置：
如果不想改變請求頭「Host」的值，可以這樣來設置：
但是，如果客戶端請求頭中沒有攜帶這個頭部，那麼傳遞到後端伺服器的請求也不含這個頭部。 這種情況下，更好的方式是使用$host變數——它的值在請求包含「Host」請求頭時為「Host」欄位的值，在請求未攜帶「Host」請求頭時為虛擬主機的主域名：
此外，伺服器名可以和後端伺服器的埠一起傳送：
如果某個請求頭的值為空，那麼這個請求頭將不會傳送給後端伺服器：
nginx配置項，裡面的配置項有代理https，http，代理靜態文件，H5分發，代理TCP連接，能滿足大多數搭建測試環境所要用的nginx的情況，大家碰到要使用nginx的時候可以參考下
⑤ nginx不放在html文件夾,怎麼配置
1、修改配置文件，判斷卜念是否用域名訪問。
2、修改配置文件，配置2個server，一個配置域名，一寬弊頃個處理不使用域名時的結果。
3、瀏覽器或者系統訪問網頁都會有自己的一套緩存慎陸機制，這樣nginx就可以不放在html文件夾里了。
⑥ 5，nginx 多域名，配置多個conf 文件
nginx下配置多域名，目前的配置方法採用多個配置文件的方法比較多
1，在nginx安裝的目錄下找到， nginx.conf文件
如我的： C:\Program Files\nginx-1.15.5\conf 目錄下
2，在該目錄下創建的文件夾，如 vhost 文件夾
C:\Program Files\nginx-1.15.5\conf\vhost
3，在vhost 文件夾下創建 *.conf 文件 如host.conf
C:\Program Files\nginx-1.15.5\conf\vhost\host.conf
4,編輯conf文件，把我們平常放在nginx.conf里的server{......}段直接粘貼到conf里。
如：
5,最後在nginx.conf的http{....}段中加入
include vhost/*.conf;
6,如果有其他的conf文件要添加直接在 按照步驟三操作即可
⑦ [後端]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 conf.d目錄下的文件怎麼配置
（1）定義環境變數
語法：env VAR|VAR=VALUE
這個配置項可以讓用戶直接設置操作系統上的環境變數。例如：
1. env TESTPATH=/tmp/;
（2）嵌入其他配置文件
語法：include /path/file;
include配置項可以將其他配置文件嵌入到當前的nginx.conf文件中，它的參數既可以是絕對路徑，也可以是相對路徑（相對於Nginx的配置目錄，即nginx.conf所在的目錄），例如：
1. include mime.types;
2. include vhost/*.conf;
可以看到，參數的值可以是一個明確的文件名，也可以是含有通配符*的文件名，同時可以一次嵌入多個配置文件。
（3）pid文件的路徑
語法：pid path/file;
默認：pid logs/nginx.pid;
保存master進程ID的pid文件存放路徑。默認與configure執行時的參數「--pid-path」所指定的路徑是相同的，也可以隨時修改，但應確保Nginx有權在相應的目標中創建pid文件，該文件直接影響Nginx是否可以運行。
（4）Nginx worker進程運行的用戶及用戶組
語法：user username [groupname];
默認：user nobody nobody;
user用於設置master進程啟動後，fork出的worker進程運行在哪個用戶和用戶組下。當按照「user username;」設置時，用戶組名與用戶名相同。
若用戶在configure命令執行時使用了參數--user=username和--group=groupname，此時nginx.conf將使用參數中指定的用戶和用戶組。
（5）指定Nginx worker進程可以打開的最大句柄描述符個數
語法：worker_rlimit_nofile limit;
設置一個worker進程可以打開的最大文件句柄數。
（6）限制信號隊列
語法：worker_rlimit_sigpending limit;
設置每個用戶發往Nginx的信號隊列的大小。也就是說，當某個用戶的信號隊列滿了，這個用戶再發送的信號量會被丟掉。