主頁 > 知識庫 > nginx正向代理與反向代理詳解

nginx正向代理與反向代理詳解

熱門標簽:四川保險智能外呼系統 地圖標注員有發(fā)展前景嗎 云南電商智能外呼系統哪家好 廈門防封電銷電話卡 外呼系統全國 地圖標注能更改嗎 濰坊寒亭400電話辦理多少錢 高德地圖標注公司需要錢 宜賓銷售外呼系統軟件

正向代理

就是假設有一個內網

內網有兩臺機器,這兩臺機器只有 a 可以上網

b 不能上網,但是 a 和 b 通過網絡相連接

這時如果 b 想訪問外網,就可以通過 a 來正向代理訪問外網

正向代理就是在內網中模擬目標服務器,把內網中其它機器的請求

轉發(fā)給外網中的真正的目標服務器

所以正向代理是接受內網其它機器的請求的

反向代理則是反過來

也是一個內網,有幾臺機器,只有其中一臺與外網連接

但是反向代理接受的不是內網機器的訪問請求

反向代理接受的是外網過來的訪問請求

然后把請求轉發(fā)到內網中的其它機器上去

外網發(fā)出請求的用戶并不知道反向代理的服務器把請求轉發(fā)給了誰

要在一臺機器上設置正向代理的功能

如圖,編輯一個nginx配置文件

上圖就是配置文件內容

如果配置一臺服務器作為正向代理服務器

那么這個虛擬主機配置文件就必須是默認虛擬主機

因為所有訪問這臺機器的網絡請求應該先訪問這個虛擬主機才對

所以這里要設置 default_server

然后還要把原來的 默認虛擬主機 配置文件名稱修改掉

如圖,把 default.conf 配置文件的名稱修改一下

這樣就取消了原來的默認虛擬主機配置文件了

因為默認的默認虛擬主機配置文件就是 default.conf

配置文件里面的 resolver 119.29.29.29

意思是配置一個 dns 地址

因為是做正向代理,接受了內網請求的域名后

要把請求發(fā)送給真正要訪問的服務器

但是內網發(fā)送的域名是沒有包含 ip 地址的

所以還要把域名發(fā)送給 dns 服務器解析 ip 地址

拿到 ip地址后才能轉發(fā)到要訪問的服務器上去

所以這里需要配置一個 dns 地址

接受了內網域名后,就會把域名發(fā)送到這個 dns 上去解析

下面的 location 按照圖中設置就可以了

這樣正向代理服務器接受內網機器請求后

就會把域名發(fā)到配置的dns上解析,然后訪問真正的服務器

再把真正服務器返回的內容發(fā)送給發(fā)出請求的內網機器

nginx反向代理

做一個反向代理的例子

如圖建立一個測試的虛擬主機配置文件

監(jiān)聽 8080 端口,域名為 www.test.com

根目錄是 /data/wwwroot/test.com

訪問虛擬主機顯示的首頁文件是 index.html

如圖,創(chuàng)建虛擬主機的根目錄 /data/wwwroot/test.com

然后使用 echo "test.com_8080" > !$/index.html

創(chuàng)建一個內容為 test.com_8080 的首頁文件

這個文件在 /data/wwwroot/test.com 目錄里面

如圖,新建一個反向代理的虛擬主機配置文件

監(jiān)聽 80 端口,域名為 www.test.com

下面的 location / 里面就是反向代理的配置

當訪問這個虛擬主機的時候,就會把訪問請求發(fā)送給 127.0.0.1:8080

如圖,使用 curl 訪問 127.0.0.1:8080 虛擬主機

成功返回了 test.com_8080 這說明這個虛擬主機能夠被訪問

如圖,再創(chuàng)建一個虛擬主機配置文件

跟之前的 test 虛擬主機差不多

但是這個虛擬主機并沒有設置 域名

location 設置返回的內容是 8080 default 字符串

保存退出,重載 nginx

還要把 test虛擬主機的 default server 設置取消掉

那么現在 127.0.0.1:8080 對應兩個虛擬主機

一個是 test 虛擬主機,另外一個是 8080 default 虛擬主機

