目录
一.正向代理
1.编译安装
(1)安装支持软件
(2)创建运行用户、组和日志目录
(3)编译安装 Nginx配置Nginx的编译选项时，将安装目录设为/usr/local/nginx，运行用户和组均设为nginx;启用 http stub status module 模块以支持状态统计，便于査看服务器的连接信息。具体选项根据实际需要来定，配置前可参考“./configure --help”给出的说明。
(4)添加Nginx系统服务为了使 Nginx 服务的启动、停止、重载等操作更加方便,可以编写 Nginx 服务脚本，并使用 chkconfig 和 systemctl 工具来进行管理。
2.配置正向代理
(1)编辑主配置文件添加正向代理相关配置:
(2)验证正向代理:
二.反向代理
1.配置nginx七层代理
(1)环境安装
(2)配置nginx七层代理转发
(4)验证转发效果
2.配置nginx四层代理
(1)配置四层代理
(2)验证四层代理
三.Nginx缓存
1.缓存功能的核心原理和缓存类型
2.代理缓存功能设置
四.Nginx rewrite和正则
1.Nginx正则
2.nginx location
3.Rewrite
（1）Rewrite 语法与参数
（2） Rewrite Flag 类型
（3） Rewrite 配置段与作用域
（4）实际应用场景对比
一.正向代理
正向代理(Forward Proxy)是一种位于客户端和原始服务器之间的代理服务器，其主要作用是将客户端的请求转发给目标服务器，并将响应返回给客户端Nginx的 正向代理 充当客户端的“中间人”，代表用户访问外部资源并隐藏真实 IP。它是企业内网管控、安全审计与加速访问的核心工具。用于场景一般是:
内网访问控制:限制员工访问特定网站(如社交媒体)
匿名访问:通过代理服务器隐藏用户真实身份。
资源缓存加速:缓存公共资源(如软件包、镜像文件)，减少外网带宽消耗
1.编译安装
(1)安装支持软件
Nginx 的配置及运行需要 pcre、zlib 等软件包的支持，因此应预先安装这些软件的开发包(devel)，以便提供相应的库和头文件，确保 Nginx 的安装顺利完成。
(2)创建运行用户、组和日志目录
Nginx 服务程序默认以 nobody 身份运行，建议为其创建专门的用户账号，以便更准确地控制其访问权限，增加灵活性、降低安全风险。例如，创建一个名为 nginx 的用户，不建立宿主文件夹，也禁止登录到 Shell 环境。
(3)编译安装 Nginx
配置Nginx的编译选项时，将安装目录设为/usr/local/nginx，运行用户和组均设为nginx;
启用 http stub status module 模块以支持状态统计，便于査看服务器的连接信息。具体选项根据实际需要来定，配置前可参考“./configure --help”给出的说明。
| 参数 | 说明 |
|---|---|
--user=nginx | 指定Nginx运行用户为nginx |
--group=nginx | 指定Nginx运行组为nginx |
--with-http_ssl_module | 启用HTTPS支持（SSL/TLS加密） |
--with-http_v2_module | 支持HTTP/2协议（提升性能和多路复用） |
--with-http_realip_module | 支持IP透传（从代理服务器获取真实客户端IP） |
--with-http_stub_status_module | 启用状态页面（用于监控Nginx运行状态） |
--with-http_gzip_static_module | 支持静态文件预压缩（提升传输效率） |
--with-pcre | 支持正则表达式（用于路由匹配等） |
--with-stream | 支持TCP/UDP反向代理（四层负载均衡） |
--with-stream_ssl_module | 为TCP/UDP代理启用SSL加密 |
--with-stream_realip_module | 支持TCP/UDP代理的IP透传（获取真实客户端IP） |
--add-module=./ngx_http_proxy_connect_module | 添加第三方模块以支持HTTPS转发（默认Nginx不支持代理HTTPS请求） |
为了使 Nginx 服务器的运行更加方便,可以为主程序 nginx 创建链接文件,以便管理员直接执行“nginx”命令就可以调用 Nginx 的主程序。
(4)添加Nginx系统服务
为了使 Nginx 服务的启动、停止、重载等操作更加方便,可以编写 Nginx 服务脚本，并使用 chkconfig 和 systemctl 工具来进行管理。
2.配置正向代理
(1)编辑主配置文件添加正向代理相关配置:
(2)验证正向代理:
Windows中验证，使用火狐浏览器，设置http和https代理即可。
Linux中验证，使用curl命令，并指定代理服务器进行访问测试。
通过实时查看nginx的访问日志，可以看到Windows下设置代理IP和端口后，本地电脑访问的所有网页会通过代理服务器进行访问网页,实现了正向代理的功能，并且隐藏了用户自己真实的IP
二.反向代理
| 类型 | 协议支持 | 工作原理 | 核心能力 | 典型应用场景 |
|---|---|---|---|---|
| 七层反向代理 | HTTP/HTTPS | 深度解析应用层内容（URL、Header、Cookie等），智能转发请求。 | 负载均衡、动静分离、SSL终端、灰度发布、缓存加速、安全防护（WAF）。 | 1. Web服务器集群负载均衡 2. 动静分离（Nginx处理静态资源，动态请求转发至后端） 3. HTTPS统一加解密 4. 按条件（IP/Header）灰度发布。 |
| 四层反向代理 | TCP/UDP | 直接转发原始数据流，不解析应用层内容。 | 高性能、低延迟传输，端口映射，协议无关转发。 | 1. 数据库代理（MySQL/Redis集群） 2. 游戏服务器（UDP协议负载均衡） 3. SSH跳板机（端口映射） 4. MQTT等TCP服务的高可用代理。 |
反向代理，指的是浏览器/客户端并不知道自己要访问具体哪台目标服务器只知道去访问代理服务器 ，代理服务器再通过反向代理 +负载均衡实现请求分发到应用服务器的一种代理服务。
反向代理服务的特点是代理服务器代理的对象是应用服务器，也就是对于浏览器/客户端 来说应用服务器是隐藏的。
1.配置nginx七层代理
通过配置nginx七层代理实现转发nginx请求至后端的httpd服务，通过该转发也能实现nginx+httpd的动静分离，动静分离会在后续章节介绍。
(1)环境安装
192.168.10.101上操作：
(2)配置nginx七层代理转发
[root@localhost# vi /usr/local/nginx/conf/nginx.conf
http {upstream backend {server 192.168.10.201:80;
}
server {
listen 80;
server_name example.com;location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote addr;
}
location /static/ {root /data/www;expires 30d;}}
}
[root@localhost~]#nginx -t
[root@localhost!]#systemctl restart nginx上述配置中，使用upstream定义后端应用服务器的地址池“backend”，在location块中，使用proxy_pass，转发请求至后端地址池，proxy_set_headerHost $host:将请求中的Host头部设置为客户端请求的主机名,proxy_set header X-Real-IP $remote addr:将请求中的 X-Real-IP 头部设置为客户端的真实 IP 地址。
(4)验证转发效果
这是后端主机
后端地址池中也可以定义多台主机，实现负载均衡。
2.配置nginx四层代理
SSH协议是基于TCP协议的，配置nginx的四层代理，实现代理ssh请求至后端服务器，用以登录内网服务器场景
(1)配置四层代理
[root@localhost~]#vi /usr/local/nginx/conf/nginx.conf
stream {upstream ssh cluster {server 192.168.10.101:22;
}server {listen 2222;proxy_pass_ssh cluster;proxy_connect_timeout 5s:proxy_timeout lh;}
}[root@localhost~]#nginx -t
[root@localhost~]#nginx-s reload
[root@localhost~]#ss -nlptgrep 2222(2)验证四层代理
[root@localhost~]# ssh root@192.168.10.102 -p2222
[root@localhost~]#ifconfig
ens33: flagS=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.10.101 netmask 255.255.255.0 broadcast
192.168.10.255
inet6 fe80::20c:29ff:fe9f:de15 prefixlen 64 scopeid
0x20<link>
ether 00:0c:29:9f:de:15 txqueuelen 1000(Ethernet)
RX packets 389822 bytes 511828164(488.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 104614 bytes 8588675 (8.1 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0通过上面的验证发现，通过102的2222端口登录后，实际上是登录到101服务器
三.Nginx缓存
Nginx的缓存功能是其核心能力之一，主要用于加速内容响应和降低后端服务器负载。它的缓存功能主要基于反向代理(Proxy Cache)，但也可用于其他场景(如 FastCGI 缓存)。以下是详细解析:
1.缓存功能的核心原理和缓存类型
| 缓存类型 | 作用场景 | 核心原理 | 配置指令示例 |
|---|---|---|---|
| 代理缓存 | 反向代理模式下缓存后端服务器（如Tomcat、Apache）的响应内容。 | Nginx作为代理服务器时，将后端响应存储到本地，后续相同请求直接返回缓存。 | proxy_cache_path + proxy_cache |
| FastCGI缓存 | 缓存PHP/Python等通过FastCGI协议处理的动态内容（需配合PHP-FPM使用）。 | 缓存FastCGI进程的动态输出，避免重复执行脚本。 | fastcgi_cache_path + fastcgi_cache |
| uWSGI/SCGI缓存 | 类似FastCGI，用于Python（uWSGI）或其他SCGI协议的后端服务。 | 缓存uWSGI/SCGI后端服务的响应，提升动态内容处理效率。 | uwsgi_cache_path + uwsgi_cache |
| 静态资源缓存 | 通过expires指令设置客户端浏览器缓存（非服务端缓存）。 | 通过HTTP响应头Cache-Control和Expires控制浏览器缓存行为，减少服务器请求。 | expires 30d;（客户端缓存30天） |
-
服务端 vs 客户端：
-
代理/FastCGI/uWSGI缓存是服务端缓存，存储在Nginx或后端。
-
静态资源缓存是客户端缓存，依赖浏览器行为。
-
-
适用协议：
-
FastCGI/uWSGI缓存针对特定后端协议（PHP/Python等）。
-
代理缓存通用所有HTTP后端。
-
-
性能优化：
-
服务端缓存降低后端负载，客户端缓存减少网络请求。
-
代理缓存：
代理缓存原理:
第一步:客户端第一次向Nginx请求数据A;
第二步:当Nginx发现缓存中没有数据A时，会向服务端请求数据A;
第三步:服务端接收到Nginx发来的请求,则返回数据A到Nginx,并且缓存在Nginx;
第四步:Nginx返回数据A给客户端应用;
第五步:客户端第二次向Nginx请求数据A;
第六步:当Nginx发现缓存中存在数据A时，则不会请求服务端;
第七步:Nginx把缓存中的数据A返回给客户端应用。
2.代理缓存功能设置
| 配置项 | 参数/值 | 说明 |
|---|---|---|
| 反向代理配置 | ||
| 后端地址池 | upstream backend { server 192.168.10.201:80; } | 定义后端服务器地址为192.168.10.201，端口80。 |
| 动态请求转发 | proxy_pass http://backend; | 将动态请求转发至后端地址池。 |
| 静态资源路径 | root /data/www; | 静态资源直接响应，存放于/data/www目录。 |
| 客户端缓存时间 | expires 30d; | 静态资源在客户端缓存30天。 |
| 缓存功能设置 | ||
| 缓存目录 | /data/nginx/cache | 创建缓存目录并设置权限为nginx用户。 |
| 缓存路径参数 | levels=1:2 keys_zone=my_cache:10m inactive=60m max_size=1g use_temp_path=off; | 定义缓存路径结构、共享内存区大小（10MB）、非活动时间（60分钟）、最大缓存大小（1GB）。 |
| 启用缓存区 | proxy_cache my_cache; | 使用名为my_cache的缓存区。 |
| 缓存键定义 | "$scheme$request_method$host$request_uri" | 缓存键由协议、请求方法、主机名和请求URI组成。 |
| 缓存有效期 | 200/302状态码: 10分钟404状态码: 1分钟其他状态码: 5秒 | 根据状态码设置不同的缓存时间。 |
| 缓存状态头 | add_header X-Cache-Status $upstream_cache_status; | 添加响应头显示缓存状态（如HIT/MISS），用于调试。 |
| 参数 | 值/示例 | 说明 |
|---|---|---|
| proxy_cache_path | /data/nginx/cache | 定义缓存文件的存储路径。 |
| levels | 1:2 | 定义缓存目录的层级结构，levels=N:M 表示路径深度（如 1:2 生成两级子目录）。 |
| keys_zone | my_cache:10m | 定义共享内存区域名称及大小（10m=10MB），用于存储缓存键和元数据（每1MB约存8000个键）。 |
| inactive | 60m | 缓存内容的闲置有效期。60分钟内未被访问的缓存将被自动删除。 |
| max_size | 1g | 缓存目录的最大磁盘空间（1g=1GB）。达到限制时，Nginx触发LRU算法清理旧缓存。 |
| use_temp_path | off | 禁用临时文件路径，直接写入缓存目录（减少磁盘操作，提升性能）。 |
四.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正则
| 字符 | 描述 | 示例 |
|---|---|---|
^ | 匹配输入字符串的起始位置 | ^abc 匹配以 "abc" 开头的字符串 |
$ | 匹配输入字符串的结束位置 | xyz$ 匹配以 "xyz" 结尾的字符串 |
* | 匹配前面的字符零次或多次 | ol* 能匹配 "o"、"ol"、"oll" 等 |
+ | 匹配前面的字符一次或多次 | ol+ 能匹配 "ol"、"oll"，但不能匹配 "o" |
? | 匹配前面的字符零次或一次（等效于 {0,1}） | do(es)? 匹配 "do" 或 "does" |
. | 匹配除换行符 \n 之外的任何单个字符 | a.c 匹配 "abc"、"a1c" 等，但不匹配 "a\nc" |
\ | 转义字符，将特殊字符转为原义字符或标记特殊功能 | \$ 匹配 "$" 字符；\n 匹配换行符 |
\d | 匹配纯数字（等效于 [0-9]） | \d+ 匹配 "123"、"45" 等数字串 |
{n} | 匹配前面的字符恰好 n 次 | a{3} 匹配 "aaa" |
{n,} | 匹配前面的字符至少 n 次 | a{2,} 匹配 "aa"、"aaa" 等 |
[c] | 匹配单个字符 c | [x] 匹配字符 "x" |
[a-z] | 匹配任意小写字母（a 到 z） | [a-z]+ 匹配 "hello" |
[a-zA-Z] | 匹配任意大小写字母（a 到 z 或 A 到 Z） | [a-zA-Z] 匹配 "A"、"b" 等 |
2.nginx location
| 匹配模式 | 语法示例 | 说明 | 优先级 |
|---|---|---|---|
| 精确匹配 | location = /uri | 仅匹配完全相同的 URL（如 = /abc 只匹配 /abc）。 | 最高 |
| 精确前缀匹配 | location ^~ /uri | 匹配以指定路径开头的 URL，匹配成功后不再检查正则匹配（如 ^~ /abc 匹配 /abc/123）。 | 高 |
| 区分大小写正则匹配 | location ~ /pattern | 使用正则表达式匹配 URL，区分大小写（如 ~ /test 匹配 /Test/ 不匹配）。 | 中 |
| 不区分大小写正则匹配 | location ~* /pattern | 使用正则表达式匹配 URL，不区分大小写（如 ~* /test 匹配 /Test/）。 | 中 |
| 普通前缀匹配 | location /uri | 匹配以指定路径开头的 URL（如 /abc 匹配 /abc 或 /abc/123），优先级低于精确前缀匹配。 | 低 |
| 通用匹配 | location / | 默认匹配所有未被其他规则匹配的请求。 | 最低 |
location 优先级规则
优先级从高到低排序：
-
精确匹配 (
=) -
精确前缀匹配 (
^~) -
正则匹配 (
~或~*，文件中先出现的优先) -
普通前缀匹配 (
/uri) -
通用匹配 (
/)
| 测试命令 | 匹配结果 | 原因 |
|---|---|---|
curl 192.168.10.102/abc | 精确匹配 | 优先匹配 location = /abc（精确匹配优先级最高）。 |
curl 192.168.10.102/abcdef | 精确前缀匹配 | 匹配 location ^~ /abc（优先级高于正则和普通前缀匹配）。 |
curl 192.168.10.102/test/abcdef | 区分大小写正则 | 匹配 location ~ /test/abcdef（正则匹配，区分大小写）。 |
curl 192.168.10.102/TEST/abc | 不区分大小写正则 | 匹配 location ~* /test/abc（不区分大小写）。 |
curl 192.168.10.102/abc/123 | 普通前缀匹配 | 匹配 location /abc（无更高优先级规则时生效）。 |
curl 192.168.10.102/xyz | 通用匹配 | 其他规则未匹配时，由 location / 处理。 |
3.Rewrite
（1）Rewrite 语法与参数
| 参数 | 说明 | 示例 |
|---|---|---|
| regex | 正则表达式匹配URL（不包含域名和参数部分，如 /index.php?id=1 仅匹配 /index.php）。 | ^/old/(.*) |
| replacement | 重写后的目标地址，可以是绝对路径或包含正则捕获组的变量（如 $1）。 | /new/$1 |
| flag | 控制重写行为（见下表）。 | last, break, redirect 等 |
（2） Rewrite Flag 类型
| Flag | 作用 | 适用场景 |
|---|---|---|
| last | 重写后的URL重新触发location匹配（默认行为）。 | 需要重新匹配location规则时使用。 |
| break | 重写后直接处理当前location，不再执行后续rewrite规则。 | 避免循环重定向或终止后续改写。 |
| redirect | 返回302临时重定向，浏览器地址栏更新，爬虫不更新URL。 | 临时跳转（如A/B测试）。 |
| permanent | 返回301永久重定向，浏览器和爬虫均更新URL。 | 永久迁移（如域名更换）。 |
（3） Rewrite 配置段与作用域
| 配置段 | 执行顺序 | 作用域 | 示例 |
|---|---|---|---|
| server{} | 在请求进入server后，匹配location前执行。 | 全局生效，影响该server块下所有请求。 | rewrite ^/old /new permanent; |
| location{} | 在匹配到该location后执行。 | 仅对当前location匹配的请求生效。 | location /old { rewrite ... } |
| if{} | 满足if条件时触发。 | 依赖if所在的上下文（如在server中则全局，在location中则局部）。 | if ($host ~* "example") { ... } |
（4）实际应用场景对比
| 实现方式 | 优点 | 缺点 | 示例 |
|---|---|---|---|
| rewrite直接跳转 | 简洁高效，适合简单路径重写。 | 复杂逻辑需结合正则，可读性降低。 | rewrite ^/old /new last; |
| if全局变量跳转 | 支持复杂条件判断（如变量、UA等）。 | 性能略低，滥用可能导致配置混乱。 | if ($args ~ "id=1") { ... } |
| location+rewrite | 结合路径匹配更精细。 | 需多层嵌套，配置稍复杂。 | location /old { rewrite ... } |
