nginx檢測配置文件

『壹』 nginx在做負載均衡時如何配置

1、下面的架構就是我們今天的演示結構，後端有兩台伺服器，分別是node1和node2，前端是一台web伺服器，然後在web伺服器上做負載均衡，將前端的訪問流量導到後端的兩個節點伺服器上。三個伺服器的IP地址分別是：web：192.168.1.210node1：192.168.1.211node2：192.168.1.212
2、按照這樣的架構，在後端的node1和node2節點上分配配置好需要訪問的網站，然後為了方便測試，我們將兩個網站的主頁分別改成下面的內容。便於區分訪問的節點。
3、後端兩個節點配置好以後，我們再來配置web伺服器里的負載均衡配置，首先使用默認配置，先打開/etc/nginx/nginx.conf配置文件，在http區塊里添加upstream塊內容，及配置了兩個後端伺服器，後端負載均衡集群的名稱是backend，記下這個名稱。
4、然後再打開/etc/nginx/conf.d/default.conf這個配置文件，在server區塊里，把location裡面的內容改成圖中所示內容。即將所有訪問192.168.1.210的流量代理到後端的backend集群里。
5、配置文件配置好以後，使用nginx-t命令測試一下配置文件，保證配置文件是ok狀態，然後執行nginx命令啟動nginx伺服器。
6、啟動後在瀏覽器上輸入前端web伺服器的ip地址192.168.1.210，然後可以看到第一次是node1響應的，然後刷新一下以後，又變成了node2響應的。就這樣實現了負載均衡的效果。由兩個伺服器分別響應，是因為默認的負載均衡演算法是輪詢演算法，即兩個節點輪流來。
7、然後我們還可以嘗試一下加權輪詢演算法，即給不同的節點配置不同的權重，權重高一點的伺服器，響應的多一些，權重第一點的響應少一些。加權輪詢演算法配置，在後端伺服器後面加上權重值weight即可。配置好以後，執行nginx-t命令檢測配置文件，確認無誤後，執行nginx-sreload命令重新載入配置文件。
8、通過加權輪詢的方式，我們無法通過手動一次次點擊，最後來統計次數。但是我們可以使用自動化工具來統計。使用的工具是一款叫做httpd-tools的軟體，安裝好以後，提供了一個ab命令
9、然後我們來執行ab命令進行測試，常用的格式是：ab-n1000-c50http://localhost這個命令是在210伺服器上執行的。表示一共執行1000次訪問，每次發送50個請求。
10、然後我們登錄到後端的node1伺服器上，打開nginx的訪問日誌，從中可以看到ab命令測試的訪問信息里，訪問來源都是ApacheBench，因此可以通過可以來源來統計nginx響應的次數。命令是：grepApacheBenchaccess.log|wcnode1和node2節點上的統計結果分別是714和286，如下面圖中所示，雖然沒有達到5:2的權重比例，但是也非常接近了。說明這個配置生效了。

『貳』 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的時候可以參考下

『叄』 windows下nginx怎麼檢查配置文件

從今開始，學nginx #安裝pcre [root@svr3 ~]# tar -xjf pcre-8 10/ Opera/9.80 (Windows NT 5.1; U; zh-cn) Presto/2.9.168 Version/11.50 ===>如何啟動nginx? <假定nginx安裝在/usr/local/nginx中> 方法1、執行/usr/local/nginx/sbin/nginx -t 檢查配置文件是否有誤！或是直接執行/usr/local/nginx/sbin/nginx 如果有多個配置文件可以使用指定的配置文件啟動： #/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf ===> nginx的信號控制： TERM,INT 快速關閉 QUIT 從容關閉 HUP 重啟，重新載入配置文件 USR1 重啟打開日誌，在切割日誌時用途大 USR2 平滑升級可執行程序 WINCH 從容關閉進程 本文出自 潛入技術的海洋 博客

『肆』 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 如何檢測配置文件的正確性

用參數-t
nginx -t
如果返回ok,用 -s reload 重新載入配置文件

『陸』 nginx 配置詳解是什麼

Nginx配置文件詳解：

Nginx的主配置文件是nginx.conf，這個配置文件一共由三部分組成，分別為全局塊、events塊和http塊。在http塊中，又包含http全局塊、多個server塊。

每個server塊中，可以包含server全局塊和多個location塊。在同一配置塊中嵌套的配置塊，各個之間不存在次序關系。