這兩個虛擬主機的 ip 端口都是一模一樣的

它們的區(qū)別是 test 虛擬主機是有域名的

而 8080 default 虛擬主機是沒有域名的

現在已經設置了 8080 default 為默認虛擬主機

所以如果只訪問 127.0.0.1:8080 的話

訪問的一定是 8080 default 虛擬主機

如果想訪問 test 虛擬主機,就需要加上 test 虛擬主機的域名

才能成功訪問 test 虛擬主機

如圖,可以看到訪問 curl 127.0.0.1:8080/ 返回的結果是 8080 default

使用 curl -x127.0.0.1:8080 www.test.com

這里帶上了域名,返回的就是 test.com_8080

說明想訪問 test 虛擬主機,ip端口還需要綁定域名才行

如圖,curl 訪問 127.0.0.1:80 域名 www.test.com

返回的是 test.com_8080 說明這個反向代理成功了

我們訪問的是 80 端口,實際卻返回了 8080 端口的虛擬主機的內容

如圖,這里把反向代理虛擬主機里面的 proxy_pass 行下面的都注釋掉

保存退出,重載 nginx

如圖,再使用 curl 訪問 127.0.0.1:80 域名 www.test.com

實際返回的卻是 8080 default

而我們想訪問的卻是 test 虛擬主機

如圖,proxy_set_header Host $host;

這一行代碼就是指定訪問的域名

上面設置了 127.0.0.1:8080

反向代理的時候就會指向這個 ip端口

如果不設置 host 那就只會訪問 127.0.0.1:8080 的虛擬主機

如果設置了 host ,那么就會指向跟指定的 host 綁定的 127.0.0.1:8080

這里的 $host 是系統變量,實際的值就是當前的虛擬主機的 server_name

也就是 www.test.com ,server_name 是什么,host的值就是什么

這里設置了 host 就相當于 curl -x127.0.0.1:8080 www.test.com

如果這里不設置 host 那么就只會訪問 127.0.0.1:8080

這樣就可以把 域名 跟 ip端口進行綁定

如圖,除了寫 ip端口之外,proxy_pass 也可以直接寫域名

這里寫的是 www.123.com:8080/

但是這樣寫的話, nginx 并不知道這個域名指向哪里

所以還需要在系統里面綁定對應的 ip

例如在 /etc/hosts 文件里面,寫入對應的 域名和 ip 進行綁定

這樣nginx 里面的 proxy_pass 的域名系統就會解析出一個 Ip 地址

然后再訪問這個 ip端口

下面的 proxy_header Host 作用就是設置一個 域名

這個域名會與上面的 ip端口綁定訪問

如果上面的 ip端口 寫的不是 ip 而是域名

跟下面指定的域名是不沖突的,因為上面寫的域名的作用是用來解析ip的

下面指定的域名才會跟上面解析出來的 ip端口進行綁定訪問

這個例子使用的是 $host 這是 nginx全局變量

這個變量實際是對應了一個值的,就是當前虛擬主機 server_name 的值

但是一般來說,還是直接寫 ip 端口方便一些

上面就是指定 ip端口

下面指定跟 ip端口綁定的 host 域名

nginx反向代理02

如圖,proxy_pass 指令后面可以跟 url

有三種格式,傳輸協議+域名+uri (訪問路徑)

傳輸協議+ip端口+uri

傳輸協議+socket

這里 unix ,http ,https 都是傳輸協議的種類

域名+uri 和 ip端口+uri 還有 socket 都是訪問的路徑

socket 一般是某個程序專用的訪問端口

訪問某個socket就是訪問某個特定的程序,所以不需要使用路徑

如圖,寫 proxy_pass 的時候,不同的寫法有不同的結果

比如 location /aming/

如果訪問的路徑包含 /aming/ 就會觸發(fā)

這里的proxy_pass 就會執(zhí)行

但是location 里面的 proxy_pass 不同的寫法會導致實際訪問的路徑有差別

雖然因為訪問的路徑包含 /aming/ 目錄才執(zhí)行 proxy_pass

但是實際訪問的路徑不一定包含 /aming/

