nginx載入配置文件

『壹』 Nginx相關知識點

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

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

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

自行安裝

正向代理: 代理伺服器站在客戶端那邊就是正向代理;
反向代理: 代理伺服器站在原始伺服器那邊就是反向代理;
詳解參考點擊 Nginx正向代理與反向代理

Nginx在做反向代理時，提供性能穩定，並且能夠提供配置靈活的轉發功能。
Nginx可以根據不同的正則匹配，採取不同的轉發策略，比如圖片文件結尾的走文件伺服器，動態頁面走web伺服器，只要你正則寫的沒問題，又有相對應的伺服器解決方案，你就可以隨心所欲的玩。
並且Nginx對返回結果進行錯誤頁跳轉，異常判斷等。如果被分發的伺服器存在異常，他可以將請求重新轉發給另外一台伺服器，然後自動去除異常伺服器。

如果你的nginx伺服器給2台web伺服器做代理，負載均衡演算法採用輪詢，那麼當你的一台機器web程序iis關閉，也就是說web不能訪問，那麼nginx伺服器分發請求還是會給這台不能訪問的web伺服器，如果這里的響應連接時間過長，就會導致客戶端的頁面一直在等待響應，對用戶來說體驗就打打折扣，這里我們怎麼避免這樣的情況發生呢。這里我配張圖來說明下問題。

如果負載均衡中其中web2發生這樣的情況，nginx首先會去web1請求，但是nginx在配置不當的情況下會繼續分發請求道web2，然後等待web2響應，直到我們的響應時間超時，才會把請求重新分發給web1，這里的響應時間如果過長，用戶等待的時間就會越長。

下面的配置是解決方案之一:

如果使用upstream指令配置了一組伺服器作為被代理伺服器，伺服器中的訪問演算法遵循配置的負載均衡規則，同時可以使用該指令配置在發生哪些異常情況時，將請求順次交由下一組伺服器處理。

狀態值可以是：error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off

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

Ip hash演算法，對客戶端請求的ip進行hash操作，然後根據hash結果將同一個客戶端ip的請求分發給同一台伺服器進行處理，可以解決session不共享的問題。

eg:

開啟簡單的緩存配置，只需要兩個指令：proxy_cache_path和proxy_cache。
proxy_cache_path: 配置緩存的存放地址和其他的一些常用配置;
proxy_cache:指令是為了啟動緩存;

相關配置說明:

該指令用於定義滿足條件的響應不會被保存到緩存中。在條件字元串中至少有一個條件不為空或者0，符合這樣條件的響應才不會被緩存。
舉例如下

其中，cookie_nocache、arg_nocache...皆為變數，可以根據你訪問的匹配策略來設置，其值只有2類，0和非0;

訪問匹配策略例如：

如果在此鏈式配置中，只要有一個值不為0，則不會cache；例如：

則不會被cache.

註：一般會配合proxy_cache_bypass共同使用；

該指令用於定義哪些情況不從cache讀取，直接從backend獲取資源；配置方式同proxy_no_cache。

給緩存數據定義一個鍵，例如

該指令用於設置緩存哪些HTTP方法,默認緩存HTTP GET/HEAD方法,不緩存HTTP POST 方法.。

設置不同響應碼的緩存時間，當不指定響應碼的時候，例如

只對響應碼為200，301，302的訪問請求資源設置緩存時間，此外可以個性化定製，例如：

此外，還可以在相應header里設置優先順序更高的緩存有效時間：

不緩存包含在field的響應header，可以設置的值有：「X-Accel-Redirect」, 「X-Accel-Expires」, 「X-Accel-Limit-Rate」，「X-Accel-Buffering」, 「X-Accel-Charset」, 「Expires」, 「Cache-Control」, 「Set-Cookie」 (0.8.44), and 「Vary」。
如果上述的header field沒有設置為忽略，則header filed中有「X-Accel-Expires」, 「Expires」, 「Cache-Control」, 「Set-Cookie」, and 「Vary」的話，響應會被緩存。

