nginx默認緩存

A. nginx 緩存機制

Nginx緩存的基本思路
基本思想是利用客戶訪問的時間局部性原理，對客戶已經訪問過的內容在Nginx伺服器本地建立副本，這樣在一段時間內再次訪問該數據，就不需要通過Nginx伺服器再次向後端伺服器發出請求，所以能夠減少Nginx伺服器與後端伺服器之間的網路流量，減輕網路擁塞，同時還能減小數據傳輸延遲，提高用戶訪問速度。同時，當後端伺服器宕機時，Nginx伺服器上的副本資源還能夠回應相關的用戶請求，這樣能夠提高後端伺服器的魯棒性。

對於緩存，我們大概會有以下問題：
（1）緩存文件放在哪兒？
（2）緩存的空間大小是否可以限定?
（3）如何指定哪些請求被緩存？
（4）緩存的有效期是多久？
（5）對於某些請求，是否可以不走緩存？

解決這些問題後，nginx的緩存也就基本配置完成了，下面看詳細配置過程
開啟緩存

要使用緩存，首先要使用 proxy_cache_path 這個指令（必須放在 http 上下文的頂層位置），然後在目標上下文中使用 proxy_cache 指令

配置示例

proxy_cache_path 有兩個必填參數，第一個參數為 緩存目錄，第二個參數keys_zone指定緩存名稱和佔用內存空間的大小（註：示例中的10m是對內存中緩存內容元數據信息大小的限制，如果想限制緩存總量大小，需要用 max_size 參數）

proxy_cache 的參數為之前指定的緩存名稱

緩存管理的相關進程
在緩存工作中有兩個附加進程：
（1）緩存管理器
定期檢查緩存狀態，看緩存總量是否超出限制，如果超出，就移除其中最少使用的部分
（2）緩存載入器
載入器只在nginx啟動後運行一次，把緩存內容的元數據信息載入到內存空間，如果一次性載入全部緩存信息，會大量消耗資源，使nginx在啟動後的幾分鍾里變慢，為避免此問題，有3種載入策略：
loader_threshold – 指定每次載入執行的時間
loader_files – 每次最多載入的數量
loader_sleeps – 每次載入的延時
例如：
proxy_cache_path /data/nginx/cache keys_zone=one:10m loader_threshold=300 loader_files=200;
指定緩存哪些請求
nginx默認會緩存所有 get 和 head 方法的請求結果，緩存的key默認使用請求字元串
（1）自定義key
例如 proxy_cache_key " request_uri cookie_nocache arg_comment;
如果任何一個參數值不為空，或者不等於0，nginx就不會查找緩存，直接進行代理轉發
綜合示例

nginx 緩存機制
三分鍾看懂Nginx伺服器的緩存原理和機制

B. Nginx緩存設置教程

| 這篇文章主要介紹了Nginx緩存設置案例詳解,本篇文章通過簡要的案例,講解了該項技術的了解與使用,以下就是詳細內容,需要的朋友可以參考下 |

在開發調試web的時候，經常會碰到因瀏覽器緩存(cache)而經常要去清空緩存或者強制刷新來測試的煩惱，提供下apache不緩存配置和nginx不緩存配置的設置。在常用的緩存設置裡面有兩種方式，都是使用add_header來設置：分別為Cache-Control和Pragma。

對於站點中不經常修改的靜態內容（如圖片，JS，CSS），可以在伺服器中設置expires過期時間，控制瀏覽器緩存，達到有效減小帶寬流量，降低伺服器壓力的目的。

以Nginx伺服器為例：

【背景】：Expires是Web伺服器響應消息頭欄位，在響應http請求時告訴瀏覽器在過期時間前瀏覽器可以直接從瀏覽器緩存取數據，而無需再次請求。

【相關資料】

1、Cache-control策略