這個例子是訪問虛擬主機內的 /aming/a.html 文件

根據 proxy_pass 的不同寫法實際上會訪問到不同的路徑去

如果 ip端口 后面沒有接任何目錄符號

就會訪問 /aming/a.html,這是我們想要的

如果 ip端口后面接了根目錄符號 /

那么就會直接訪問根目錄里面的 a.html文件,這顯然不對

ip端口后面接 /linux/ 那么就會訪問 /linux/ 里面的 a.html文件

如果 ip端口后面是 /linux 最后沒有跟目錄符號 /

就會訪問 /linuxa.html

所以如果想正確訪問 /aming/a.html

有兩種寫法,一種是 ip端口后面不要加任何目錄符號 /

第二種是完整的寫成 ip端口/aming/ 這樣寫

根據上面示例可以發(fā)現,ip端口后面不管是什么目錄

實際訪問路徑就會變成直接把最終要訪問的文件名稱 a.html

直接添加到 ip端口 后面的目錄上去

所以 ip端口后面不寫任何目錄符號的話,系統才會自己添加 /aming/a.html 這個目錄路徑

一旦有任何目錄符號存在,就會直接把 a.html 放在這個目錄符號后面

第二種情況是,ip端口+ /linux

實際結果是訪問 /linuxa.html

這可能是因為 linux 后面沒有跟上任何目錄符號 /

所以系統把 linux 認為是一個沒有寫完的文件名稱

然后就直接把 a.html 這個文件名稱跟 linux 粘貼在一起

這樣就變成了要訪問的文件是 /linuxa.html 的形式

所以不管寫什么路徑,后面一定要跟上目錄符號 /

反向代理03

如圖,proxy_set_header 是設置被代理的服務器可以接收到的 header 信息的

比如有三臺電腦 a b c

a 是我們用來訪問的電腦,我們從 a 發(fā)出訪問請求

b 是反向代理服務器,b 接收我們發(fā)出的訪問請求

c 是被反向代理的服務器,也就是我們真正要訪問的服務器

b 會把我們的訪問請求轉發(fā)給 c

如果不設置 proxy_set_header 的話,b 轉發(fā)請求給 c 的時候就不會帶上相應的 header 信息

如果設置了這個參數,在轉發(fā)請求的時候就會帶上對應的 header 信息

其中 $remote_addr 和 $proxy_add_x_forwarded_for 這兩個變量是 nginx 的內置變量

$remote_addr 變量里面保存的是 b 反向代理服務器本身的 ip 地址

$proxy_add_x_forwarded_for 變量里面保存的是 a 客戶端電腦的 ip 地址

如果不設置這個變量的話,c 服務器實際上是不知道訪問請求的真實來源地址的

而設置了這個變量, c 服務器就可以知道這個訪問請求是哪一個ip地址發(fā)過來的

如圖,編輯 www.test.com 虛擬主機的配置文件

假設這個虛擬主機是我們要訪問的 c 服務器

location 里面設置了兩個echo 顯示訪問請求的來源地址,和真實來源地址

$remote_addr 記錄了反向代理服務器的地址

$proxy_add_x_forwarded_for 記錄了訪問請求的真實來源地址,也就是客戶端的地址

這樣設置,訪問這個虛擬主機的時候,就會顯示這兩個變量里面保存的值

保存退出,然后重載配置文件

如圖,編輯反向代理服務器虛擬主機的配置文件

如圖,可以看到 location 里面

proxy_set_header X-Real-IP 和 proxy_set_header X-Forwarded-For 這兩行是被注釋掉的

先做個測試,保存退出重載配置文件

如圖,使用 curl 測試從 192.168.133.140:80 發(fā)出訪問請求

192.168.133.140 這個 ip 實際就是 客戶端 ip

因為訪問請求就是從這個 ip 發(fā)出來的

但是可以看到,測試之后,實際顯示的卻是兩個 127.0.0.1 的回環(huán)地址

并沒有 192.168.133.140 這個 ip

在這個測試里面,反向代理服務器 和 真實服務器 都在本機上面

所以真實服務器 c 接收的訪問請求來源 ip 就是本機的回環(huán)地址