該指令用於設置緩存的最小使用次數,默認值為1

源站有問題時，nginx可以通過proxy_cache_use_stale指令開啟容錯能力，即使用緩存內容來響應客戶端的請求。舉例如下：

如上配置表示，當作為cache的NGINX收到源站返回error、timeout或者其他指定的5XX錯誤，並且在其緩存中有請求文件的陳舊版本，則會將這些陳舊版本的文件而不是錯誤信息發送給客戶端。

使用NGINX，不需要建立一個RAID（磁碟陣列）。如果有多個硬碟，NGINX可以用來在多個硬碟之間分割緩存。舉例如下：

在這份配置中，使用了3個獨立的緩存，每個緩存專用一塊硬碟，另外，3個獨立的線程池也各自專用一塊硬碟。

緩存之間（其結果就是磁碟之間）的負載均衡使用split_clients模塊，split_clients非常適用於這個任務。
在 proxy_cache_path指令中設置 use_temp_path=off ，表示NGINX會將臨時文件保存在緩存數據的同一目錄中。這是為了避免在更新緩存時，磁碟之間互相復制響應數據。

通過訪問日誌，你可以得到用戶地域來源、跳轉來源、使用終端、某個URL訪問量等相關信息；
通過錯誤日誌，你可以得到系統某個服務或server的性能瓶頸等。
因此，將日誌好好利用，你可以得到很多有價值的信息。

打開nginx.conf配置文件：vim /usr/local/nginx/conf/nginx.conf
日誌部分內容：
#access_log logs/access.log main;
日誌生成的到Nginx根目錄logs/access.log文件，默認使用「main」日誌格式，也可以自定義格式。
默認「main」日誌格式：

參數明細表：

查看日誌命令tail -f /usr/local/nginx/logs/access.log

打開nginx.conf配置文件去掉#注釋見下圖：

自定義某一個server配置的日誌，使用「main」日誌格式。

日誌生成的到Nginx根目錄logs/access.log文件，默認使用「main」日誌格式，也可以自定義格式。

重新讀取載入Nginx配置文件：

執行命令：nginx-s reload

網上一位老師寫的log文件分解的腳本

此腳本執行時間根據自己公司情況來定,可以設置默認一天執行一次;

創建crontab設置作業

設置日誌文件存放目錄crontab -e

*/1 * * * * sh /usr/local/software/nginx/nginx_log.sh
此設置的為一分鍾,如果設置一天自行修改;

默認的 nginx 配置文件 nginx.conf 內容如下

示例

幾個常見配置項：

注意:

驚群現象：一個網路連接到來，多個睡眠的進程被同事叫醒，但只有一個進程能獲得鏈接，這樣會影響系統性能
每個指令必須有分號結束。

進入安裝目錄下的sbin

『貳』 通過nginx將本地請求打到開發機上

現在的工作的由於環境的隔離，所以開發需要在開發機上進行開發。
本地調試時，如果希望將請求打到開發機上起的本地服務，在windows下可以通過fiddler來進行，但是在mac下由於不存在像fiddler般簡單易用的軟體，所以可以使用比如nginx來進行轉發。

配置起來需要如下幾部：

對於nginx來講，配置文件中關鍵的內容有以下幾點：

日誌中的內建變數
這篇文章介紹的比較詳細
Nginx的日誌配置參數詳解

轉發的規則
具體的轉發規則location我們就不贅述了，有很多文章介紹。

dns的問題
在我們的場景中，我們需要一個比較特殊的情況是：我們需要攔截某些請求到本地，而希望其他的請求繼續走原始的路徑。但是由於我們通過了配置hosts將域名打到了本地127.0.0.1，所以如果在proxy_pass中繼續配置 http://crm-off.work-int.com 的話，由於仍會走本機的host，所以仍然會打到本機的nginx上。所以我們需要繞過本機的host的配置。為了解決這個問題，我們需要了解下nginx對於域名的解析規則。nginx在載入配置文件的時候，會將host載入到上下文中，然後對於配置文件中的域名會進行解析。而如果我們不希望進行該解析，則需要通過內置變數來進行。比如$http_host。這就是我們在上面的配置文件中看到了：