Cache-Control與Expires的作用一致，都是指明當前資源的有效期，控制瀏覽器是否直接從瀏覽器緩存取數據還是重新發請求到伺服器取數據。只不過Cache-Control的選擇更多，設置更細致，如果同時設置的話，其優先順序高於Expires。

http協議頭Cache-Control ：

值可以是public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age

各個消息中的指令含義如下：

Last-Modified/If-Modified-Since

其最終達到的就是等效於設置這三類html緩存技術：

C. nginx緩存(proxy_cache模塊)

緩存的基本思想是利用客戶端訪問的時間局限性，將客戶端訪問過的內容做一個副本，在一定時間內存放到本地，當改數據下次被訪問時，不必連接到後端伺服器反復去查詢數據，而是由本地保存的副本響應數據。

保存在本地的這些副本具有一個過期時間，超過該時間將會更新。判斷一個副本數據是否為過期數據的辦法有很多，可以使用保留時間來判斷，也可以使用數據完整度來判斷。

許多Web伺服器還具有校驗功能，就是當某些副本數據過期以後，先向後端伺服器發送校驗請求，後端伺服器對這些數據進行校驗，如果發現原數據和副本沒有差別，則將過期副本重新置為可用副本。

以上nginx配置結合使用：

proxy_params文件的配置如下：

訪問一次頁面，並向 http://www.blogs-s.com:8080/api/ 發起一個介面數據請求,查看/cache/nginx目錄下的緩存結果：

ngx_cache_purge是nginx的第三方模塊，能夠幫助我清除nginx中的緩存。

在之前的nginx編譯安裝中我們是沒有把緩存的清除模塊ngx_cache_purge編譯進去的，如果啟動了緩存，沒有安裝這個模塊，在之後的調試中我們嘗試去清除緩存時，將會出現異常：

這個異常是在指示我們，找不到該指令的驅動，需要按照相關模塊。

ngx_cache_purge只是nginx的第三方模塊，並不是某個特殊的軟體，所以我們需要對nginx重新進行編譯，操作如下：

配置nginx：

再一次啟動nginx成功；

接下來進行緩存清除測試，訪問： http://blogs.com/clear_cache/api/index.php , 訪問這個連接將會清除介面： http://blogs.com/api/index.php 的緩存數據。

結果如下：

在項目開發中，不可能出現什麼都需要緩存的數據，緩存僅僅適合去緩存查詢頻繁，但是不需要實時更新的數據，這個是它適合的場景，而我們上面的配置，只要是訪問api介面目錄就會緩存介面的數據，這樣對於一些需要實時更新的介面數據來說是不合理的，需要控制好nginx的緩存去緩存什麼以及不緩存什麼

set 指令為變數設置，proxy_no_cache參數中的值可以設置多個，但是多個值中，只要有一個是不為0的，就會通過緩存響應數據。

該指令用於配置一塊公用的內存區域的名稱,該區域可以存放緩存的索引數據。這些數據在Nginx伺服器啟動時由緩存索引重建進程負責建立，在Nginx伺服器的整個運行過程中由緩存管理進程負責定時檢測過期數據，檢索等管理工作。

該指令用於配置Nginx伺服器向客戶端發送響應數據時，不從緩存中獲取的條件。這些條件支持使用Nginx 配置的常用變數。

看一個例子:

其中，Scookie_nocache、Sarg_nocache、Sarg_comment、Shttp_pragma 和Shttp_authorization 都是Nginx配置文件的變數，

該指令用於設置Nginx伺服器在內存中為緩存數據建立索引時使用的關鍵字

如果我們希望緩存數據包含伺服器主機名稱等關鍵字，則可以將該指令設置為:

該指令用於設置是否開啟緩存的鎖功能。在緩存中，某些數據項可以同時被多個請求返回的響應數據填充。開啟該功能後，Nginx伺服器同時只能有一個請求填充緩存中的某一數據項，這相當於給該數據項上鎖,不允許其他請求操作。其他的請求如果也想填充該項,必須等待該數據項的鎖被釋放。這個等待時間由 proxy_cache_lock_timeout 指令配置。