反向代理服務 b 發(fā)送請求給 真實服務器 c 走的就是 127.0.0.1 的內部回環(huán)地址

因為這兩個服務器都在本機上,本機上的程序之間通訊基本都是走 127.0.0.1 回環(huán)地址的

所以 c 的 $remote_addr 的值就是 127.0.0.1

因為反向代理服務器 b 沒有設置 $proxy_add_x_forwarded_for

所以真實服務器 c 的接收到的 $proxy_add_x_forwarded_for 變量值就是請求發(fā)送過來的 ip

也就是 127.0.0.1

$proxy_add_x_forwarded_for 這個變量實際上是記錄了從客戶端開始

請求總共經過了哪些 ip 地址的一個變量值,多個 ip 地址之間使用逗號分隔

如果發(fā)送的訪問請求沒有設置 $proxy_add_x_forwarded_for 這個變量的話

那么接收方的這個變量的值就只是訪問請求發(fā)送過來的上一個 ip , 也就是跟 remote_addr 相同

比如訪問請求從 a 到 b 到 c

如果 b 設置了 $proxy_add_x_forwarded_for 的話

那么這個變量的格式就是 a_ip, b_ip

也就是記錄了 a 的ip 和 b 的ip

如果中間還經過更多的服務器的話,那么它們的 ip 也會被記錄下來,使用逗號分隔

當然每一臺代理服務器都需要設置 $proxy_add_x_forwarded_for 這個變量才行

不然下一臺代理服務器的 $proxy_add_x_forwarded_for 這個變量將不會記錄到之前經過的 ip

只能夠記錄到上一臺服務器的 ip

所以在這個測試里面,因為 b 沒有設置 $proxy_add_x_forwarded_for

所以 c 服務的 $proxy_add_x_forwarded_for 變量的值等于 $remote_addr 的值

如圖,第二次測試,編輯反向代理服務器 b 的配置文件

把 location 里面的 X-Real-IP 和 X-Forwarded-For 兩行注釋去掉

保存退出重載配置文件

如圖,再次測試

可以看到返回的結果,第一行 remote_addr 的值是 127.0.0.1

這是 代理服務器 b 的 ip

第二行 $proxy_add_x_forwarded_for 的值是兩個 ip

curl 命令里面,訪問請求是從 192.168.133.140 發(fā)出的

也就是說,客戶端 a 的 ip 就是 192.168.133.140

b 的 ip 就是 127.0.0.1

$proxy_add_x_forwarded_for 記錄的是到達 c 的訪問請求經過了哪些 ip

訪問請求是從 a 到 b 再從 b 到 c 的

所以 $proxy_add_x_forwarded_for 變量 記錄了 a 的 ip 和 b 的 ip

因為訪問請求在到達 c 之前經過了這兩個 ip 地址

所以以后做反向代理的時候,這幾行變量都要設置

后面的真實服務器才能夠獲取到訪問請求的真實 ip 地址

反向代理04

如圖,redirect 應用的場景不多,主要有三種寫法

功能是修改被代理的服務器返回的 location 和 refresh 頭域信息

第一種寫法,redirect 是返回的頭域信息

replacement 是要修改的信息

redirect 會被修改為 replacement

第二種寫法是 default 就是默認設置的意思

第三種 off 意思就是關閉 redirect功能

如圖,做一個測試,編輯代理服務器的配置文件

要測試成功有幾個條件要達成

首先,location 后面只能是根目錄 / 不能是加別的

第二個條件是proxy_pass后面的 url 后面不能加 / 符號

正常來說是要 / 結尾的,但是這里不能用 / 結尾

然后訪問的目錄必須真實存在,如果不存在可以創(chuàng)建一個

然后再目錄里面也可以創(chuàng)建一個 index.html 文件,里面編輯一些字符串內容

保存退出重載一下配置文件

如圖,編輯被代理服務器的配置文件

寫成如圖所示的這種簡單格式

保存退出重載配置文件

如圖,curl 測試訪問的時候,如果 aming 后面加了 / 結尾,那么就會訪問到 index.html 文件