的原因。
以上的討論，在文章 Nginx 教程二：利用nginx搭建靜態文件服務、正向代理伺服器、反向代理伺服器 也有討論，稱之為正向代理，與反向代理所區別。可以理解為一個為出，一個為入。
但是，單純的如此編輯後，仍然會存在問題，比如域名解析不出來等。此時我們需要配上域名解析器，也就是server模塊：

那麼有個問題就產生了，這個ip是如何產生的呢。

查找域名解析器
我們需要去查找我們的$http_host的dns伺服器域名。這時候nslookup就出場了。
使用nslookup查找域名：

於是我們便獲得了dns的伺服器。實際如果訪問的是公網的話，則直接填8.8.8.8，是Google提供的免費DNS伺服器的IP地址。

其中stop和quit的區別在於quit是一種較平滑的退出。

『叄』 nginx 網頁載入

在nginx的配置文件中的server中寫入以下內容
server {
server_name static.naice.me; // 你的域名或者 ip
root /www/static-web/static-web; // 你的克隆到的項目路徑
index index.html; // 顯示首頁
}

在遇到異常時使用 vi /var/log/nginx/error.log 命令查看錯誤原因

我遇到的原因是由於啟動用戶和nginx工作用戶不一致所致的
輸入命令 ps aux | grep "nginx: worker process" | awk '{print $1}' 查看用戶名
樣例輸出

可以發現用戶是www-data而非root
修改 nginx.conf 中的 user www-data; 為 user root; 就可以使用root用戶運行
輸入 nginx -s reload 重啟nginx服務即可

我遇到的情況是static文件路徑載入錯誤，在 nginx.conf 文件加入下面的語句即可修改static文件路徑

關於Nginx出現403 forbidden (13: Permission denied)報錯的更多原因

『肆』 初識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、安裝EPEL
Nginx 伺服器軟體安裝包在 EPEL 倉庫里，但不在CentOS 的 yum 包安裝源倉庫中，所以需要先添加 CentOS 7 EPEL 倉庫：

[root@Tracy src]# yum install -y epel-release
2、安裝Nginx
[root@Tracy src]# yum install -y nginx
3、驗證是否安裝成功
[root@Tracy src]# nginx -v
nginx version: nginx/1.20.1
出現版本號即安裝成功！

4、設置Nginx為系統服務
[root@Tracy src]# systemctl enable nginx
Created symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service.
5、啟動服務
[root@Tracy src]# service nginx start
Redirecting to /bin/systemctl start nginx.service
6、瀏覽器驗證
註：確認80端囗對外可訪問，設置可參考：CentOS7 開放端囗（使用iptables）_ling1998的博客-CSDN博客

在瀏覽器中輸入訪問地址，出現Ngnix默認頁面（註：我的是阿里雲伺服器，可能與你的默認頁面內容不一樣）



7、常用命令
nginx //打開nginx

nginx -h //顯示幫助

nginx -v //顯示版本號

nginx -t //檢測配置文件（nginx.conf）是否有語法錯誤

nginx -T //檢測配置文件（nginx.conf）並顯示出來

nginx -s start //啟動服務

nginx -s reopen //打開錯誤日誌

nginx -s reload //程序載入配置文件（nginx.conf），然後以優雅的方式重啟服務

nginx -s stop //強制停止服務

nginx -s quit //優雅的停止服務

設置Nginx為系統服務後，可以通過以下命令操作服務

service nginx start //啟動服務

service nginx stop //停止服務

service nginx restart //重啟服務

service nginx status //查看服務狀態

8、部署項目
（1）項目放在相應目錄中，記錄項目根目錄路徑
（2）編輯nginx配置文件
[root@Tracy src]# vi /etc/nginx/nginx.conf
修改服務配置中的root路徑為自己的項目根路徑