該指令用於設置緩存的鎖功能開啟以後鎖的超時時間。具體細節參見proxy_cache_lock 指令的相關內容

其中，time為設置的時間，默認為5s。

該指令用於設置客戶端請求發送的次數，當客戶端向被代理伺服器發送相同請求達到該指令設定的次數後，Nginx伺服器才對該請求的響應數據做緩存。合理設置該值可以有效地降低硬碟上緩存數據的數量，並提高緩存的命中率。

其中，number為設置的次數。默認設置為1。

該指令用於設置Nginx伺服器存儲緩存數據的路徑以及和緩存索引相關的內容

該指令設置比較復雜，一般需要設置前面三個指令的情形比較多，後面的幾個變數與Nginx伺服器緩存索引重建進程及管理進程的性能相關，一般情況下保持默認設置就可以了。我們來看幾個簡單的配置實例:

如果Nginx在訪問被代理伺服器過程中出現被代理的伺服器無法訪問或者訪問錯誤等現象時，Nginx伺服器可以使用歷史緩存響應客戶端的請求，這些數據不一定和被代理伺服器上最新的數據相一致，但對於更新頻率不高的後端伺服器來說，Nginx伺服器的該功能在一定程度上能夠為客戶端提供不間斷訪問。該指令用來設置一些狀態，當後端被代理的伺服器處於這些狀態時，Nginx伺服器啟用該功能。

該指令可以支持的狀態如語法結構中所示。

該指令可以針對不同的HTTP響應狀態設置不同的緩存時間，

該指令同於配置在什麼情況下不使用cache功能

該指令配置是否在本地磁碟緩存來自被代理伺服器的響應數據。這是Nginx伺服器提供的另一種緩存數據的方法，但是該功能相對 Proxy Cache簡單一些，它不提供緩存過期更新、內存索引建立等功能，不佔用內存空間，對靜態數據的效果比較好。

Proxy Store方法多使用在被代理伺服器端發生錯誤的情況下,用來緩存被代理伺服器的響應數據。

該指令用於設置用戶或用戶組對Proxy Store緩存的數據的訪問許可權，

有關Proxy Store方法的使用，我們通過官方給出的實例加深理解，在該實例中筆者通過注釋對配置做了說明:

D. 【NGINX入門】3.Nginx的緩存伺服器proxy_cache配置

本文介紹NGINX緩存機制，配置和參數說明。

如圖所示，nginx緩存，可以在一定程度上，減少源伺服器的處理請求壓力。因為靜態文件（比如css，js， 圖片）中，很多都是不經常更新的。nginx使用proxy_cache將用戶的請求緩存到本地一個目錄。下一個相同請求可以直接調取緩存文件，就不用去請求伺服器了。畢竟，IO密集型服務的處理是nginx的強項。

Nginx的緩存加速功能是由proxy_cache（用於反向代理和靜態緩存）和fastcgi_cache（PHP動態緩存）兩個功能模塊完成。

Nginx緩存特點：

先上個例子：

因為我是在一台伺服器上做試驗，所以用了兩個埠 80 和 90 進行模擬兩台伺服器之間的交互。

接下來講一下配置項：

這里我設置了 圖片 、 css 、 js 靜態資源進行緩存。
當用戶輸入 http://wangxiaokai.vip 域名時，解析得到 ip:port 的訪問地址。 port 默認為80。所以頁面請求會被當前server截取到，進行請求處理。
當解析到上述文件名結尾的靜態資源，會到緩存區獲取靜態資源。
如果獲取到對應資源，則直接返回數據。
如果獲取不到，則將請求轉發給 proxy_pass 指向的地址進行處理。

這里直接處理 90 埠接受到的請求，到伺服器本地目錄 /mnt/blog 下抓取資源進行響應。