但是我們要訪問的是目錄本身,并不是里面的某個文件

所以 crul 的時候,訪問的地址結尾不能加上 / 符號

這樣就可以訪問到 aming 目錄了

可以看到,返回的代碼是 301 表示永久重定向

下面的 location 后面的字段,是帶端口8080 的訪問路徑

如圖,編輯被代理服務器的配置文件

添加 access_log /tmp/456.log

這樣就開啟了服務器的訪問日志,檢查訪問日志可以更清晰的了解訪問過程

保存退出重載

如圖,重新 curl 測試一次,這次測試 aming 結尾是帶 / 符號的

cat 查看 /tmp/456.log 訪問日志

發(fā)現日志信息沒有 host 和 端口 等信息

這種情況可以修改 nginx.conf 配置文件里面的 format 配置

如圖,配置文件里面 log_format main 這三行本來是被注釋掉的

現在把注釋去掉,讓這幾行產生作用,這個就是日志返回信息的格式設置

如圖,在最后面添加兩個nginx變量 $host $server_port 這兩個變量

然后保存退出重載一下,這樣訪問日志顯示的信息里面,就會加上這兩個變量的信息了

如圖,編輯代理服務器配置文件,同樣添加 access_log 配置

日志地址就是 /tmp/proxy.log

后面加上 main 因為 nginx.conf 里面配置的格式是用 main 命名的

這里加上main 表示使用 main 命名的格式來顯示日志信息

如圖,同樣被代理服務器里面的 access_log

后面也需要加上 main表示使用 main 的格式顯示日志信息

保存退出重載一下

如圖,curl 測試一下,這次測試是用 / 符號結尾的

查看 456.log 后端服務器的日志,可以看到,訪問的是 8080 端口

查看 proxy.log 代理服務器日志,可以看到,訪問的是 80 端口

網絡代碼都是 200 這樣是正常的

如圖,這次訪問 aming 結尾不帶 / 符號

可以看到返回的是 301

查看 proxy.log 返回的也是 301

如圖,重新測試一下,再查看兩個日志

看到 301 再到 200 的日志信息

總之確定了我們訪問 80 端口,跳轉到了 8080 端口

但是客戶端是訪問不到 8080 端口的

如圖,解決這個問題可以使用 proxy_redirect

這里是 http://$host:8080/ /;

這樣寫可以把本來返回的 8080 端口信息給去掉

保存退出重載

如圖,重新測試

可以看到,返回的是 301

然后 location 后面的地址里面,也沒有 8080 端口的信息存在了

反向代理05

proxy_buffering 是緩沖的意思

緩沖就是在內存里面劃一塊區(qū)域,在里面寫數據

寫到一定量的時候,才會把緩沖里面的數據寫進硬盤中

這樣做的話,就可以大大減少硬盤的讀寫頻率

如果不做緩沖,每產生一次數據都要讀寫一次硬盤,對于硬盤的負擔就會很大

假設有三個對象,客戶端 a 代理服務器 b 被代理服務器 c

a 發(fā)出請求,b 接收請求,轉發(fā)給 c

c 返回數據給 b ,然后 b 再把數據發(fā)給 a

這是一般的運作情況,但是如果 a 發(fā)出許多訪問請求

或者有很多個客戶端發(fā)出訪問請求

那么對于代理服務器 b 和 被代理服務器 c 來說

每個請求都要按照這個流程處理一次,負擔就會很重

proxy_buffering 就是在 代理服務器 b 的內存里面設置一個或多個緩沖區(qū)域

當緩沖區(qū)域數據量滿了的時候,才把數據轉發(fā)給相應的客戶端

這樣代理服務器 b 的數據轉發(fā)次數就大大減少了,負擔就下降了

當 proxy_buffering 開啟的時候,由 proxy_busy_buffer_size 來決定何時把數據發(fā)送給 a

在這個過程中,如果 buffer 區(qū)域被寫滿,有數據溢出

多出來的數據會被寫入到 temp_file 也就是一個臨時文件中去,這個文件會存儲在硬盤上

如果 proxy_buffering 關閉的話,c 反饋的數據就直接由 b 轉發(fā)給 a