server {
listen 80; #修改web服務監聽端囗，默認為80
listen [::]:80;
server_name _; #服務名稱
root /home/project; #修改成自己的項目目錄

# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;

error_page 404 /404.html;
location = /404.html {
}

error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
按Esc退出編輯，輸入:wq保存退出

（3）瀏覽器訪問驗證
在瀏覽器中輸入訪問地址，發現已經改變



（4）反向代理及證書配置
配置證書，可以通過https訪問，需要開啟443端囗，前提條件是需要先有域名，然後做域名解析，然後進行配置nginx.conf

server {
listen 80;
listen [::]:80;
listen 443 ssl;
server_name _;
root /home/client-front/out;

# 配置證書
ssl_certificate /etc/nginx/cert/8538290.pem;
ssl_certificate_key /etc/nginx/cert/8538290.key;
ssl_session_timeout 5m;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;

# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;

location ^~ /api/v1 {
proxy_pass http://127.0.0.1:8090;
}

location ^~ /swagger {
proxy_pass http://127.0.0.1:8090;
}

error_page 404 /404.html;
location = /404.html {
}

error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
9、寶塔面板
（1）安裝
詳見官網：寶塔linux面板,一鍵安裝LAMP/LNMP/SSL/Tomcat

（2）配置反向代理
場景：前端訪問後端，如下圖所示：



（3）問題
如果配置完，在瀏覽器訪問時發現並沒有生效，查看下配置文件，有的時候通過上面設置的在配置文件中有可能不太一樣，我遇到的問題就是配置文件中proxy_pass後面多了一個/，但是上面設置時是沒有的

『陸』 nginx啟動之後打不開前端頁面

nginx啟動之後，打開前端頁面一直顯示403錯誤，打開錯誤日誌（ nginx -V中找到錯誤日誌路徑 ），發現是Permission denied錯誤，執行

，發現執行nginx的用戶為nobody，現在將執行nginx的用戶改為root。打開nginx.config，將裡面的user配置為

再執行

重新載入配置文件重新訪問。

『柒』 linux 上修改了nginx.conf 怎麼重新載入配置文件生效

步驟如下
先利用/usr/local/nginx/sbin/nginx -t測試配置文件修改是否正常
/usr/local/nginx/sbin/nginx -s reload重新載入

nginx 更改配置文件後需要重啟生效。
1、更改配置重啟nginx：
kill -HUP 主進程號或進程號文件路徑
或者使用
cd /usr/local/nginx/sbin
./nginx -s reload
2、判斷配置文件是否正確：
nginx -t -c /usr/local/nginx/conf/nginx.conf
或者
cd /usr/local/nginx/sbin
./nginx -t

『捌』 nginx 配置詳解是怎麼樣的

Nginx配置文件主要分為四部分：main（全局配置）、server（主機設置）、upstream（上游伺服器設置）和location(URL匹配特定位置後的設置）每部分包含若干個指令。

Nginx功能豐富，可作為HTTP伺服器，也可作為反向代理伺服器，郵件伺服器。支持FastCGI、SSL、Virtual Host、URL Rewrite、Gzip等功能。

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

nginx 配置注意事項

Nginx可以對不同的文件做不同的緩存處理，配置靈活，並且支持FastCGI_Cache，主要用於對FastCGI的動態程序進行緩存。配合著第三方的ngx_cache_purge，對制定的URL緩存內容可以的進行增刪管理。

events塊：配置影響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 啟動報錯 nginx: [emerg] getgrnam("root") failed

問題原因：是nginx許可權的問題

解決辦法：

1. 修改nginx配置文件nginx.conf，在配置文件其實位置增加 user root root; 並保存

2. 重新載入配置文件

./nginx -c /nginx.conf

3. 啟動服務，成功

如果本文章為你解決問題提供了幫助，請不要吝嗇為以後的分享熱情添一把柴