Nginx反向代理快取伺服器搭建
Nginx反向代理
代理服務可簡單的分為正向代理和反向代理:
正向代理: 用於代理內部網路對Internet的連線請求(如×××/NAT),客戶端指定代理伺服器,並將本來要直接傳送給目標Web伺服器的HTTP請求先發送到代理伺服器上, 然後由代理伺服器去訪問Web伺服器,並將Web伺服器的Response回傳給客戶端:
反向代理: 與正向代理相反,如果區域網向Internet提供資源,並讓Internet上的其他使用者可以訪問區域網內資源, 也可以設定一個代理伺服器, 它提供的服務就是反向代理. 反向代理伺服器接受來自Internet的連線,然後將請求轉發給內部網路上的伺服器,並將Response回傳給Internet上請求連線的客戶端:
一、nginx反向代理：Web伺服器的排程器
1、反向代理（ReverseProxy）方式是指以代理伺服器來接受客戶端的連線請求，然後將請求轉發給網路上的web伺服器（可能是apache、nginx、tomcat、iis等），並將從web伺服器上得到的結果返回給請求連線的客戶端，此時代理伺服器對外就表現為一個伺服器。
從上圖可以看出：反向代理伺服器代理網站Web伺服器接收Http請求，對請求進行轉發。而且nginx作為反向代理伺服器可以根據使用者請求的內容把請求轉發給後端不同的web伺服器，例如靜動分離，再例如在nginx上建立多個虛擬主機，這樣就成功的做到了在瀏覽器中輸入不同域名（url）的時候訪問後端的不同web伺服器或web群集。
2、反向代理的作用
①保護網站安全：任何來自Internet的請求都必須先經過代理伺服器；
②通過配置快取功能加速Web請求：可以快取真實Web伺服器上的某些靜態資源，減輕真實Web伺服器的負載壓力；
③實現負載均衡：充當負載均衡伺服器均衡地分發請求，平衡叢集中各個伺服器的負載壓力；
二、什麼是nginx
1、nginx簡介
Nginx是一款輕量級的網頁伺服器、反向代理器以及電子郵件代理伺服器。因它的穩定性、豐富的功能集、示例配置檔案和低系統資源的消耗而聞名。Nginx（發音同engine x），它是由俄羅斯程式設計師Igor Sysoev所開發的。起初是供俄國大型的入口網站及搜尋引擎Rambler（俄語：Рамблер）使用。此軟體BSD-like協議下發行，可以在UNIX、GNU/Linux、BSD、Mac OSX、Solaris，以及Microsoft Windows等作業系統中執行。
Nginx的應用現狀
Nginx 已經在俄羅斯最大的入口網站──Rambler Media（www.rambler.ru）上執行，同時俄羅斯超過20%的虛擬主機平臺採用 Nginx作為反向代理伺服器。
在國內，已經有淘寶、新浪部落格、新浪播客、網易新聞、六間房、56.com、Discuz!、水木社群、豆瓣、YUPOO、海內、迅雷線上等多家網站使用 Nginx 作為Web伺服器或反向代理伺服器。
2、Nginx的核心特點
（1）跨平臺：Nginx 可以在大多數OS編譯執行，而且也有Windows的版本；
（2）配置異常簡單：非常容易上手。
（3）非阻塞、高併發連線：官方測試能夠支撐5萬併發連線，在實際生產環境中跑到2～3萬併發連線數。（這得益於Nginx使用了最新的epoll模型）；
注：
對於一個Web伺服器來說，首先看一個請求的基本過程：建立連線—接收資料—傳送資料，在系統底層看來：上述過程（建立連線—接收資料—傳送資料）在系統底層就是讀寫事件。
如果採用阻塞呼叫的方式，當讀寫事件沒有準備好時，那麼就只能等待，當前執行緒被掛起，等事件準備好了，才能進行讀寫事件。
如果採用非阻塞呼叫的方式：事件馬上返回，告訴你事件還沒準備好呢，過會再來吧。過一會，再來檢查一下事件，直到事件準備好了為止，在這期間，你就可以先去做其它事情，然後再來看看事件好了沒。雖然不阻塞了，但你得不時地過來檢查一下事件的狀態，你可以做更多的事情了，但帶來的開銷也是不小的。非阻塞呼叫指在不能立刻得到結果之前，該呼叫不會阻塞當前執行緒
（4）事件驅動：通訊機制採用epoll模型，支援更大的併發連線。
非阻塞通過不斷檢查事件的狀態來判斷是否進行讀寫操作，這樣帶來的開銷很大，因此就有了非同步非阻塞的事件處理機制。這種機制讓你可以同時監控多個事件，呼叫他們是非阻塞的，但可以設定超時時間，在超時時間之內，如果有事件準備好了，就返回。這種機制解決了上面阻塞呼叫與非阻塞呼叫的兩個問題。
以epoll模型為例：當事件沒有準備好時，就放入epoll(佇列)裡面。如果有事件準備好了，那麼就去處理；當事件沒有準備好時，才在epoll裡面等著。這樣，我們就可以併發處理大量的併發了，當然，這裡的併發請求，是指未處理完的請求。執行緒只有一個，所以同時能處理的請求當然只有一個了，只是在請求之間進行不斷地切換而已，切換也是因為非同步事件未準備好，而主動讓出的。這裡的切換是沒有任何代價，你可以理解為迴圈處理多個準備好的事件。
多執行緒方式相比，這種事件處理方式是有很大的優勢的，不需要建立執行緒，每個請求佔用的記憶體也很少，沒有上下文切換，事件處理非常的輕量級，併發數再多也不會導致無謂的資源浪費（上下文切換）。對於apache伺服器，每個請求會獨佔一個工作執行緒，當併發數上到幾千時，就同時有幾千的執行緒在處理請求了。這對作業系統來說，是個不小的挑戰：因為執行緒帶來的記憶體佔用非常大，執行緒的上下文切換帶來的cpu開銷很大，自然效能就上不去，從而導致在高併發場景下效能下降嚴重。
總結：通過非同步非阻塞的事件處理機制，Nginx實現由程序迴圈處理多個準備好的事件，從而實現高併發和輕量級。
（5）Master/Worker結構：一個master程序，生成一個或多個worker程序。
注：Master-Worker設計模式主要包含兩個主要元件Master和Worker，Master維護著Worker佇列，將請求下發到多個Worker並行執行，Worker主要進行實際邏輯計算，並將結果返回給Master。
nginx採用這種程序模型有什麼好處？採用獨立的程序，可以讓互相之間不會影響，一個程序退出後，其它程序還在工作，服務不會中斷，Master 程序則很快重新啟動新的Worker程序。當然，Worker程序的異常退出，肯定是程式有bug了，異常退出，會導致當前Worker上的所有請求失敗，不過不會影響到所有請求，所以降低了風險。
（6）記憶體消耗小：處理大併發的請求記憶體消耗非常小。在3萬併發連線下，開啟的10個Nginx 程序才消耗150M記憶體（15M*10=150M）。
（7）內建的健康檢查功能：如果Nginx 代理的後端的某臺 Web 伺服器宕機了，不會影響前端訪問。
（8）節省頻寬：支援 GZIP 壓縮，可以新增瀏覽器本地快取的 Header 頭。
（9）穩定性高：用於反向代理，宕機的概率微乎其微。
三、Nginx+apache構築Web伺服器叢集的負載均衡
配置nginx作為反向代理和負載均衡，同時利用其快取功能，將靜態頁面在nginx快取，以達到降低後端伺服器連線數的目的並檢查後端web伺服器的健康狀況。
1、安裝nginx
環境：
OS:centos7.2
nginx：192.168.31.83
apache1:192.168.31.141
apache2:192.168.31.250
安裝zlib-devel、pcre-devel等依賴包
yum -y installgccgcc-c++ make libtoolzlibzlib-develpcrepcre-developensslopenssl-devel
注：
結合proxy和upstream模組實現後端web負載均衡
使用proxy模組實現靜態檔案快取
結合nginx預設自帶的ngx_http_proxy_module模組和ngx_http_upstream_module模組實現後端伺服器的健康檢查，也可以使用第三方模組nginx_upstream_check_module
使用nginx-sticky-module擴充套件模組實現Cookie會話黏貼（保持會話）
使用ngx_cache_purge實現更強大的快取清除功能
上面提到的2個模組都屬於第三方擴充套件模組，需要提前下好原始碼，然後編譯時通過--add-moudle=src_path一起安裝。
安裝nginx
groupadd www #新增www組
useradd -g wwwwww -s /sbin/nologin #建立nginx執行賬戶www並加入到www組，不允許www使用者直接登入系統
tar zxf nginx-1.10.2.tar.gz
tar zxfngx_cache_purge-2.3.tar.gz
tar zxf master.tar.gz
cd nginx-1.10.2/
./configure--prefix=/usr/local/nginx1.10 --user=www --group=www--with-http_stub_status_module --with-http_realip_module --with-http_ssl_module--with-http_gzip_static_module--http-client-body-temp-path=/var/tmp/nginx/client--http-proxy-temp-path=/var/tmp/nginx/proxy--http-fastcgi-temp-path=/var/tmp/nginx/fcgi --with-pcre--add-module=../ngx_cache_purge-2.3 --with-http_flv_module--add-module=../nginx-goodies-nginx-sticky-module-ng-08a395c66e42
make&& make install
注：nginx的所有模組必須在編譯的時候新增，不能再執行的時候動態載入。
優化nginx程式的執行路徑
[[email protected] nginx-1.10.2]# ln-s /usr/local/nginx1.10/sbin/nginx /usr/local/sbin/
[[email protected] nginx-1.10.2]#nginx -t
[[email protected] nginx-1.10.2]#mkdir -p /var/tmp/nginx/client
[[email protected] nginx-1.10.2]#chown -R www:www /var/tmp/nginx/
[[email protected] nginx-1.10.2]#nginx -t
nginx: the configurationfile /usr/local/nginx1.10/conf/nginx.conf syntax is ok
nginx: configuration file/usr/local/nginx1.10/conf/nginx.conf test is successful
2、編寫nginx服務指令碼（詳見附件）
[[email protected] ~]# chmod +x/etc/init.d/nginx
[[email protected] ~]# chkconfig--add nginx
[[email protected] ~]# chkconfignginxon
[[email protected] ~]# service nginx start
Nginx service start success.
[[email protected] ~]# service nginx status
Nginx service is running.
[[email protected] ~]# netstat -anpt| grep nginx
tcp 00 0.0.0.0:800.0.0.0:* LISTEN 3977/nginx: master
[[email protected] ~]# firewall-cmd--permanent --add-port=80/tcp
success
[[email protected] ~]# firewall-cmd--reload
Success
注：如果你想在已安裝好的nginx上新增第三方模組，依然需要重新編譯，但為了不覆蓋你原有的配置，請不要make install，而是直接拷貝可執行檔案：
# nginx–V
[[email protected]]#./configure--add-module=…… #你的第三方模組
[[email protected]] #make後不要make install,改為手動拷貝，先備份
[[email protected] nginx-1.10.2] #cp/usr/local/nginx1.10/sbin/nginx /usr/local/nginx1.10/sbin/nginx.bak
[[email protected] nginx-1.10.2] #cpobjs/nginx/usr/local/nginx1.10/sbin/nginx
配置nginx反向代理：反向代理+負載均衡+健康探測
檢視nginx載入的模組
[[email protected] ~]## nginx -V
nginx version: nginx/1.10.2
built by gcc 4.8.5 20150623(Red Hat 4.8.5-4) (GCC)
built with OpenSSL1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments:--prefix=/usr/local/nginx1.10 --user=www --group=www--with-http_stub_status_module --with-http_realip_module --with-http_ssl_module--with-http_gzip_static_module --http-client-body-temp-path=/var/tmp/nginx/client--http-proxy-temp-path=/var/tmp/nginx/proxy--http-fastcgi-temp-path=/var/tmp/nginx/fcgi --with-pcre--add-module=../ngx_cache_purge-2.3 --with-http_flv_module--add-module=../nginx-goodies-nginx-sticky-module-ng-08a395c66e42
nginx的所有模組必須在編譯的時候新增，不能再執行的時候動態載入。
3、nginx-sticky-module模組：
這個模組的作用是通過cookie黏貼的方式將來自同一個客戶端（瀏覽器）的請求傳送到同一個後端伺服器上處理，這樣一定程度上可以解決多個backend servers的session同步的問題 —— 因為不再需要同步，而RR輪詢模式必須要運維人員自己考慮session同步的實現。
另外內建的ip_hash也可以實現根據客戶端IP來分發請求，但它很容易造成負載不均衡的情況，而如果nginx前面有CDN網路或者來自同一區域網的訪問，它接收的客戶端IP是一樣的，容易造成負載不均衡現象。nginx-sticky-module的cookie過期時間，預設瀏覽器關閉就過期。
這個模組並不合適不支援 Cookie 或手動禁用了cookie的瀏覽器，此時預設sticky就會切換成RR。它不能與ip_hash同時使用。
upstream backend {
server 192.168.31.141:80weight=1;
server 192.168.31.250:80weight=1;
sticky;
}
配置起來超級簡單，一般來說一個sticky指令就夠了。
相關資訊可以檢視官方文件https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng
4、load-balance其它排程方案：
這裡順帶介紹一下nginx的負載均衡模組支援的其它排程演算法：
輪詢（預設）：每個請求按時間順序逐一分配到不同的後端伺服器，如果後端某臺伺服器宕機，故障系統被自動剔除，使使用者訪問不受影響。Weight 指定輪詢權值，Weight值越大，分配到的訪問機率越高，主要用於後端每個伺服器效能不均的情況下。
ip_hash：每個請求按訪問IP的hash結果分配，這樣來自同一個IP的訪客固定訪問一個後端伺服器，有效解決了動態網頁存在的session共享問題。當然如果這個節點不可用了，會發到下個節點，而此時沒有session同步的話就登出掉了。
least_conn：請求被髮送到當前活躍連線最少的realserver上。會考慮weight的值。
url_hash：此方法按訪問url的hash結果來分配請求，使每個url定向到同一個後端伺服器，可以進一步提高後端快取伺服器的效率。Nginx本身是不支援url_hash的，如果需要使用這種排程演算法，必須安裝Nginx 的hash軟體包nginx_upstream_hash。
fair：這是比上面兩個更加智慧的負載均衡演算法。此種演算法可以依據頁面大小和載入時間長短智慧地進行負載均衡，也就是根據後端伺服器的響應時間來分配請求，響應時間短的優先分配。Nginx本身是不支援fair的，如果需要使用這種排程演算法，必須下載Nginx的upstream_fair模組。
5、負載均衡與健康檢查：
嚴格來說，nginx自帶是沒有針對負載均衡後端節點的健康檢查的，但是可以通過預設自帶的ngx_http_proxy_module模組和ngx_http_upstream_module模組中的相關指令來完成當後端節點出現故障時，自動切換到下一個節點來提供訪問。
upstream backend {
sticky;
server 192.168.31.141:80 weight=1 max_fails=2fail_timeout=10s;
server 192.168.31.250:80 weight=1 max_fails=2fail_timeout=10s;
}
server {
……
location / {
proxy_pass http://backend;
}
……
weight：輪詢權值也是可以用在ip_hash的，預設值為1
max_fails：允許請求失敗的次數，預設為1。當超過最大次數時，返回proxy_next_upstream模組定義的錯誤。
fail_timeout：有兩層含義，一是在10s 時間內最多容許2 次失敗；二是在經歷了 2 次失敗以後，10s時間內不分配請求到這臺伺服器。
6、nginx的proxy快取使用：
快取也就是將js、css、p_w_picpath等靜態檔案從後端伺服器快取到nginx指定的快取目錄下，既可以減輕後端伺服器負擔，也可以加快訪問速度，但這樣快取及時清理成為了一個問題，所以需要ngx_cache_purge這個模組來在過期時間未到之前，手動清理快取。
proxy模組中常用的指令時proxy_pass和proxy_cache.
nginx的web快取功能的主要是由proxy_cache、fastcgi_cache指令集和相關指令集完成，proxy_cache指令負責反向代理快取後端伺服器的靜態內容，fastcgi_cache主要用來處理FastCGI動態程序快取。
http {
#$upstream_cache_status記錄快取命中率
log_format main'$remote_addr - $remote_user [$time_local] "$request" '
'$status$body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"'
'"$upstream_cache_status"';
access_log logs/access.log main;
proxy_bufferingon;#代理的時候，開啟或關閉緩衝後端伺服器的響應
proxy_temp_path/usr/local/nginx1.10/proxy_temp;
proxy_cache_path /usr/local/nginx1.10/proxy_cache levels=1:2keys_zone=my-cache:100m inactive=600m max_size=2g;
server {
listen 80;
server_name localhost;
root html;
index index.php index.html index.htm;
#ngx_cache_purge實現快取清除
location ~/purge(/.*) {
allow 127.0.0.1;
allow 192.168.31.0/24;
deny all;
proxy_cache_purge my-cache$host$1$is_args$args;
}
location ~.*\.(gif|jpg|png|html|htm|css|js|ico|swf|pdf)(.*) {
proxy_pass http://backend;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For$proxy_add_x_forwarded_for;
proxy_ignore_headers Set-Cookie;
proxy_hide_header Set-Cookie;
proxy_next_upstream error timeout invalid_headerhttp_500 http_502 http_503 http_504;
proxy_cache my-cache;
add_header Nginx-Cache$upstream_cache_status;
proxy_cache_valid 200 304 301 302 8h;
proxy_cache_valid 404 1m;
proxy_cache_valid any 1d;
proxy_cache_key $host$uri$is_args$args;
expires 30d;
}
相關選項說明：
proxy_buffering on; 代理的時候，開啟或關閉緩衝後端伺服器的響應。
當開啟緩衝時，nginx儘可能快地從被代理的伺服器接收響應，再將它存入緩衝區中。
proxy_temp_path：快取臨時目錄。後端的響應並不直接返回客戶端，而是先寫到一個臨時檔案中，然後被rename一下當做快取放在proxy_cache_path。0.8.9版本以後允許temp和cache兩個目錄在不同檔案系統上（分割槽），然而為了減少效能損失還是建議把它們設成一個檔案系統上。
proxy_cache_path：設定快取目錄，目錄裡的檔名是cache_key的MD5值。
levels=1:2 keys_zone=my-cache:100m表示採用2級目錄結構，第一層目錄只有一個字元，是由levels=1:2設定，總共二層目錄，子目錄名字由二個字元組成。Web快取區名稱為my-cache，記憶體快取空間大小為100MB，這個緩衝zone可以被多次使用。檔案系統上看到的快取檔名類似於/usr/local/nginx1.10/proxy_cache/c/29/b7f54b2df7773722d382f4809d65029c 。
inactive=600max_size=2g表示600分鐘沒有被訪問的內容自動清除，硬碟最大快取空間為2GB，超過這個大學將清除最近最少使用的資料。
需要在預設情況，nginx不快取從後端響應的http頭中帶有Set-Cookie的物件。如果客戶端傳送的請求帶有Cookie header，varnish將忽略快取，直接將請求傳遞到後端。nginx中通過proxy_ignore_headers設定忽略它們，設定方法如下：
解決辦法：
proxy_ignore_headersSet-Cookie;
proxy_hide_headerSet-Cookie;
proxy_cache：引用前面定義的快取區my-cache
proxy_cache_key：定義如何生成快取的鍵，設定web快取的key值，nginx根據key值md5雜湊儲存快取
proxy_cache_valid：為不同的響應狀態碼設定不同的快取時間，比如200、302等正常結果可以快取的時間長點，而404、500等快取時間設定短一些，這個時間到了檔案就會過期，而不論是否剛被訪問過。
add_header指令來設定response header,語法: add_header name value;
$upstream_cache_status這個變數來顯示快取的狀態，我們可以在配置中新增一個http頭來顯示這一狀態，
$upstream_cache_status包含以下幾種狀態：
·MISS未命中，請求被傳送到後端
·HIT快取命中
·UPDATING正在更新快取，將使用舊的應答
·STALE後端將得到過期的應答
Expires ：在響應頭裡設定Expires:或Cache-Control:max-age，返回給客戶端的瀏覽器快取失效時間。
下面的nginx.conf實現nginx在前端做反向代理伺服器的完整配置檔案的例子，處理js、png等靜態檔案，jsp/php等動態請求轉發到其它伺服器tomcat/apache（詳見附件）
常用指令說明:
main全域性配置:
woker_processes4
在配置檔案的頂級main部分，worker角色的工作程序的個數，master程序是接收並分配請求給worker處理。這個數值簡單一點可以設定為cpu的核數grep^processor /proc/cpuinfo | wc -l，也是 auto 值，如果開啟了ssl和gzip更應該設定成與邏輯CPU數量一樣甚至為2倍，可以減少I/O操作。如果nginx伺服器還有其它服務，可以考慮適當減少。
worker_cpu_affinity
也是寫在main部分。在高併發情況下，通過設定cpu粘性來降低由於多CPU核切換造成的暫存器等現場重建帶來的效能損耗。如worker_cpu_affinity 0001 0010 0100 1000;（四核）。
附：
CPU工作狀況：（輸入 top 後，按1 檢視）
上面的配置表示：4核CPU，開啟4個程序。0001表示開啟第一個cpu核心， 0010表示開啟第二個cpu核心，依次類推；有多少個核，就有幾位數，1表示該核心開啟，0表示該核心關閉。
例如：
1、2核CPU，開啟2個程序
worker_processes2;
worker_cpu_affinity01 10;
worker_processes4;
worker_cpu_affinity01 10 01 10;
worker_processes8;
worker_cpu_affinity01 10 01 10 01 10 01 10;
worker_processes2;
worker_cpu_affinity10101010 01010101;
說明：10101010表示開啟了第2,4,6,8核心，01010101表示開始了1,3,5,7核心
通過apache的ab測試檢視nginx對CPU的使用狀況：
如果多個CPU核心的利用率都相差不多，證明nginx己經成功的利用了多核CPU。
測試結束後，CPU核心的負載應該都同時降低。
worker_connections4096
寫在events部分。每一個worker程序能併發處理（發起）的最大連線數（包含與客戶端或後端被代理伺服器間等所有連線數）。
worker_rlimit_nofile10240
寫在main部分。worker程序的最大開啟檔案數限制。預設是沒有設定，如果沒設定的話，這個值為作業系統的限制(ulimit -n)。可以限制為作業系統最大的限制65535。把這個值設高，這樣nginx就不會有“too many open files”問題了。
use epoll
寫在events部分。在Linux作業系統下，nginx預設使用epoll事件模型，得益於此，nginx在Linux作業系統下效率相當高。同時Nginx在OpenBSD或FreeBSD作業系統上採用類似於epoll的高效事件模型kqueue。
http伺服器:
與提供http服務相關的一些配置引數。例如：是否使用keepalive啊，是否使用gzip進行壓縮等。
sendfile on
開啟高效檔案傳輸模式。
keepalive_timeout 65:長連線超時時間，單位是秒，長連線請求大量小檔案的時候，可以減少重建連線的開銷，如果設定時間過長，使用者又多，長時間保持連線會佔用大量資源。
client_max_body_size 10m
允許客戶端請求的最大單檔案位元組數。如果有上傳較大檔案，請設定它的限制值
client_body_buffer_size 128k
緩衝區代理緩衝使用者端請求的最大位元組數
server_tokens off;
隱藏nginx的版本號
模組http_proxy：
這個模組實現的是nginx作為反向代理伺服器的功能，包括快取功能
proxy_connect_timeout 60
nginx跟後端伺服器連線超時時間(代理連線超時)
proxy_read_timeout 60
定義從後端伺服器讀取響應的超時。此超時是指相鄰兩次讀操作之間的最長時間間隔，而不是整個響應傳輸完成的最長時間。如果後端伺服器在超時時間段內沒有傳輸任何資料，連線將被關閉。
定義向後端伺服器傳輸請求的超時。此超時是指相鄰兩次寫操作之間的最長時間間隔，而不是整個請求傳輸完成的最長時間。如果後端伺服器在超時時間段內沒有接收到任何資料，連線將被關閉。
proxy_buffer_size 4k
設定緩衝區的大小為size。nginx從被代理的伺服器讀取響應時，使用該緩衝區儲存響應的開始部分。這部分通常包含著一個小小的響應頭。該緩衝區大小預設等於proxy_buffers指令設定的一塊緩衝區的大小，但它也可以被設定得更小。
proxy_buffers84k
語法:proxy_buffersthe_numberis_size;
為每個連線設定緩衝區的數量為number，每塊緩衝區的大小為size。這些緩衝區用於儲存從被代理的伺服器讀取的響應。每塊緩衝區預設等於一個記憶體頁的大小。這個值是4K還是8K，取決於平臺。
附：檢視Linux記憶體頁大小
[[email protected] ~]# getconfPAGESIZE
4096
或
[[email protected] ~]# getconfPAGE_SIZE
4096
proxy_busy_buffers_size 64k
高負荷下緩衝大小（預設大小是proxy_buffers指令設定單塊緩衝大小的2倍）
proxy_max_temp_file_size
當proxy_buffers放不下後端伺服器的響應內容時，會將一部分儲存到硬碟的臨時檔案中，這個值用來設定最大臨時檔案大小，預設1024M。
proxy_temp_file_write_size 64k
當快取被代理的伺服器響應到臨時檔案時，這個選項限制每次寫臨時檔案的大小。
模組http_gzip：
gzip on: 開啟gzip壓縮輸出，減少網路傳輸。
gzip_min_length 1k：設定允許壓縮的頁面最小位元組數，頁面位元組數從header頭得content-length中進行獲取。建議設定成大於1k的位元組數，小於1k可能會越壓越大。
gzip_buffers 4 16k：設定系統獲取幾個單位的快取用於儲存gzip的壓縮結果資料流。4 16k代表以16k為單位，按照原始資料大小以16k為單位的4倍申請記憶體。如果沒有設定，預設值是申請跟原始資料相同大小的記憶體空間去儲存gzip壓縮結果
gzip_http_version 1.1：用於識別 http 協議的版本，早期的瀏覽器不支援Gzip壓縮，使用者就會看到亂碼，所以為了支援前期版本加上了這個選項，如果你用了Nginx 的反向代理並期望也啟用Gzip壓縮的話，由於末端通訊是 http/1.1，故請設定為 1.1。
gzip_comp_level 6：gzip壓縮比，1壓縮比最小處理速度最快，9壓縮比最大但處理速度最慢(傳輸快但比較消耗cpu)
gzip_types：匹配mime型別進行壓縮，無論是否指定”text/html”型別總是會被壓縮的。
預設值: gzip_types text/html (預設不對js/css檔案進行壓縮)
# 壓縮型別，匹配MIME型別進行壓縮
# 不能用萬用字元 text/*
# (無論是否指定)text/html預設已經壓縮
# 設定哪壓縮種文字檔案可參考conf/mime.types
gzip_proxied any：Nginx作為反向代理的時候啟用，根據某些請求和應答來決定是否在對代理請求的應答啟用gzip壓縮，是否壓縮取決於請求頭中的“Via”欄位，指令中可以同時指定多個不同的引數，意義如下：
off – 關閉所有的代理結果資料的壓縮
expired –啟用壓縮，如果header頭中包含 “Expires” 頭資訊
no-cache –啟用壓縮，如果header頭中包含 “Cache-Control:no-cache” 頭資訊
no-store –啟用壓縮，如果header頭中包含 “Cache-Control:no-store” 頭資訊
private –啟用壓縮，如果header頭中包含 “Cache-Control:private” 頭資訊
no_last_modified –啟用壓縮,如果header頭中不包含 “Last-Modified” 頭資訊
no_etag –啟用壓縮 ,如果header頭中不包含“ETag” 頭資訊
auth –啟用壓縮 , 如果header頭中包含“Authorization” 頭資訊
any –無條件啟用壓縮
gzip_vary on：和http頭有關係，加個vary頭，給代理伺服器用的，有的瀏覽器支援壓縮，有的不支援，所以避免浪費不支援的也壓縮，所以根據客戶端的HTTP頭來判斷，是否需要壓縮
模組http_stream：
這個模組通過一個簡單的排程演算法來實現客戶端IP到後端伺服器的負載均衡，upstream後接負載均衡器的名字，後端realserver以host:portoptions;方式組織在 {} 中。如果後端被代理的只有一臺，也可以直接寫在proxy_pass。
Location:
root /var/www/html
定義伺服器的預設網站根目錄位置。如果locationURL匹配的是子目錄或檔案，root沒什麼作用，一般放在server指令裡面或/下。
indexindex.jsp index.htmlindex.htm
定義路徑下預設訪問的檔名，一般跟著root放
proxy_pass http:/backend
請求轉向backend定義的伺服器列表，即反向代理，對應upstream負載均衡器。也可以proxy_passhttp://ip:port。
proxy_redirect off;
指定是否修改被代理伺服器返回的響應頭中的location頭域跟refresh頭域數值
例如：
設定後端伺服器“Location”響應頭和“Refresh”響應頭的替換文字。假設後端伺服器返回的響應頭是 “Location:http://localhost:8000/two/some/uri/”，那麼指令
proxy_redirecthttp://localhost:8000/two/ http://frontend/one/;
將把字串改寫為 “Location:http://frontend/one/some/uri/”。
proxy_set_header Host $host;
允許重新定義或者添加發往後端伺服器的請求頭。
Host的含義是表明請求的主機名，nginx反向代理伺服器會向後端真實伺服器傳送請求，並且請求頭中的host欄位重寫為proxy_pass指令設定的伺服器。因為nginx作為反向代理使用，而如果後端真實的伺服器設定有類似防盜鏈或者根據http請求頭中的host欄位來進行路由或判斷功能的話，如果反向代理層的nginx不重寫請求頭中的host欄位，將會導致請求失敗。
proxy_set_header X-Forwarded-For$proxy_add_x_forwarded_for;
後端的Web伺服器可以通過X-Forwarded-For獲取使用者真實IP
X_Forward_For欄位表示該條http請求是有誰發起的？如果反向代理伺服器不重寫該請求頭的話，那麼後端真實伺服器在處理時會認為所有的請求都來自反向代理伺服器，如果後端有防***策略的話，那麼機器就被封掉了。因此，在配置用作反向代理的nginx中一般會增加兩條配置，修改http的請求頭：
proxy_set_header Host $host;
proxy_set_header X-Forward-For $remote_addr;
proxy_next_upstreamerrortimeout invalid_header http_500 http_502 http_503 http_504;
增加故障轉移，如果後端的伺服器返回502、504、執行超時等錯誤，自動將請求轉發到upstream負載均衡池中的另一臺伺服器，實現故障轉移。
proxy_set_header X-Real-IP $remote_addr;
web伺服器端獲得使用者的真實ip但是，實際上要獲得使用者的真實ip，也可以通過X-Forward-For
7、驗證：nginx反向代理的快取功能、負載均衡及健康檢查
1）下面我們來測試一下快取功能
如果在快取時間之內需要更新被快取的靜態檔案怎麼辦呢，這時候就需要手動來清除快取了。
ngx_cache_pure清除快取模組使用說明
用谷歌瀏覽器測試的時候，可以按F12呼叫開發工具，選擇Network選項，我們可以看到，Response Headers，在這裡我們可以看到，我們請求的是否是快取
從圖中我們可以看到，我們訪問的伺服器是192.168.31.83，快取命中。
也可以檢視快取目錄或nginx的訪問日誌
清除快取:
上述配置的proxy_cache_purge指令用於方便的清除快取，但必須按照第三方的ngx_cache_purge模組才能使用
使用ngx_cache_purge模組清除快取（直接刪除快取目錄下的檔案也算一種辦法）：
GET方式請求URL
即使用配置檔案中的location ~/purge(/.*)
瀏覽器訪問http://192.168.31.83/purge/your/may/path來清除快取
快取清除成功。
備註：
（1）purge是ngx_cache_pure模組指令
（2）your/may/path是要清除的快取檔案URL路徑
2）若只有一臺客戶端要驗證負載均衡和健康檢查可以先關掉快取功能和保持session會話
#proxy_buffering off;
#sticky
測試過程略
轉載於:https://blog.51cto.com/zhangminghao/1912227