而不會有別的操作發(fā)生

如圖,不管 proxy_buffering 是 on 還是 off 的狀態(tài)

proxy_buffer_size 這個選項都是生效的,這個參數是用來設置一個 buffer

這個 buffer 存儲了服務器反饋的 header 信息

如果設置不夠大,存儲不了 header 信息的話,會出現 502 錯誤碼

所以建議設置為 4k

如圖, proxy_buffers 是定義每個請求的 緩沖區(qū)個數 和 每個緩沖區(qū)的具體大小

這里定義了 8 4k 意思就是有 8個緩沖區(qū),每個緩沖區(qū)的大小為 4k

那么總緩沖區(qū)的大小就是 8*4 = 32 k

假設有一萬個請求,那么緩沖區(qū)就是 8 * 10000 個緩沖區(qū)了

因為這個設置是針對每個請求來的,而不是總共只有 8 個緩沖區(qū)

proxy_busy_buffer_size 定義的是達到多少數據量,就把數據傳輸給客戶端

這里定義的是 16k ,那么當 b 的屬于這個請求的緩沖區(qū)接收到 16k 的數據量的時候

就會把數據轉發(fā)給 a

這里緩沖區(qū)有 8 個,總共 32k 的大小,緩沖區(qū)一般來說處于兩種狀態(tài)

一個是接收數據,一個是發(fā)送數據,并不能同時接收數據和發(fā)送數據

proxy_busy_buffer_size 定義的就是 發(fā)送數據的緩沖區(qū)的大小

所以 proxy_busy_buffer_size 的大小要比緩沖區(qū)的總大小要小才行

接收的數據達到 proxy_busy_buffer_size 設置的數據量的時候

這些緩沖區(qū)就進入發(fā)送數據的狀態(tài),剩下的緩沖區(qū)則是接收數據的狀態(tài)

如果請求反饋的數據總量小于 proxy_busy_buffer_size 設置的值

那么 b 接收完成就會直接轉發(fā)為 a

如果請求反饋的數據總量大于 proxy_busy_buffer_size 設置的值

那么當緩沖區(qū)接收的數據量達到 proxy_busy_buffer_size設置的值的時候

就會把這部分的數據先發(fā)送給 a

如圖,proxy_temp_path 定義的是臨時文件存放目錄

舉例,a 發(fā)出請求,b代理服務器分配給 a 這個請求的 緩沖區(qū) 總大小為 32k

但是 c 服務對這個請求反饋的數據量為 100 MB 這么大,遠遠超過緩沖區(qū)的大小

這種情況下, b 接收 c 的數據的過程中就會有很多數據溢出緩沖區(qū)

這些溢出的數據會被先保存到 b 的硬盤上的臨時文件里面去

proxy_temp_path 定義的就是這個臨時文件存放的路徑,還有子目錄層級

這里定義的路徑是 /usr/local/nginx/proxy_temp 這是一個目錄名稱

臨時文件就會存放到這個目錄里面去

后面的數字 1 2 表示子目錄層級

前面的目錄路徑是由我們自己定義的,子目錄是系統自動創(chuàng)建的

創(chuàng)建多少個子目錄層級,可以通過后面的數字設置

比如 只寫一個 1 就表示子目錄只有一層,子目錄的名稱為 0-9 的命名方式

根據定義,proxy_temp_path 支持三級子目錄,也就是可以寫 3 個數字

比如寫 1 子目錄數量和命名方式 就是 0- 9 共10個

如果寫 2 就是 00-99 共100個,如果寫 3 就是 000-999 共1000個子目錄

子目錄名稱也是根據這些數字來命名的

如果寫 1 3 就表示子目錄分兩層,第一層是 0-9 10個子目錄

第二層是 000-999 1000個子目錄,也可以反過來寫 3 1

這樣第一層就是 1000 個子目錄,每個目錄下面第二層又有 10 個子目錄

proxy_max_temp_file_size 定義的是 臨時文件的總大小

比如這里設置為 100M 說明每個臨時文件最大為 100M

臨時文件的數據如果傳輸完成,就會自動刪除