細心的讀者應該發現，我在第二段例子里，留了個彩蛋 add_header wall "hey!guys!give me a star." 。
add_header 是用於在報頭設置自定義的信息。
所以，如果緩存有效的話，那麼靜態資源返回的報頭，一定會帶上這個信息。

（1）Nginx系列教程（3）nginx緩存伺服器上的靜態文件
https://yq.aliyun.com/articles/752967

（2）proxy_cache
nginx 反向代理之 proxy_cache https://www.cnblogs.com/yyxianren/p/10832172.html

（3）Nginx使用upstream負載均衡和proxy_cache緩存實現反向代理
https://blog.51cto.com/13770206/2163952

E. nginx 緩存怎麼都在tmp

nginx緩存cache的5種方案
1、傳統緩存之一（404）
這個辦法是把nginx的404錯誤定向到後端，然後用proxy_store把後端返回的頁面保存。
配置：

location / {
root /home/html/;#主目錄
expires 1d;#網頁的過期時間
error_page 404 =200 /fetch$request_uri;#404定向到/fetch目錄下
}
location /fetch/ {#404定向到這里
internal;#指明這個目錄不能在外部直接訪問到
expires 1d;#網頁的過期時間
alias /html/;
proxy_store會將文件保存到這目錄下
proxy_passhttp://www.jb51.net/;#後端upstream地址，/fetch同時是一個代理
proxy_set_header Accept-Encoding '';#讓後端不要返回壓縮（gzip或deflate）的內容，保存壓縮後的內容會引發亂子。
proxy_store on;#指定nginx將代理返回的文件保存
proxy_temp_path /home/tmp;#臨時目錄，這個目錄要和/home/html在同一個硬碟分區內

}

使用的時候還有要注意是nginx要有許可權往/home/tmp和/home/html下有寫入文件的許可權，在linux下nginx一般會配
置成nobody用戶運行，這樣這兩個目錄就要chown nobody，設成nobody用戶專用，當然也可以chmod
777，不過所有有經驗的系統管理員都會建議不要隨便使用777。
2、傳統緩存之二（!-e）
原理和404跳轉基本一致，但更簡潔一些：

location / {
root /home/html/;
proxy_store on;
proxy_set_header Accept-Encoding '';
proxy_temp_path /home/tmp;
if ( !-f $request_filename )
{
proxy_passhttp://www.jb51.net/;
}
}

可以看到這個配置比404節約了不少代碼，它是用!-f來判斷請求的文件在文件系統上存不存在，不存在就proxy_pass到後端，返回同樣是用proxy_store保存。
兩種傳統緩存都有著基本一樣的優點和缺點：
缺點1：不支持帶參數的動態鏈接，比如read.php?id=1，因為nginx只保存文件名，所以這個鏈接只在文件系統下保存為
read.php，這樣用戶訪問read.php?id=2時會返回不正確的結果。同時不支持http://www.jb51.net/這種形式的首頁和
二級目錄http://www.jb51.net/download/，因為nginx非常老實，會將這樣的請求照鏈接寫入文件系統，而這個鏈接顯然是一
個目錄，所以保存失敗。這些情況都需要寫rewrite才能正確保存。
缺點2：nginx內部沒有緩存過期和清理的任何機制，這些緩存的文件會永久性地保存在機器上，如果要緩存的東西非常多，那就會撐暴整個硬碟空間。為此可以使用一個shell腳本定期清理，同時可以撰寫php等動態程序來做實時更新。
缺點3：只能緩存200狀態碼，因此後端返回301/302/404等狀態碼都不會緩存，假如恰好有一個訪問量很大的偽靜態鏈接被刪除，那就會不停穿透導致後端承載不小壓力。
缺點4：nginx不會自動選擇內存或硬碟作為存儲介質，一切由配置決定，當然在當前的操作系統里都會有操作系統級的文件緩存機制，所以存在硬碟上也不需要過分擔心大並發讀取造成的io性能問題。
nginx傳統緩存的缺點也是它和squid等緩存軟體的不同之特色，所以也可看作其優點。在生產應用中它常常用作和squid的搭檔，squid對
於帶?的鏈接往往無法阻擋，而nginx能將其訪問攔住，例如：http://jb51.net/?和http://jb51.net/在squid上會
被當做兩個鏈接，所以會造成兩次穿透；而nginx只會保存一次，無論鏈接變成http://jb51.net/?1還是http://jb51.net
/?123，均不能透過nginx緩存，從而有效地保護了後端主機。
nginx會非常老實地將鏈接形式保存到文件系統中，這樣對於一個鏈接，可以很方便地查閱它在緩存機器上的緩存狀態和內容，也可以很方便地和別的文件管理器如rsync等配合使用，它完完全全就是一個文件系統結構。
這兩種傳統緩存都可以在linux下將文件保存到/dev/shm里，一般我也是這么做的，這樣可以利用系統內存來做緩存，利用內存的話，清理過期內
容速度就會快得多。使用/dev/shm/時除了要把tmp目錄也指向到/dev/shm這個分區外，如果有大量小文件和目錄，還要修改一下這個內存分區
的inode數量和最大容量：


