目錄
一,正向代理
1,編譯安裝Nginx
(1)安裝支持軟件
(2)創建運行用戶,組和日志目錄
(3)編譯安裝Nginx
(4)添加Nginx系統服務
2,配置正向代理
(1)編輯主配置文件添加正向代理相關配置
(2)驗證正向代理
二,反向代理
1,配置nginx七層代理
(1)環境安裝
(2)配置nginx七層代理轉發
(3)驗證轉發效果
2,配置nginx四層代理
(1)配置四層代理
(2)驗證四層代理
三,Nginx緩存
1,緩存功能的核心原理和緩存類型
2,代理緩存功能設置
(1)反向代理配置
(2)設置緩存功能
四,Nginx rewrite和正則
1,Nginx正則
2,nginx location
(1)location 的語法
3,Rewrite
(1)Rewrite 語法
一,正向代理
正向代理(Forward Proxy)是一種位于客戶端和原始服務器之間的代理服務器,其主要作用是將客戶端的請求轉發給目標服務器,并將響應返回給客戶端Nginx的正向代理充當客戶端的“中間人”,代表用戶訪問外部資源并隱藏真實IP它是企業內網管控、安全審計與加速訪問的核心工具。用于場景一般是:
內網訪問控制: | 限制員工訪問特定網站(如社交媒體) |
匿名訪問: | 通過代理服務器隱藏用戶真實身份。 |
資源緩存加速: | 緩存公共資源(如軟件包、鏡像文件),減少外網帶寬消耗。 |
1,編譯安裝Nginx
Nginx的配置及運行需要pcre、zlib等軟件包的支持,因此應預先安裝這些軟件的開發包(devel),以便提供相應的庫和頭文件,確保ginx的安裝順利完成。
(1)安裝支持軟件
(2)編譯安裝Nginx
配置Nginx的編譯選項時,將安裝目錄設為/usr/local/nginx,運行用戶和組均設為nginx;啟用http_stub_status_module模塊以支持狀態統計,便于查看服務器的連接信息。具體項根據實際需要來定,配置前可參考“./configure--help”給出的說明。
--user=nginx | #指定nginx運行用戶 |
--group=nginx | #指定nginx運行組 |
--with-http ssl module | #支持https:// |
--with-http_v2_module | #支持http版本2 |
--with-http realip module | #支持ip透傳 |
--with-http_stub_status_module | #支持狀態頁面 |
--with-http_gzip_static module | #支持壓縮 |
--with pcre | #支持正則 |
--with-stream | #支持tcp反向代理 |
--with-stream ssl module | #支持tcp的ssl加密 |
--with-stream realip module | #支持tcp的透傳ip |
--add-module=./ngxhttp proxy connect module | #支持https轉發(默認nginx不支持https轉發,需要添加第三方模塊) |
為了使Nginx服務器的運行更加方便,可以為主程序nginx創建鏈接文件,以便管理員直接執行“nginx”命令就可以調用Nginx的主程序。
(3)添加Nginx系統服務
2,配置正向代理
(1)編輯主配置文件添加正向代理相關配置
(2)驗證正向代理
二,反向代理
Nginx的七層(應用層)反向代理基于HTTP/HTTPS協議,深度解析應用層內容(如URL、Header、Cookie),將客戶端請求精準轉發至后端服務器。作為企業級架構的“智能調度器”,它實現了負載均衡、安全隔離與性能優化的核心能力。應用場景一般是:
負載均衡: | 將流量分發至多臺后端服務器,避免單點故障。 |
動靜分離: | 靜態資源(圖片、CSS/JS)由Nginx直接響應,動態請求(PHP、API)轉發至Apache/Tomcat. |
SSL終端: | 統一處理HTTPS加密/解密,降低后端服務器計算壓力。 |
灰度發布 | :根據請求特征(如IP、Header)將部分流量導向新版本服務。 |
Nginx的四層(網絡層)反向代理基于TCP/UDP協議,直接轉發原始數據流,不解析應用層內容。它專為高性能、低延遲的傳輸層場景設計,是數據庫、游戲服務器等非HTTP服務的理想選擇。應用場景一般是:
數據庫代理: | 對外暴露統一端口,內部轉發至MySQL、Redis集群。 ? |
游戲服務器: | 代理UDP協議,實現實時數據包負載均衡。 |
SSH跳板機: | 通過端口映射安全訪問內網服務器。 |
高可用服務: | TCP服務(如MQTT)的主備切換與健康檢查。 |
反向代理,指的是瀏覽器/客戶端并不知道自己要訪問具體哪臺目標服務器,只知道去訪問代理服務器,代理服務器再通過反向代理+負載均衡實現請求分發到應用服務器的一種代理服務。
反向代理服務的特點是代理服務器代理的對象是應用服務器,也就是對于瀏覽器/客戶端 來說應用服務器是隱藏的。
1,配置nginx七層代理
通過配置nginx七層代理實現轉發nginx請求至后端的httpd服務,通過該轉發也能實現nginx+httpd的動靜分離,動靜分離會在后續章節介紹
(1)環境安裝
(2)配置nginx七層代理轉發
上述配置中,使用upstream定義后端應用服務器的地址池“backend”,在location塊中,使用proxy_pass,轉發請求至后端地址池,proxy_set_header Host $host:將請求中的Host頭部設置為客戶端請求的主機名,proxy_set header X-Real-IP$remote_addr:將請求中的X-Real-IP頭部設置為客戶端的真實IP地址。
(3)驗證轉發效果
后端地址池中也可以定義多臺主機,實現負載均衡
2,配置nginx四層代理
SSH協議是基于TCP協議的,配置nginx的四層代理,實現代理ssh請求至后端服務器,用以登錄內網服務器場景
(1)配置四層代理
配置文件
(2)驗證四層代理
第二臺驗證
三,Nginx緩存
Nginx的緩存功能是其核心能力之一,主要用于加速內容響應和降低后端服務器負載它的緩存功能主要基于反向代理(ProxyCache),但也可用于其他場景(如FastCGI 緩存)。以下是詳細解析:
1,緩存功能的核心原理和緩存類型
緩存類型 | 作用場景 |
代理緩存 | 反向代理模式下緩存后端服務器(如Tomcat、Apache)的響應內容。 |
FastCGI 緩存 | 緩存PHP/Python等通過FastCG協議處理的動態內容(需配合PHP-FPM使用)。 |
uWSGI/SCGI 緩存 | 似 FastCGI,用于其他后端協議。 |
靜態資源緩存 | 通過 expires指令設置客戶端瀏覽器緩存(非服務端緩存)。 |
代理緩存原理:
第一步:客戶端第一次向Nginx請求數據A;
第二步:當Nginx發現緩存中沒有數據A時,會向服務端請求數據A:
第三步:服務端接收到Nginx發來的請求,則返回數據A到Nginx,并且緩存在Nginx;
第四步:Nginx返回數據A給客戶端應用:
第五步:客戶端第二次向Nginx請求數據A:
第六步:當Nginx發現緩存中存在數據A時,則不會請求服務端;第七步:Nginx把緩存中的數據A返回給客戶端應用。
2,代理緩存功能設置
因代理緩存功能需在反向代理模式下緩存啟端服務器(如Tomcat、Apache)的響應內容需要先配置七層反向代理
(1)反向代理配置
(2)設置緩存功能
關鍵配置解析
proxy_cache_path: | 定義緩存文件的存儲路徑 |
levels=1:2: | 定義緩存目錄的層級結構,1evels=N:M,表示緩存文件路徑的層級深度 |
keys_zone=my_cache:10m? | 定義共享內存區域,用于存儲緩存鍵(key)和元數據(如過期時間),10m:共享內存區大小(通常每1MB可存儲約8000個鍵) |
inactive=60m | :定義緩存內容的閑置有效期。60分鐘內未被訪問,將被自動刪除 |
max size=1g: | 定義緩存目錄的最大磁盤空間。當緩存量達到1GB 時,Nginx 啟動 LRU(最近最少使用)算法清理舊緩存。 |
use_temp path=off : | 控制臨時文件的存儲位置,推薦值:off(減少磁盤操作,提升性能) |
(3)驗證緩存功能
curl -r 192.168.10.101
四,Nginx rewrite和正則
已成為現代Web服務的核心組件之一。它不僅是負載均衡、反向代理的首選工具,更是實現流量調度、安全防護和動態路由的關鍵樞紐。而在這其中,Rewrite模塊作為Nginx的“規則引擎”,扮演著至關重要的角色--它賦予開發者精準控制URL的能力,讓請求的流轉不再受限于物理路徑,而是通過邏輯規則靈活適配業務需求。
Rewrite的應用場景
路徑美化:將/product/123轉換為/index.php?id=123
舊鏈接遷移:將過期URL永久重定向(301)到新地址強制HTTPS/域名統一:自動跳轉http://到https://,或合并www與非www域名動態路由:適配單頁應用(SPA)、RESTfuIAPI路由灰度發布:按規則將部分流量導向新版本服務
1,Nginx正則
學習Rewrite之前要熟悉正則表達式,表中列舉出一些常用的正則表達式元事符
字符 | 描述 |
^ | 匹配輸入字符串的起始位置 |
$ | 匹配輸入字符串的結束位置 |
* | 匹配前面的字符零次或多次。如"ol“"能匹配"o"及“ol”、"ol" |
+ | 匹配前面的字符一次或多次。如“ol+“能匹配"ol"及"oI"、“o“”,但不能匹配“o” |
? | 匹配前面的字符零次或一次,例如"do(es)?"能匹配“do"或者“does","?“等效于”(0,1} |
. | 匹配除“""之外的任何單個字符,若要匹配包括“""在內的任意字符,請使用諸如“[\n]之類的模式 |
\ | 將后面接著的字符標記為一個特殊字符或一個原義字符或一個向后引用。如\匹配個換行符,而“\$"則匹配“$” |
\d | 匹配純數字 |
{n} | 重復n次 |
{n,} | 重復n次或更多次 |
{n,} | 匹配單個字符c |
[a-z] | 匹配 a-z小寫字母的任意一個 |
[a-zA-Z] | 匹配a-z小寫字母或A-Z大寫字母的任意一個 |
2,nginx location
在學習rewrite前還要了解下location,因為rewrite 通常會與 location 結合使用,但并非絕對。二者的協作能實現更精細的路徑控制,1ocation是Nginx中用于匹配請求URI(路徑:只能對域名后邊的除去傳遞的參數外的字符串起作用,例如http://www.kgc.com/index.php?id=1 只匹配/index.php)的核心指令,用于根據請求路徑定義不同的處理邏輯(如靜態資源服務、反向代理、重定向等)
(1)location 的語法
location[匹配模式]{
#處理邏輯(如root,proxy_pass,rewrite等)
匹配模式類型:
模式 | 說明 |
location /uri普通前綴匹配: | 匹配以指定路徑開頭的 URI |
location=/精確匹配: | 僅匹配完全相同的URI(優先級最高)。 |
location~ ? | 區分大小寫的正則表達式匹配。 |
location~*正則匹配: | 不區分大小寫的正則表達式匹配。 |
location·~ | 精確前綴匹配:匹配前綴路徑后,不再檢查正則匹配(優先級高于正則)。 |
location/通用匹配: | 默認方式,優先級最低,其他方式匹配不到時匹配 |
location 的優先級規則:
精確匹配 〉精確前綴匹配 〉正則匹配( 和 *同時存在時,文件中物理位置靠上的優先)>普通前綴匹配>通用匹配。
3,Rewrite
(1)Rewrite 語法
rewrite<regex><replacement>[flag];
regex:正則匹配URL字符串(只能對域名后邊的除去傳遞的參數外的字符串起作用,例如
http://www.kgc.com/index.php?id=l 只對/index.php 重寫)
replacement:重寫跳轉后的地址
flag類型:
last: | 重寫后的URI 會重新觸發的指令,是默認類型 |
break: | 重寫后的URI不會重新匹配location,直接在當前location中處理,且后續的 rewrite 指令不再執行 |
redirect: | 返回302臨時重定向,瀏覽器地址會顯示跳轉后的URL地址,爬蟲不會更新url(因為是臨時) |
permanent: | 返回301永久重定向,瀏覽器地址欄會顯示跳轉后的URL地址,爬蟲更新url 。 |
在實際工作的應用中,Nginx跳轉需求有三種方式可實現。可以直接用rewrite進行匹配跳轉,也可以使用if匹配全局變量后跳轉。另外,還可以使用1ocation匹配再跳轉所以rewrite 只能放在 server、if{}、location{}配置段中
1.server{}塊中的rewrite
執行順序:在請求進入server塊后、匹配location前執行。
作用域:影響該server塊下所有請求(全局生效)。
2.location{}塊中的rewrite執行順序:在請求匹配到該location后執行。
作用域:僅對該location匹配的請求生效(局部生效)。
3.if{}塊中的 rewrite
執行順序:在滿足if 條件時觸發。
作用域:依賴if表達式所在的上下文(如在server中或location中)。