proxy_temp_file_write_size 定義的是同時寫入臨時文件數據量的總大小

這里定義一個值比如 8k 或者 16k

如果同時寫入的數據量低于這個值,那么就增加同時寫入的數據量

如果高于這個值,那么就減少同時寫入的數據量

因為同時寫入的數據量太高,對于硬盤 IO 負擔太大,而太小則沒有充分用到硬盤的性能

所以設置一個值,既不會太快,也不會太慢,充分使用到硬盤的性能,又不會負擔過重

如圖,這是一個使用 proxy_buffering 的例子

首先是設置為 on 的狀態(tài),也就是打開 buffer 功能

頭文件存儲的 buffer區(qū)域大小為 4k

然后是其它數據的 buffer 區(qū)域為 2 個,每個大小為 4k

然后是 busy_buffers 的數據量為 4k

buffer 接收的數據量達到 4k 時就會發(fā)送數據

然后是臨時文件存放的路徑定義,定義了兩層子目錄

分別是 1 2 也就是 第一層有 0-9 10個子目錄

然后每個子目錄下面 第二層有 00-99 100個子目錄

然后是每個臨時文件的大小為 20M

然后是臨時文件同時寫入的數據量定義為 8k

反向代理06

如圖,要使用 proxy_cache 首先要打開 proxy_buffering 功能

proxy_cache 就是緩存功能

客戶端 a 發(fā)出請求,如果 a 請求的數據已經保存到 代理服務器 b 的緩存里面的話

那么 b 會把相關數據直接發(fā)送給 a 而不會去向 服務器 c 請求數據

如果不開啟緩存功能,那么 a 的每一次請求,代理服務器 b 都會向 服務器 c 請求獲取一次數據

如果 a 兩次請求的數據是一樣的,也會向 服務器 c 請求兩次數據

開啟緩存功能的話,第一次請求的數據已經被保存到 緩存里面了,第二次如果請求同樣的數據

b 就會直接從緩存里面獲取,而不會去向 c 獲取數據,這樣就減輕了 服務器 c 的負擔

總結,緩沖可以減輕 代理服務器b 的負擔,緩存可以減輕 被代理服務器 c 的負擔

如圖,proxy_cache 功能的開啟與關閉

proxy_cache off 意思就是關閉緩存功能

proxy_cache zone 就是開啟緩存區(qū),zone 就是緩存區(qū)的名稱

緩存區(qū)名稱是可以任意命名的,可以是 zone 也可以是 123 等任意名稱

這里寫一個緩存區(qū)名稱就表示了開啟一個以這個名稱命名的緩存區(qū)

從 nginx 0.7.66 版本開始,開啟 proxy_cache 之后

還會檢測被代理服務器的 http 響應頭中的 Cache-Control ,Expire 頭域

如果 cache-control 的值為 no-cache 時,那么這個請求的數據是不會被緩存的

如圖,curl -I 一個網站請求數據

可以看到,返回的頭文件信息,Cache-Control 后面的值里面

存在 no-cache ,表示這個請求返回的數據是不會被緩存的

如圖,proxy_cache_bypass 這個參數是設置某種情況下

請求的數據不從 cache 中獲取,而是直接從后端服務器中獲取

這個參數后面的 string 一般為 nginx 的一些變量

比如 proxy_cache_bypass $cookie_nocache $arg_nocache $arg_comment;

這樣設置就表示,這三個變量的值,任意一個不為 0 或 空 的情況下

響應數據就不會從 cache 中獲取,而是直接從后端服務器獲取

暫時很少用到,了解一下即可

如圖,proxy_no_cache 跟上面的參數用法相似

主要是設置某種情況下,獲取的數據不進行緩存

示例 proxy_no_cache $cookie_nocache $arg_nocache $arg_comment;

這樣設置就表示,當后面這三個變量任意一項的值不為 0 或者 空 的時候

獲取的數據都不進行緩存

如圖,這個參數格式跟上面的參數差不多,一般不需要設置,保持默認就可以了

如圖,proxy_cache_path 是設置緩存區(qū)具體配置的參數