mount -o size=2500M -o nr_inodes=480000 -o noatime,nodiratime -o remount /dev/shm

上面的命令在一台有3G內存的機器上使用，因為/dev/shm默認最大內存是系統內存的一半就是1500M，這條命令將其調大成2500M，
同時shm系統inode數量默認情況下可能是不夠用的，但有趣的是它可以隨意調節，這里調節為480000保守了點，但也基本夠用了。
3、基於memcached的緩存
nginx對memcached有所支持，但是功能並不是特別之強，性能上還是非常之優秀。


location /mem/ {
if ( $uri ~ "^/mem/([0-9A-Za-z_]*)$" )
{
set $memcached_key "$1";
memcached_pass 192.168.1.2:11211;
}
expires 70;
}

這個配置會將http://jb51.net/mem/abc指明到memcached的abc這個key去取數據。
nginx目前沒有寫入memcached的任何機制，所以要往memcached里寫入數據得用後台的動態語言完成，可以利用404定向到後端去寫入數據。
4、基於第三方插件ncache
ncache是新浪兄弟開發的一個不錯的項目，它利用nginx和memcached實現了一部分類似squid緩存的功能，我並沒有使用這個插件的經驗，可以參考：
http://code.google.com/p/ncache/
5、nginx新開發的proxy_cache功能
從nginx-0.7.44版開始，nginx支持了類似squid較為正規的cache功能，目前還處於開發階段，支持相當有限，這個緩存是把鏈接用md5編碼hash後保存，所以它可以支持任意鏈接，同時也支持404/301/302這樣的非200狀態。
配置：
首先配置一個cache空間：

復制代碼 代碼如下:

proxy_cache_path /path/to/cache levels=1:2 keys_zone=NAME:10m inactive=5m max_size=2m clean_time=1m;

注意這個配置是在server標簽外，levels指定該緩存空間有兩層hash目錄，第一層目錄是1個字母，第二層為2個字母，保存的文件名就會類
似/path/to/cache/c/29/；keys_zone為這個空間起個名
字，10m指空間大小為10MB；inactive的5m指緩存默認時長5分鍾；max_size的2m是指單個文件超過2m的就不緩
存；clean_time指定一分鍾清理一次緩存。

location / {
proxy_passhttp://www.jb51.net/;
proxy_cache NAME;#使用NAME這個keys_zone
proxy_cache_valid 200 302 1h;#200和302狀態碼保存1小時
proxy_cache_valid 301 1d;#301狀態碼保存一天
proxy_cache_valid any 1m;#其它的保存一分鍾
}

ps：支持cache的0.7.44到0.7.51這幾個版本的穩定性均有問題，訪問有些鏈接會出現錯誤，所以這幾個版本最好不要在生產環境中
使用。nginx-0.7下目前所知較為穩定的版本是0.7.39。穩定版0.6.36版也是近期更新，如果在配置里沒有使用到0.7的一些新標簽新功
能，也可以使用0.6.36版。

