引用：https://baijiahao.baidu.com/s?id=1600687025749463237&wfr=spider&for=pc

參考下圖，正向代理用途：Client無法直接訪問Server，比如谷歌FQ，于是請求發送給代理，代理可以訪問Server并將其返回信息返回給Client。

反向代理用途：1.把Server的IP域名隱藏起來不直接暴露，Proxy充當跳板機/前置機的功能；2.對于大量的客戶端并發請求，進行分發給各個服務器，實現負載均衡。

反向代理TCP/UDP負載均衡配置和選擇：編輯nginx.conf文件

#進程數，一般一個進程就夠了
worker_processes  1;  events {  #單個進程最大連接數（最大連接數=連接數*進程數）worker_connections  1024;  
}  #TCP/UDP套接字固定字符串：stream
stream {#反向代理URL管理upstream myproxy {#源地址哈希法，就是對訪問客戶端的IP進行hash后的結果進行分配，這樣每一個客戶端固定請求同一個后端服務器。#ip_hash;    #按照服務器響應時間的長短來進行分發的，服務器響應時間越短的，優先分發。#fair

　　　　　#正常分發server 192.168.3.22:13333;server 192.168.3.22:13334;#權重，權重越大，連接數量越多，壓力越大。#server 11.22.333.44:5555 weight=2; #server 11.22.333.11:6666 weight=1; #表示當前的server臨時不參與負載。#server 11.22.333.22:8888 down; #其他全部的非backup機器down或者忙的時候，請求backup機器。所以這臺機器壓力會最輕。#server 11.22.333.33:8888 backup;}server {#region 統一監聽端口listen 13335; #連接超時時間proxy_connect_timeout 3s;#N秒內服務器沒有接收到數據自動斷開與客戶端的連接，如不想要此功能則注釋該行      #proxy_timeout 10s; #反向代理URLproxy_pass myproxy; }
}

?

打開cmd，輸入nginx -c nginx.conf，回車執行。

注意如果要關閉nginx，關了控制臺是沒用的，需要另外打開一個cmd窗口輸入nginx -s quit，回車執行。

一般只修改配置文件，不需要重啟或關閉nginx，執行?nginx -s reload?重新加載配置文件即可。

?

深入Nginx

附上原文鏈接：https://blog.csdn.net/wy757510722/article/details/75267431

?

nginx是以多進程的方式來工作的，當然nginx也是支持多線程的方式的,只是我們主流的方式還是多進程的方式，也是nginx的默認方式：

1.nginx、redis等每個單獨的進程都可以獨占資源，通常情況下每個服務器會開幾十個nginx、redis進程，這樣如果采用多線程的模式，各個線程能夠利用的資源就會受到一些限制，諸如：ulimit -n 命令展示的每個進程最多可以打開的文件數這樣的限制。

2.nginx中除了master需要跟worker通過管道進行通信，worker之間不需要通信，而且每個worker的功能都一樣，屬于常駐進程。在這種場景下多線程的優勢體現不出來，而且也可以避免多線程在編程時需要考慮資源訪問互斥、同步等問題帶來的編程復雜度的提升，以及可能帶來的調試困難。（這里的同步、互斥并非指線程間消息傳遞等操作）

3.nginx采用多進程的方式，既可以避免因某個線程故障導致整個服務不可用的問題，也可以實現配置熱加載，不停服升級版本。

?

多進程工作模式

1. nginx在啟動后，會有一個master進程和多個worker進程。master進程主要用來管理worker進程，包含：接收來自外界的信號(重新加載配置文件，重啟nginx命令等)，向各worker進程發送信號，監控 worker進程的運行狀態,當worker進程異常情況下退出后，會自動重新啟動新的worker進程。而基本的網絡事件，則是放在worker進程中來處理了 。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的 。一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其它進程的請求。 worker進程的個數是可以設置的，一般我們會設置與機器cpu核數一致，這里面的原因與nginx的進程模型以及事件處理模型是分不開的 。

2.Master接收到信號以后怎樣進行處理（./nginx -s reload ）?首先master進程在接到信號后，會先重新加載配置文件，然后再啟動新的進程，并向所有老的進程發送信號，告訴他們可以光榮退休了。新的進程在啟動后，就開始接收新的請求，而老的進程在收到來自?master的信號后，就不再接收新的請求，并且在當前進程中的所有未處理完的請求處理完成后，再退出 。

3. worker進程又是如何處理請求的呢？我們前面有提到，worker進程之間是平等的，每個進程，處理請求的機會也是一樣的。當我們提供80端口的http服務時，一個連接請求過來，每個進程都有可能處理這個連接，怎么做到的呢？首先，每個worker進程都是從master?進程fork(分配)過來，在master進程里面，先建立好需要listen的socket之后，然后再fork出多個worker進程，這樣每個worker進程都可以去accept這個socket(當然不是同一個socket，只是每個進程的這個socket會監控在同一個ip地址與端口，這個在網絡協議里面是允許的)。一般來說，當一個連接進來后，所有在accept在這個socket上面的進程，都會收到通知，而只有一個進程可以accept這個連接，其它的則accept失敗，這是所謂的驚群現象。當然，nginx也不會視而不見，所以nginx提供了一個accept_mutex這個東西，從名字上，我們可以看這是一個加在accept上的一把共享鎖。有了這把鎖之后，同一時刻，就只會有一個進程在accpet連接，這樣就不會有驚群問題了。accept_mutex是一個可控選項，我們可以顯示地關掉，默認是打開的。當一個worker進程在accept這個連接之后，就開始讀取請求，解析請求，處理請求，產生數據后，再返回給客戶端，最后才斷開連接，這樣一個完整的請求就是這樣的了。我們可以看到，一個請求，完全由worker進程來處理，而且只在一個worker進程中處理。

4.nginx采用這種進程模型有什么好處呢？采用獨立的進程，可以讓互相之間不會影響，一個進程退出后，其它進程還在工作，服務不會中斷，master進程則很快重新啟動新的worker進程。當然，worker進程的異常退出，肯定是程序有bug了，異常退出，會導致當前worker上的所有請求失敗，不過不會影響到所有請求，所以降低了風險。

5.有人可能要問了，nginx采用多worker的方式來處理請求，每個worker里面只有一個主線程，那能夠處理的并發數很有限啊，多少個worker就能處理多少個并發，何來高并發呢？非也，這就是nginx的高明之處，nginx采用了異步非阻塞的方式來處理請求，也就是說，nginx是可以同時處理成千上萬個請求的 。對于IIS服務器每個請求會獨占一個工作線程，當并發數上到幾千時，就同時有幾千的線程在處理請求了。這對操作系統來說，是個不小的挑戰，線程帶來的內存占用非常大，線程的上下文切換帶來的cpu開銷很大，自然性能就上不去了，而這些開銷完全是沒有意義的。我們之前說過，推薦設置worker的個數為cpu的核數，在這里就很容易理解了，更多的worker數，只會導致進程來競爭cpu資源了，從而帶來不必要的上下文切換。而且，nginx為了更好的利用多核特性，提供了cpu親緣性的綁定選項，我們可以將某一個進程綁定在某一個核上，這樣就不會因為進程的切換帶來cache的失效。

轉載于:https://www.cnblogs.com/lene-y/p/11089450.html

總結

以上是生活随笔為你收集整理的反向代理Nginx的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。