緩存除了內存中的空間外,還可以在硬盤中劃出一塊空間來做緩存

path 就是指定一個目錄路徑作為緩存路徑,緩存會存放到這里面

levels=1:2 這個表示目錄層級,第一個數字設置的是第一層

第二個數字設置的是第二層

1 表示 0-9 a-f 總共16個字符,每個目錄由單個字符組成,一共16個目錄

2 表示 0-9 a-f 總共16個字符,但是每個目錄由兩個字符組成,00,01,04,2f 之類的,有兩百多種組合

總之這個參數是設置子目錄層級,第一個數字表示第一層

第二個數字表示第二層

keys_zone 是設置內存zone 的名稱和大小

keys_zone=my_zone:10m 就表示zone的名稱叫做 my_zone

然后 zone 的大小是 10MB

inactive 是設置多長時間后,把緩存刪除

比如圖中設置為 300s 意思就是,如果數據在 300秒內沒有被訪問過

那么這個數據就會從緩存中刪除

max_size 是設置硬盤中的緩存最多可以存儲多少數據

比如這里設置為 5g ,上面設置的目錄 /data/nginx_cache/

這個硬盤上的目錄,最多可以存放 5g 的數據,如果超過這個量

系統就會先把訪問量最少的數據刪除,再放新的數據進去

proxy_cache_path 這行代碼不能寫在 配置文件的 server 括號內

要寫在 http 括號里面

舉例說明,首先編輯 nginx.conf 配置文件

如圖,在 server 的外面添加 proxy_cache_path 代碼

如圖,

因為指定的緩存目錄 /data/nginx_cache/ 不存在,所以這里要創(chuàng)建一下

如圖,編譯一個虛擬主機的配置文件,在location 里面添加 proxy_cache my_zone;

這樣這個虛擬主機接收請求的時候,就會使用 my_zone 這個緩存空間了

而 my_zone 緩存空間的具體定義已經在 nginx.conf 配置文件里面作了定義

nginx.conf 里面的配置內容對所有虛擬主機都是有效的

所以在 nginx.conf 里面定義了 my_zone 的話

那么在所有虛擬主機配置文件里面使用 proxy_cache my_zone

這些虛擬主機就都可以使用到 my_zone 這個緩存空間

然后保存退出重載配置文件就可以生效了

平時使用,只需要添加這樣兩行代碼就成功配置好緩存了

如圖,還有一個問題就是,nginx 服務本身的權限是 nobody

剛才的目錄是使用 root 權限創(chuàng)建的

所以這里要把 緩存目錄 的所有者所屬組修改成 nobody

這樣nginx 服務操作這個目錄的時候就不會有權限問題了

如圖,查看 /data/nginx_cache/ 目錄內容

可以看到 0-9 a-f 的第一級目錄

進入 0 目錄內查看,可以看到由兩位數構成的 第二級目錄

總結,緩存空間配置主要就是定義 proxy_cache_path

可以在 nignx.conf 里面定義,這樣任何虛擬主機都可以使用到

定義好 proxy_cache_path 后,在需要使用緩存的虛擬主機 server內

配置 proxy_cache zone_name

zone_name 就是 proxy_cache_path 里面定義好的緩存空間名稱

這樣對應的虛擬主機就可以使用這個緩存空間了

以上就是nginx正向代理與反向代理詳解的詳細內容,更多關于nginx正向代理與反向代理的資料請關注腳本之家其它相關文章!

標簽:回訪 廊坊 紅河 廣安 德州 湛江 滁州 巴彥淖爾

巨人網絡通訊聲明:本文標題《nginx正向代理與反向代理詳解》,本文關鍵詞  nginx,正向,代理,與,反向,;如發(fā)現本文內容存在版權問題,煩請?zhí)峁┫嚓P信息告之我們,我們將及時溝通與處理。本站內容系統采集于網絡,涉及言論、版權與本站無關。
  • 相關文章
  • 下面列出與本文章《nginx正向代理與反向代理詳解》相關的同類信息!
  • 本頁收集關于nginx正向代理與反向代理詳解的相關信息資訊供網民參考!
  • 推薦文章