Nginx緩存的內存佔用問題的一般解決方法
1、前些日子某服務被刷，每分鍾達到上幾百萬請求；當時採用了nginx cache來解決的；但是因為某服務不能緩存太久，當時設置了5s，那麼帶來的問題就是產生大量小文件，而且很快就刪除了。

2、通過

free -m

會發現used是27G；但是通過top查看進程占的內存並沒有那麼多

那內存去哪了？

3、通過查閱資料會發現(cat /proc/meminfo)
Slab: 22464312 kB
SReclaimable: 16474128 kB （這些是內核保持的但是可以釋放的inode和dentry的緩存）
SUnreclaim: 5990184 kB

4、這些內存為什麼會不自動清理呢？
某機房機器系統版本：Linux 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux（正常，沒出現內存快到100%的情況）
某機房機器系統版本：Linux 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux （不釋放）

5、通過設置如下參數來設置內存閥值

sysctl -w vm.extra_free_kbytes=6436787
sysctl -w vm.vfs_cache_pressure=10000

F. Nginx作為緩存服務

  上一篇文章講了Nginx作為代理服務的使用方式，這篇文章我們講一講Nginx作為緩存服務是怎麼工作的，以及實戰的使用。
  先看一張圖：

  面對第一次客戶端的應用Nginx需要從後端的服務獲取數據，對於後續的請求，Nginx若進行了緩存就不再從後端服務獲取數據。

語法：proxy_cache_path path [levels=levels].只能用在http中。

  proxy_cache zone | off。默認是關閉的，可以用在http,server,location中。

訪問zzm這個路徑的時候，會返回配置文件中的spring.s項，具體值可以參考我們的啟動設置：

三個後台金正分別對應6000埠，6001埠，6002埠

所以我們訪問ip:port/zzm的時候會自動去訪問後台

我們首先注釋掉proxy_cache zzm_cache;進行訪問，也就是沒有緩存的情況下，訪問3次：

我們可以看到沒有緩存的情況下，會進行輪詢訪問，每次訪問的結果不一樣，而且我們的緩存路徑什麼都沒有，讓我想起了一首歌空空如也：

好奇的看了下目錄下的文件內容：

add_header Nging-Cache "$upstream_cache_status";

當我們沒有緩存的時候，我們可以看到應答會是MISS：

現在nginx.conf中加入新的配置項：

此時我們怒刷前端頁面，會發現後端日誌如下：

Nginx的緩存服務就講到這里，歡迎大家指正

G. nginx基本配置（參考）

Nginx是一款自由的、開源的、高性能的HTTP伺服器和反向代理伺服器；同時也是一個IMAP、POP3、SMTP代理伺服器；Nginx可以作為一個HTTP伺服器進行網站的發布處理，另外Nginx可以作為反向代理進行負載均衡的實現。

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

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

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

4、server塊：配置虛擬主機的相關參數，一個http中可以有多個server。
5、location塊：配置請求的路由，以及各種頁面的處理情況。

