目录
掌握nginx的反向代理
掌握nginx的正向代理
掌握nginx的缓存
了解nginx的rewrite正则表达式
前言
Nginx作为一款高性能的开源Web服务器和反向代理工具,凭借其轻量级、高并发处理能力和灵活的模块化设计,已成为现代Web架构的基石。从全球顶尖网站到微服务架构,Nginx在负载均衡、缓存加速、安全防护等场景中扮演着关键角色。本课程聚焦Nginx的四大核心功能-一反向代理(七层/四层)、正向代理、缓存机制和正则表达式匹配,通过理论解析与场景化案例,深入掌握其设计思想与实践技巧,为构建高效、稳定的Web服务奠定坚实基础。
一：正向代理
正向代理(Forward Proxy)是一种位于客户端和原始服务器之间的代理服务器,要作用是将客户端的请求转发给目标服务器,并将响应返回给客户端Nginx 的 正向代理 充当客户端的“中间人”,代表用户访问外部资源并隐藏真实它是企业内网管控、安全审计与加速访问的核心工具。用于场景一般是:
| > 内网访问控制: | 限制员工访问特定网站(如社交媒体) |
| > 匿名访问: | 通过代理服务器隐藏用户真实身份。 |
| > 资源缓存加速: | 缓存公共资源(如软件包、镜像文件),减少外网带宽消耗。 |
1.编译安装nginx
Nginx 的配置及运行需要pcre、zlib 等软件包的支持,因此应预先安装这些软件的开发包(devel),以便提供相应的库和头文件,确保Nginx 的安装顺利完成。
(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的ss1加密 -- with-stream_realip_module # 支持tcp的透传ip -- add-module =. /ngx_http_proxy_connect_module #支持https转发(默认nginx不支持https转发,需要添加第三方模块)
为了使 Nginx 服务器的运行更加方便,可以为主程序nginx 创建链接文件,以便管理员直接执行“nginx”命令就可以调用 Nginx 的主程序。
(3)添加 Nginx 系统服务 
2.配置正向代理
（1）编写主配置文件添加正向代理相关配置
（2）验证正向代理
使用Linux验证使用curl命令，并指定代理服务器进行测试访问
二 反向代理
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七层代理
（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 的缓存功能是其核心能力之一,主要用于加速内容响应和降低后端服务器负载。它的缓存功能主要基于反向代理(Proxy Cache),但也可用于其他场景(如FastCGI 缓存)。以下是详细解析:
1. 缓存功能的核心原理和缓存类型
缓存类型
代理 缓存
FastCGI 缓存
uWSGI/SCGI 缓存
静态资源缓存 通过expires 指令设置客户端浏览器缓存(非服务端缓存)。
作用场景
反向代理模式下缓存后端服务器(如Tomcat、Apache)的响应内容。
缓存 PHP/Python 等通过 FastCGI 协议处动态内容(需配合 PHP-FPM使用)。
类似于 fastcgi 用于其他后端协议
代理缓存原理
第一步:客户端第一次向Nginx请求数据A; 第二步:当Nginx发现缓存中没有数据A时,会向服务端请求数据A; 第三步:服务端接收到Nginx发来的请求,则返回数据A到Nginx,并且缓存在Nginx; 第四步:Nginx返回数据A给客户端应用; 第五步:客户端第二次向Nginx请求数据A; 第六步:当Nginx发现缓存中存在数据A时,则不会请求服务端; 第七步:Nginx把缓存中的数据A返回给客户端应用。
2.代理缓存功能设置
因代理缓存功能需在反向代理模式下缓存后端服务器(如Tomcat、Apache)的响应内容。需要先配置七层反向代理
(1)反向代理配置 和设置缓存功能
关键配置解析
>proxy_cache_path: 定义缓存文件的存储路径 >levels=1:2:定义缓存目录的层级结构 定义缓存目录的层级结构,levels=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 -I 192.168.1.101
四 nginx rewrite和正则
在云计算与分布式架构的时代,Nginx 凭借其高性能、高并发处理能力以及模块化设计,已成为现代Web服务的核心组件之一。它不仅是负载均衡、反向代理的首选工具,更是实现流量调度、安全防护和动态路由的关键枢纽。而在这其中,Rewrite模块作为Nginx的“规则引擎”,扮演着至关重要的角色-一它赋予开发者精准控制URL的能力,让请求的流转不再受限于物理路径,而是通过逻辑规则灵活适配业务需求。
Rewrite的应用场景
路径美化:将/product/123 转换为 /index.php?id=123 旧链接迁移:将过期URL永久重定向(301)到新地址 强制HTTPS/域名统一:自动跳转http://到https://,或合并www与非www域名 动态路由:适配单页应用(SPA)、RESTful API路由 灰度发布:按规则将部分流量导向新版本服务 1.nginx正则l
字符 描述 ^
匹配输入字符串的起始位置 $ 匹配输入字符串的结束位置 * 匹配前面的字符零次或多次。如“ol*”能匹配“o”及“ol”、“oll” + 匹配前面的字符一次或多次。如“ol+”能匹配“ol”及“oll”、“oll”,但不能匹配“o” ? 匹配前面的字符零次或一次,例如“do(es)?”能匹配“do”或者“does”,“?”等效于”{0,1}” . 匹配除“\”之外的任何单个字符,若要匹配包括“\n”在内的任意字符,请使用诸如“[.\n]”
之类的模式\ 将后面接着的字符标记为一个特殊字符或一个原义字符或一个向后引用。如“\n”匹配一
个换行符,而“1$”则匹配“$”\d 匹配纯数字 {d} 重复n次 {n} 重复n次或更多次 {c} 匹配单个字符c [a-z] 匹配a-z小写字母的任意一个 [a-zA-Z] 匹配a-z小写字母或A-Z大写字母的任意一个
2. nginx location
在学习rewrite前还要了解下location,因为rewrite 通常会与 location 结合使用,但并非绝对。二者的协作能实现更精细的路径控制,location是Nginx 中用于匹配请求URI(路径:只能对域名后边的除去传递的参数外的字符串起作用,例如http://www.kgc.com/index.php?id=1 只匹配/index.php)的核心指令,用于根据请求路径定义不同的处理逻辑(如静态资源服务、反向代理、重定向等)
(1)location 的语法
|
匹配模式
模式 说明
location/uri普通前缀匹配:匹配以指定路径开头的 URI。
location=/精确匹配:仅匹配完全相同的 URI(优先级最高)。
location~正则匹配:区分大小写的正则表达式匹配。
location ~* 正则匹配:不区分大小写的正则表达式匹配。location^~精确前缀匹配:匹配前缀路径后,不再检查正则匹配(优先级高于正则)。
location /通用匹配:默认方式,优先级最低,其他方式匹配不到时匹配
location 的优先级规则
精确匹配>精确前缀匹配>正则匹配(~和 ~* 同时存在时,文件中物理位置靠上的优先)>普通前缀匹配>通用匹配。
3 rewrite
(1)rewrite 语法
rewrite <regex> <relacement> <flag
regex:正则匹配URL字符串(只能对域名后边的除去传递的参数外的字符串起作用,例如
http://www.kgc.com/index.php?id=1 只对/index.php 重写)
replacement:重写跳转后的地址
flag类型:
last:重写后的 URI 会重新触发 匹配,并执行新匹配到的location块中的指令,是默认类型Rv
break:重写后的 URI 不会重新匹配location,直接在当前直接在当前location中处理,rewrite 且后续的rewrite指令不再执行
redirect:返回302临时重定向,浏览器地址会显示跳转后的URL地址,爬虫不会更新ur1(因为是临时)
permanent:返回301永久重定向,浏览器地址栏会显示跳转后的URL 地址,爬虫更新
urllocation,location,直接在当前
在实际工作的应用中,Nginx 跳转需求有三种方式可实现。可以直接用 rewrite 进行
匹配跳转,也可以使用if 匹配全局变量后跳转。另外,还可以使用location 匹配再跳转。
所以rewrite 只能放在 server{}、if{}、location+配置段中
（1）server{} 块中的 rewrite
执行顺序:在请求进入server块后、匹配location前执行。作用域:影响该server块下所有请求(全局生效)。