配置文件支持大量可配置的指令，絕大多數指令不是特定屬於某一個塊的。同一個指令放在不同層級的塊中，其作用域也不同，一般情況下，高一級塊中的指令可以作用於自身所在的塊和此塊包含的所有低層級塊。

如果某個指令在兩個不同層級的塊中同時出現，則採用「就近原則」，即以較低層級塊中的配置為准。比如，某指令同時出現在http全局塊中和server塊中，並且配置不同，則應該以server塊中的配置為准。

全局塊：

全局塊是默認配置文件從開始到events塊之間的一部分內容，主要設置一些影響Nginx伺服器整體運行的配置指令，因此，這些指令的作用域是Nginx伺服器全局。

通常包括配置運行Nginx伺服器的用戶（組）、允許生成的worker process數、Nginx進程PID存放路徑、日誌的存放路徑和類型以及配置文件引入等。

『柒』 nginx配置解讀

Nginx是俄羅斯人Igor Sysoev(塞索耶夫)編寫的一款高性能的 HTTP 和反向代理伺服器。也是一個IMAP/POP3/SMTP代理伺服器，也就是說，Nginx本身就可以託管網站，進行HTTP服務處理，也可以作為反向代理伺服器使用。

Nginx功能豐富，可作為HTTP伺服器，也可作為反向代理伺服器，郵件伺服器。支持FastCGI、SSL、Virtual Host、URL Rewrite、Gzip等功能。並且支持很多第三方的模塊擴展。

總之，非常牛的一款反向代理服務，牛逼吹的差不多啦，下面進入正題[得意]

Nginx配置文件nginx.conf詳解

『捌』 如何驗證Nginx配置文件是否准確

檢測nginx配置文件是否正確

/usr/local/nginx/sbin/nginx -t -c nginx.conf  
-c 配置文件路徑  
-g Set global directives. (version >=0.7.4)  
-t 檢測文件是否正確不執行  
-v Print version.  
-V Print nginx version, compiler version and configure 
parameters. 
編譯時如果使用了–with-debug編譯,還可以使用error_log file [ debug_core| debug_http | debug_event …] 來獲得debug信息

通過信號對 Nginx配置文件 進行控制

『玖』 nginx 配置詳解是什麼

Nginx是lgor Sysoev為俄羅斯訪問量第二的rambler.ru站點設計開發的。從2004年發布至今，憑借開源的力量，已經接近成熟與完善。

Nginx功能豐富，可作為HTTP伺服器，也可作為反向代理伺服器，郵件伺服器。支持FastCGI、SSL、Virtual Host、URL Rewrite、Gzip等功能。並且支持很多第三方的模塊擴展。

Nginx的穩定性、功能集、示例配置文件和低系統資源的消耗讓他後來居上，在全球活躍的網站中有12.18%的使用比率，大約為2220萬個網站。

1、全局塊：配置影響nginx全局的指令。一般有運行nginx伺服器的用戶組，nginx進程pid存放路徑，日誌存放路徑，配置文件引入，允許生成worker process數等。

2、events塊：配置影響nginx伺服器或與用戶的網路連接。有每個進程的最大連接數，選取哪種事件驅動模型處理連接請求，是否允許同時接受多個網路連接，開啟多個網路連接序列化等。

3、http塊：可以嵌套多個server，配置代理，緩存，日誌定義等絕大多數功能和第三方模塊的配置。如文件引入，mime-type定義，日誌自定義，是否使用sendfile傳輸文件，連接超時時間，單連接請求數等。

4、server塊：配置虛擬主機的相關參數，一個http中可以有多個server。

5、location塊：配置請求的路由，以及各種頁面的處理情況。

Nginx常用功能。

1、Http代理，反向代理：作為web伺服器最常用的功能之一，尤其是反向代理。

Nginx在做反向代理時，提供性能穩定，並且能夠提供配置靈活的轉發功能。Nginx可以根據不同的正則匹配，採取不同的轉發策略，比如圖片文件結尾的走文件伺服器，動態頁面走web伺服器，只要你正則寫的沒問題，又有相對應的伺服器解決方案。

。並且Nginx對返回結果進行錯誤頁跳轉，異常判斷等。如果被分發的伺服器存在異常，他可以將請求重新轉發給另外一台伺服器，然後自動去除異常伺服器。

2、負載均衡

Nginx提供的負載均衡策略有2種：內置策略和擴展策略。內置策略為輪詢，加權輪詢，Ip hash。擴展策略，就天馬行空，只有你想不到的沒有他做不到的啦，你可以參照所有的負載均衡演算法，給他一一找出來做下實現。

『拾』 初識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站