6、緩存控制欄位cache-control的配置說明 ( https://www.cnblogs.com/kevingrace/p/10459429.html )

HTTP協議的Cache -Control指定請求和響應遵循的緩存機制。在請求消息或響應消息中設置 Cache-Control並不會影響另一個消息處理過程中的緩存處理過程。
請求時的緩存指令包括: no-cache、no-store、max-age、 max-stale、min-fresh、only-if-cached等。
響應消息中的指令包括: public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age。

no-cache: 數據內容不能被緩存, 每次請求都重新訪問伺服器, 若有max-age, 則緩存期間不訪問伺服器.
no-store: 不僅不能緩存, 連暫存也不可以(即: 臨時文件夾中不能暫存該資源).
private(默認): 只能在瀏覽器中緩存, 只有在第一次請求的時候才訪問伺服器, 若有max-age, 則緩存期間不訪問伺服器.
public: 可以被任何緩存區緩存, 如: 瀏覽器、伺服器、代理伺服器等.
max-age: 相對過期時間, 即以秒為單位的緩存時間.
no-cache, private: 打開新窗口時候重新訪問伺服器, 若設置max-age, 則緩存期間不訪問伺服器.

設置以分鍾為單位的絕對過期時間, 優先順序比Cache-Control低, 同時設置Expires和Cache-Control則後者生效. 也就是說要注意一點: Cache-Control的優先順序高於Expires

expires起到控制頁面緩存的作用，合理配置expires可以減少很多伺服器的請求, expires的配置可以在http段中或者server段中或者location段中. 比如控制圖片等過期時間為30天

客戶端必須設置正向代理伺服器，當然前提是要知道正向代理伺服器的IP地址，還有代理程序的埠。

"它代理的是客戶端，代客戶端發出請求"，是一個位於客戶端和原始伺服器(origin server)之間的伺服器，為了從原始伺服器取得內容，客戶端向代理發送一個請求並指定目標(原始伺服器)，然後代理向原始伺服器轉交請求並將獲得的內容返回給客戶端。客戶端必須要進行一些特別的設置才能使用正向代理。
正向代理的用途：
（1）訪問原來無法訪問的資源，如Google
（2） 可以做緩存，加速訪問資源
（3）對客戶端訪問授權，上網進行認證
（4）代理可以記錄用戶訪問記錄（上網行為管理），對外隱藏用戶信息

多個客戶端給伺服器發送的請求，Nginx伺服器接收到之後，按照一定的規則分發給了後端的業務處理伺服器進行處理了。此時~請求的來源也就是客戶端是明確的，但是請求具體由哪台伺服器處理的並不明確了，Nginx扮演的就是一個反向代理角色。

客戶端是無感知代理的存在的，反向代理對外都是透明的，訪問者並不知道自己訪問的是一個代理。因為客戶端不需要任何配置就可以訪問。

反向代理，"它代理的是服務端，代服務端接收請求"，主要用於伺服器集群分布式部署的情況下，反向代理隱藏了伺服器的信息。

反向代理的作用：
（1）保證內網的安全，通常將反向代理作為公網訪問地址，Web伺服器是內網
（2）負載均衡，通過反向代理伺服器來優化網站的負載

H. Nginx文件描述符緩存--open_file_cache

標簽（空格分隔）： nginx

NGINX雖然已經對靜態內容做過優化。但在高流量網站的情況下，仍然可以使用open_file_cache進一步提高性能。 NGINX緩存將最近使用的文件描述符和相關元數據（如修改時間，大小等）存儲在緩存中。緩存不會存儲所請求文件的內容。

啟用此指令將存儲以下信息的緩存：

如下例子：

在上述配置中，為1,000個元素定義了一個緩存。 inactive參數配置到期時間為20秒。 沒有必要為該指令設置非活動時間段，默認情況下，非活動時間段為60秒。
NGINX還定義了一些相關的指令，可用於在錯誤和有效性檢查期間配置open_file_cache的行為。

NGINX的open_file_cache保存信息的快照。 由於信息在源處更改，快照可能在一段時間後無效。 open_file_ cache_valid指令定義時間段（以秒為單位），之後將重新驗證open_file_cache中的元素。默認情況下，60秒後重新檢查元素。 如下例子：

NGINX將在非活動時間段之後從高速緩存中清除元素。 此指令可用於配置最小訪問次數以將元素標記為活動使用。 默認情況下，最小訪問次數設置為1次或更多次。如下例子

如前所述，NGINX可以緩存在文件訪問期間發生的錯誤。但是這需要通過設置open_file_cache_errors指令來啟用。 如果啟用錯誤緩存，則在訪問資源（不查找資源）時，NGINX會報告相同的錯誤。默認情況下，錯誤緩存設置為關閉。