Nginx 核心功能全解析：正向代理、反向代理、缓存与 Rewrite 实战

前言

在现代 Web 架构中，Nginx 凭借轻量级、高并发处理能力和灵活的模块化设计，成为了高性能开源 Web 服务器和反向代理工具的首选，更是构建高效、稳定 Web 服务的基石。从全球顶尖网站的流量调度到微服务架构的负载均衡，从缓存加速到安全防护，Nginx 都扮演着不可或缺的角色。

本文将围绕 Nginx 的四大核心功能 ------正向代理 、反向代理（七层 / 四层） 、缓存机制 和Rewrite 正则匹配展开全面解析，结合理论知识与实操案例，从环境搭建到配置验证，手把手教你掌握 Nginx 核心功能的设计思想与实践技巧，助力大家搭建高可用的 Web 服务架构。

一、正向代理：客户端的 "中间人"

1.1 正向代理核心概念

正向代理（Forward Proxy）是部署在客户端和原始服务器之间的代理服务器，核心作用是接收客户端的请求并转发至目标服务器，再将目标服务器的响应结果返回给客户端。Nginx 作为正向代理时，会充当客户端的 "中间人"，代表用户访问外部资源，同时可隐藏客户端的真实 IP 地址。

正向代理的典型应用场景主要有三类：

• 内网访问控制：企业场景中限制员工访问社交媒体、视频网站等非工作相关资源，管控内网网络行为；
• 匿名访问：通过代理服务器转发请求，隐藏客户端真实 IP，提升访问的隐私性；
• 资源缓存加速：缓存软件包、镜像文件等公共资源，减少外网带宽消耗，提升内网用户的资源访问速度。

正向代理的访问流程为：浏览器 / 客户端发起请求 → 代理服务器接收并转发请求至目标服务器 → 目标服务器返回响应 → 代理服务器将响应回传给客户端。

1.2 编译安装 Nginx（支持正向代理）

Nginx 默认不支持 HTTPS 正向代理转发，需编译安装并添加第三方模块ngx_http_proxy_connect_module，同时依赖 pcre、zlib、openssl 等开发包，以下为基于 OpenEuler 系统的完整安装步骤。

1.2.1 安装依赖软件包

Nginx 的配置和运行需要 pcre、zlib、openssl 等库的支持，通过 dnf 命令安装相关开发包：

[root @localhost ~]# dnf install -y gcc make pcre-devel zlib-devel openssl-devel perl-ExtUtils-MakeMaker git wget tar

1.2.2 创建运行用户、组和日志目录

为了精准控制 Nginx 的访问权限，降低安全风险，建议创建专用的运行用户（不创建宿主文件夹、禁止 Shell 登录），并建立日志目录且修改权限：

[root@localhost ~]# useradd -M -s /sbin/nologin nginx
[root@localhost ~]# mkdir -p /var/log/nginx
[root@localhost ~]# chown -R nginx:nginx /var/log/nginx

1.2.3 编译安装 Nginx（添加正向代理模块）

本次安装将 Nginx 部署在/usr/local/nginx，指定运行用户 / 组为 nginx，同时启用 SSL、状态统计、TCP 代理等核心模块，添加第三方 HTTPS 正向代理模块：

# 解压Nginx源码包
[root@localhost ~]# tar zxf nginx-1.26.3_http_proxy.tar.gz
[root@localhost ~]# cd nginx-1.26.3
# 配置编译选项（已内置ngx_http_proxy_connect_module模块，无需额外下载）
[root@localhost nginx-1.26.3]# ./configure --prefix=/usr/local/nginx --user=nginx --group=nginx \
--with-http_ssl_module --with-http_v2_module --with-http_realip_module \
--with-http_stub_status_module --with-http_gzip_static_module --with-pcre \
--with-stream --with-stream_ssl_module --with-stream_realip_module \
--add-module=./ngx_http_proxy_connect_module
# 编译并安装
[root@localhost nginx-1.26.3]# make && make install

核心编译参数说明：

表格

参数	作用
--with-http_ssl_module	支持 HTTPS 协议
--with-http_realip_module	支持 IP 透传
--with-http_stub_status_module	支持 Nginx 状态统计页面
--with-stream	支持 TCP 四层反向代理
--add-module	添加第三方 HTTPS 正向代理模块
--with-pcre	支持正则表达式解析

1.2.4 创建软链接并添加系统服务

为了方便调用 Nginx 命令，为其主程序创建软链接；同时编写 systemd 服务脚本，实现 Nginx 的系统级管理（启动、停止、重载）：

# 创建软链接
[root@localhost nginx-1.26.3]# ln -s /usr/local/nginx/sbin/nginx /usr/local/sbin/
# 编写Nginx系统服务脚本
[root@localhost ~]# vi /lib/systemd/system/nginx.service

服务脚本内容如下：

[Unit]
Description=The NGINX HTTP and reverse proxy server
After=network.target

[Service]
Type=forking
PIDFile=/usr/local/nginx/logs/nginx.pid
ExecStartPre=/usr/local/sbin/nginx -t
ExecStart=/usr/local/sbin/nginx
ExecReload=/usr/local/sbin/nginx -s reload
ExecStop=/bin/kill -s QUIT $MAINPID
TimeoutStopSec=5
KillMode=process
PrivateTmp=true
User=root
Group=root

[Install]
WantedBy=multi-user.target

重新加载系统服务并设置 Nginx 开机自启、启动 Nginx：

[root@localhost ~]# systemctl daemon-reload
[root@localhost ~]# systemctl enable nginx
[root@localhost ~]# systemctl start nginx

1.3 配置 Nginx 正向代理

1.3.1 编辑主配置文件

修改 Nginx 主配置文件/usr/local/nginx/conf/nginx.conf，添加正向代理相关配置，监听 8080 端口，支持 HTTP/HTTPS 代理转发：

[root@localhost ~]# vi /usr/local/nginx/conf/nginx.conf

核心配置内容：

server {
    listen 8080;  # 正向代理监听端口
    server_name proxy.example.com;  # 代理服务器域名

    resolver 8.8.8.8 1.1.1.1;  # 配置DNS解析服务器，多个用空格分隔
    proxy_connect;  # 启用代理CONNECT方法，支持HTTPS转发
    proxy_connect_allow 443 80;  # 允许代理的目标端口
    proxy_connect_connect_timeout 10s;  # 连接超时时间
    proxy_connect_read_timeout 10s;     # 读取超时时间
    proxy_connect_send_timeout 10s;     # 发送超时时间

    # 处理所有HTTP/HTTPS请求
    location / {
        proxy_pass $scheme://$http_host$request_uri;  # 动态转发至目标地址
        proxy_set_header Host $http_host;
        proxy_buffers 256 4k;  # 优化缓冲区大小
        proxy_max_temp_file_size 0;  # 禁用临时文件
        proxy_http_version 1.1;  # 启用HTTP/1.1，保持长连接
        proxy_set_header Connection "";
    }
}

1.3.2 验证配置并重载 Nginx

修改配置后，先检查配置文件语法正确性，再重载 Nginx 使配置生效：

[root@localhost ~]# nginx -t  # 检查语法，显示ok即无问题
[root@localhost ~]# nginx -s reload  # 重载配置

1.4 验证正向代理功能

正向代理的验证可通过Windows 浏览器 和Linux curl 命令两种方式，以下为详细步骤（代理服务器 IP 为 192.168.10.202，端口 8080）。

1.4.1 Windows 火狐浏览器验证

1. 打开火狐浏览器，进入设置 → 高级 → 网络 → 连接设置；
2. 选择手动配置代理 ，填写 HTTP 代理和 HTTPS 代理为192.168.10.202，端口8080，勾选也将此代理用于 HTTPS；
3. 点击确定，访问任意网站（如百度），即可通过代理服务器转发请求。

1.4.2 Linux curl 命令验证

使用 curl 命令指定代理服务器，访问目标网站，验证代理是否生效：

[root@localhost ~]# curl -x http://192.168.10.202:8080 www.baidu.com

若能正常返回百度页面的 HTML 内容，说明正向代理配置成功。同时可查看 Nginx 访问日志/var/log/nginx/access.log，能看到客户端的访问记录，且目标服务器仅能识别代理服务器 IP，实现了真实 IP 隐藏。

二、反向代理：服务端的 "智能调度器"

2.1 反向代理核心概念

反向代理（Reverse Proxy）是部署在服务端的代理服务器，客户端仅需访问代理服务器，由代理服务器根据规则将请求转发至后端的应用服务器，再将后端服务器的响应返回给客户端。

与正向代理不同，反向代理代理的是应用服务器 ，客户端并不知道具体的后端服务器地址，后端服务器对客户端完全隐藏。Nginx 支持 ** 七层（应用层）和四层（网络层）** 反向代理，是企业级架构中实现负载均衡、安全隔离、性能优化的核心组件。

2.2 七层反向代理（HTTP/HTTPS 协议）

七层反向代理基于 HTTP/HTTPS 协议，可深度解析应用层内容（URL、Header、Cookie 等），实现精准的请求转发，是 Web 服务最常用的代理方式。

2.2.1 应用场景

• 负载均衡：将客户端流量分发至多台后端服务器，避免单点故障，提升服务可用性；
• 动静分离：静态资源（图片、CSS、JS）由 Nginx 直接响应，动态请求（PHP、API）转发至 Apache/Tomcat，提升响应速度；
• SSL 终端：由 Nginx 统一处理 HTTPS 的加密 / 解密，降低后端服务器的计算压力；
• 灰度发布：根据客户端 IP、Header 等特征，将部分流量导向新版本服务，实现平滑升级。

2.2.2 实验环境准备

本次实验需要两台 OpenEuler 主机，配置如下：

表格

主机 IP	配置	部署服务	作用
192.168.10.101	2C4G	Nginx	七层反向代理服务器
192.168.10.102	2C4G	Httpd	后端应用服务器

2.2.3 部署后端 Httpd 服务

在 192.168.10.102 上安装并启动 Httpd，创建测试页面，作为后端服务节点：

# 关闭防火墙（实验环境）
[root@localhost ~]# systemctl stop firewalld
# 安装Httpd
[root@localhost ~]# dnf install httpd -y
# 创建测试页面
[root@localhost ~]# echo "这是后端主机" > /var/www/html/index.html
# 启动Httpd
[root@localhost ~]# systemctl start httpd

2.2.4 配置 Nginx 七层反向代理

在 192.168.10.101 上修改 Nginx 主配置文件，通过upstream定义后端服务器地址池，使用proxy_pass实现请求转发：

[root@localhost ~]# vi /usr/local/nginx/conf/nginx.conf

核心配置内容：

http {
    # 定义后端服务器地址池，命名为backend
    upstream backend {
        server 192.168.10.102:80;  # 后端Httpd服务器IP和端口
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://backend;  # 将请求转发至后端地址池
            proxy_set_header Host $host;  # 传递客户端请求的Host头
            proxy_set_header X-Real-IP $remote_addr;  # 传递客户端真实IP
        }
    }
}

2.2.5 验证七层反向代理

检查配置文件语法并重载 Nginx，使用 curl 命令访问代理服务器 IP，验证请求是否转发至后端 Httpd：

# 验证配置并重载
[root@localhost ~]# nginx -t
[root@localhost ~]# nginx -s reload
# 访问代理服务器
[root@localhost ~]# curl 192.168.10.101

若返回这是后端主机 ，说明七层反向代理配置成功。若在upstream中添加多台后端服务器，即可实现基础的负载均衡。

2.3 四层反向代理（TCP/UDP 协议）

四层反向代理基于 TCP/UDP 协议，直接转发原始数据流，不解析应用层内容，具有高性能、低延迟的特点，适用于数据库、游戏服务器、SSH 等非 HTTP 服务的代理。

2.3.1 应用场景

• 数据库代理：对外暴露统一端口，内部转发至 MySQL、Redis 集群，实现数据库的访问管控；
• 游戏服务器：代理 UDP 协议，实现实时数据包的负载均衡；
• SSH 跳板机：通过端口映射，实现对内网服务器的安全 SSH 访问；
• 高可用服务：为 MQTT 等 TCP 服务实现主备切换和健康检查。

2.3.2 配置 Nginx 四层反向代理（SSH 代理）

以 SSH 协议（基于 TCP）为例，配置 Nginx 四层反向代理，实现通过代理服务器的 2222 端口，登录后端 192.168.10.102 的 SSH 服务。

注意 ：Nginx 的四层代理通过stream模块实现，stream模块需与http模块平级，不能嵌套在http模块内。

修改 Nginx 主配置文件：

[root@localhost ~]# vi /usr/local/nginx/conf/nginx.conf

在配置文件末尾添加stream模块配置：

# stream模块与http模块平级
stream {
    # 定义后端SSH服务器地址池
    upstream ssh_cluster {
        server 192.168.10.102:22;  # 后端服务器SSH端口
    }

    # 监听2222端口，作为SSH代理入口
    server {
        listen 2222;
        proxy_pass ssh_cluster;  # 转发至后端地址池
        proxy_connect_timeout 5s;  # 连接超时时间
        proxy_timeout 1h;  # 长连接保持时间
    }
}

2.3.3 验证四层反向代理

检查配置并重载 Nginx，验证 2222 端口是否监听，再通过 SSH 命令访问代理服务器的 2222 端口，验证是否能登录后端服务器：

# 验证配置并重载
[root@localhost ~]# nginx -t
[root@localhost ~]# nginx -s reload
# 检查2222端口是否监听
[root@localhost ~]# ss -nlpt | grep 2222
# 通过代理服务器登录后端SSH
[root@localhost ~]# ssh root@192.168.10.101 -p2222

登录成功后，执行ifconfig查看当前主机 IP，若显示为 192.168.10.102，说明四层反向代理配置成功。

三、Nginx 缓存机制：提升服务响应速度的核心

Nginx 的缓存功能是其高性能的重要体现，主要基于 ** 反向代理缓存（Proxy Cache）** 实现，可缓存后端服务器的响应内容，当客户端再次请求相同资源时，Nginx 直接从本地缓存返回，无需转发至后端服务器，大幅提升响应速度，同时降低后端服务器的负载。

3.1 缓存核心原理与类型

3.1.1 代理缓存核心原理

代理缓存的核心流程为 "首次请求转发，再次请求缓存返回"，具体步骤：

1. 客户端第一次请求数据 A，Nginx 检查本地缓存，未找到数据 A（缓存未命中）；
2. Nginx 将请求转发至后端服务器，请求数据 A；
3. 后端服务器返回数据 A 给 Nginx，Nginx 将数据 A 缓存至本地磁盘；
4. Nginx 将数据 A 返回给客户端；
5. 客户端第二次请求数据 A，Nginx 检查本地缓存，找到数据 A（缓存命中）；
6. Nginx 直接从本地缓存中读取数据 A，返回给客户端，不再转发至后端服务器。

3.1.2 Nginx 主要缓存类型

Nginx 支持多种缓存类型，适用于不同的业务场景，核心类型如下：

表格

缓存类型	作用场景
代理缓存（Proxy Cache）	反向代理模式下，缓存后端服务器（Tomcat/Apache）的 HTTP/HTTPS 响应内容
FastCGI 缓存	缓存 PHP/Python 等通过 FastCGI 协议处理的动态内容（需配合 PHP-FPM 使用）
uWSGI/SCGI 缓存	类似 FastCGI 缓存，适用于 uWSGI/SCGI 协议的后端服务
静态资源缓存	通过expires指令设置客户端浏览器缓存，属于客户端缓存，非服务端缓存

本文重点讲解 ** 代理缓存（Proxy Cache）** 的配置与实战，该缓存是 Nginx 最常用的缓存类型，需基于七层反向代理实现。

3.2 配置 Nginx 代理缓存（基于七层反向代理）

代理缓存的配置需先完成七层反向代理的基础配置，再添加缓存相关指令，包括定义缓存路径、启用缓存、设置缓存有效期等，本次实验基于前文的七层反向代理环境（代理服务器 192.168.10.101，后端服务器 192.168.10.102）。

3.2.1 创建缓存目录并修改权限

创建 Nginx 缓存文件的存储目录，将目录所有者修改为 Nginx 运行用户，避免权限不足：

[root@localhost ~]# mkdir -p /data/nginx/cache
[root@localhost ~]# chown -R nginx:nginx /data/nginx/cache

3.2.2 编辑 Nginx 配置，添加缓存相关指令

修改 Nginx 主配置文件，在http模块中定义缓存路径和参数，在location模块中启用缓存并设置缓存规则：

[root@localhost ~]# vi /usr/local/nginx/conf/nginx.conf

核心配置内容：

http {
    # 定义缓存路径和核心参数
    proxy_cache_path /data/nginx/cache  # 缓存文件存储路径
    levels=1:2  # 缓存目录层级结构（1级目录+2级子目录，减少单目录文件数）
    keys_zone=my_cache:10m  # 共享内存区域，命名my_cache，大小10m（1m可存约8000个缓存键）
    inactive=60m  # 缓存闲置有效期：60分钟未访问则自动删除
    max_size=1g  # 缓存最大磁盘空间：1G，超出后触发LRU算法清理旧缓存
    use_temp_path=off;  # 禁用临时目录，减少磁盘IO，提升性能

    # 后端服务器地址池（七层反向代理基础配置）
    upstream backend {
        server 192.168.10.102: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;

            # 启用代理缓存
            proxy_cache my_cache;  # 关联上述定义的共享内存区域my_cache
            # 定义缓存键：协议+请求方法+主机名+请求URI，确保唯一标识一个资源
            proxy_cache_key "$scheme$request_method$host$request_uri";
            # 设置不同状态码的缓存有效期
            proxy_cache_valid 200 302 10m;  # 200/302状态码缓存10分钟
            proxy_cache_valid 404 1m;        # 404状态码缓存1分钟
            proxy_cache_valid any 5s;        # 其他状态码缓存5秒
            # 添加缓存状态响应头，用于调试（MISS未命中/HIT命中/EXPIRED过期）
            add_header X-Cache-Status $upstream_cache_status;
        }
    }
}

3.2.3 验证配置并重载 Nginx

[root@localhost ~]# nginx -t
[root@localhost ~]# nginx -s reload

3.3 验证代理缓存功能

使用curl -I命令访问代理服务器，查看响应头中的X-Cache-Status字段，验证缓存是否命中，具体步骤：

1. 第一次访问：缓存未命中（MISS），Nginx 转发请求至后端服务器，并缓存数据；

   [root@localhost ~]# curl -I 192.168.10.101

   响应头中会显示X-Cache-Status: MISS，表示缓存未命中。

2. 第二次访问：缓存命中（HIT），Nginx 直接从本地缓存返回数据；

   [root@localhost ~]# curl -I 192.168.10.101

   响应头中会显示X-Cache-Status: HIT，表示缓存命中。

3. 查看缓存文件：缓存命中后，可在缓存目录中看到生成的缓存文件，验证缓存是否实际存储：

   [root@localhost ~]# ls /data/nginx/cache

通过以上验证，可确认 Nginx 代理缓存功能已正常生效，后续相同请求将直接从缓存返回，大幅提升响应速度。

四、Nginx Rewrite 与正则：URL 的 "规则引擎"

Rewrite 模块是 Nginx 的 "规则引擎"，通过正则表达式 匹配 URL，并根据规则对 URL 进行重写或跳转，实现路径美化、旧链接迁移、强制 HTTPS、动态路由等功能。Rewrite 通常与location指令结合使用，实现更精细的 URL 控制，是 Nginx 实现流量调度的核心功能之一。

4.1 Nginx 常用正则表达式元字符

学习 Rewrite 前，需先掌握常用的正则表达式元字符，Nginx 的正则匹配遵循 Perl 兼容正则（PCRE）规范，核心元字符如下：

表格

元字符	描述
^	匹配输入字符串的起始位置
$	匹配输入字符串的结束位置
*	匹配前面的字符零次或多次（如 ol * 匹配 o、ol、oll）
+	匹配前面的字符一次或多次（如 ol + 匹配 ol、oll，不匹配 o）
?	匹配前面的字符零次或一次（如 do (es)? 匹配 do、does）
.	匹配除 \n 之外的任何单个字符
\	转义字符，将特殊字符标记为原义字符（如 匹配 ）
\d	匹配纯数字
{n}	匹配前面的字符恰好 n 次
{n,}	匹配前面的字符 n 次或更多次
[c]	匹配单个字符 c
[a-z]	匹配任意一个小写字母
[a-zA-Z]	匹配任意一个大小写字母

4.2 Nginx location 指令：URI 匹配核心

location是 Nginx 中用于匹配请求 URI（域名后的路径部分）的核心指令，用于根据 URI 定义不同的处理逻辑，Rewrite 通常与location结合使用，因此需先掌握location的匹配模式和优先级。

4.2.1 location 语法与匹配模式

语法：

location [匹配模式] /uri {
    # 处理逻辑（root、proxy_pass、rewrite等）
}

匹配模式类型：

表格

匹配模式	说明	示例
精确匹配 =	仅匹配与 URI 完全相同的请求，优先级最高	location =/abc { ... }
精确前缀匹配 ^~	匹配以指定 URI 开头的请求，不触发后续正则匹配，优先级高于正则	location ^~/abcdef { ... }
正则匹配 ~	区分大小写的正则表达式匹配	location ~/test/abc { ... }
正则匹配 ~*	不区分大小写的正则表达式匹配	location ~*/test/abc { ... }
普通前缀匹配	无模式标记，匹配以指定 URI 开头的请求	location /abc { ... }
通用匹配 /	无匹配规则时的默认匹配，优先级最低	location / { ... }

4.2.2 location 优先级规则

location 的匹配优先级决定了请求的处理逻辑，核心规则：精确匹配= > 精确前缀匹配^~ > 正则匹配（~/~*，文件中靠前的优先） > 普通前缀匹配 > 通用匹配/

4.2.3 location 匹配验证

通过以下配置可验证 location 的优先级，修改 Nginx 配置文件并重载，通过 curl 命令访问不同 URI，查看返回结果：

server {
    listen 80;
    server_name example.com;
    default_type text/plain;  # 防止浏览器下载返回内容

    location =/abc { return 200 "精确匹配"; }
    location ^~/abcdef { return 200 "精确前缀匹配"; }
    location ~/test/abcdef { return 200 "区分大小写正则"; }
    location ~*/test/abc { return 200 "不区分大小写正则"; }
    location /abc { return 200 "普通前缀匹配"; }
    location / { return 200 "通用匹配"; }
}

例如：访问http://192.168.10.101/abc，返回精确匹配 ；注释精确匹配后，访问该 URI 返回普通前缀匹配，符合优先级规则。

4.3 Rewrite 核心语法与 Flag 标记

4.3.1 Rewrite 基本语法

Rewrite 的核心语法为：

rewrite <regex> <replacement> [flag];

• regex ：正则表达式，匹配需要重写的 URI（仅匹配域名后、参数前的路径部分，如http://www.xxx.com/index.php?id=1仅匹配/index.php）；
• replacement：重写 / 跳转后的目标地址；
• flag：重写标记，控制重写后的请求处理逻辑，是 Rewrite 的核心。

4.3.2 Rewrite 核心 Flag 标记

Flag 标记决定了重写后的 URI 是否重新匹配 location、是否跳转等，核心标记有 4 种，具体说明：

表格

Flag 标记	作用	特点
last	重写后的 URI 重新触发 location 匹配，执行新 location 的逻辑，默认标记	重写后继续匹配，适合内部路径重写
break	重写后的 URI 不重新匹配 location，直接在当前 location 处理，后续 rewrite 指令失效	重写后终止匹配，适合简单路径重写
redirect	返回 302 临时重定向，浏览器地址栏显示跳转后的 URL，爬虫不更新 URL	临时跳转，适合临时的 URL 变更
permanent	返回 301 永久重定向，浏览器地址栏显示跳转后的 URL，爬虫更新 URL	永久跳转，适合旧链接迁移、域名统一

4.3.3 Flag 标记实战验证

通过实际配置验证 4 种 Flag 标记的差异，基于 192.168.10.101 的 Nginx 服务器，配置如下：

1. last 标记：重写后重新匹配 location

server {
    listen 80;
    default_type text/plain;
    # 匹配/abc，重写为/def，last标记重新匹配location
    location /abc {
        rewrite ^/abc /def last;
    }
    # 匹配/def，返回指定内容
    location /def {
        return 200 "this is def";
    }
}

重载 Nginx 后，访问http://192.168.10.101/abc，返回this is def ，说明重写后的/def重新匹配了 location。

2. break 标记：重写后终止 location 匹配

修改上述配置，将 last 改为 break：

location /abc {
    rewrite ^/abc /def break;
}
location /def {
    return 200 "this is def";
}

重载后访问http://192.168.10.101/abc，返回404 Not Found ，说明重写后的/def未重新匹配 location，Nginx 直接查找本地/def路径，因不存在该路径导致 404。

3. redirect 标记：302 临时重定向

修改配置为 redirect 标记：

location /abc {
    rewrite ^/abc /def redirect;
}
location /def {
    return 200 "this is def";
}

访问http://192.168.10.101/abc，浏览器地址栏跳转为http://192.168.10.101/def，返回this is def，响应状态码为 302。

4. permanent 标记：301 永久重定向

修改配置为 permanent 标记：

location /abc {
    rewrite ^/abc /def permanent;
}
location /def {
    return 200 "this is def";
}

访问http://192.168.10.101/abc，浏览器地址栏跳转为http://192.168.10.101/def，返回this is def，响应状态码为 301，适合旧链接永久迁移。

4.4 Rewrite 高级用法：捕获组与 set 指令

4.4.1 捕获组：正则匹配结果的引用

在 Rewrite 的正则表达式中，可通过小括号 ()定义捕获组 ，捕获匹配到的文本内容，并通过$1、$2、$3等变量在重写后的地址中引用，实现动态的 URL 重写。

语法 ：rewrite (正则捕获组1) (正则捕获组2) 重写地址$1$2 [flag];

实战案例 ：将/category/tech/123重写为/archive/tech/123，并引用捕获的分类和 ID：

server {
    listen 80;
    default_type text/plain;
    # 匹配/category/分类/数字，捕获分类到$1，数字到$2
    location /category/ {
        rewrite /category/(.+)/(\d+)$ /archive/$1/$2 last;
    }
    # 匹配重写后的/archive/，返回捕获的内容
    location /archive/ {
        return 200 "Category:$1, ID:$2";
    }
}

重载 Nginx 后，访问http://192.168.10.101/category/tech/456，返回Category:tech, ID:456，说明捕获组成功匹配并引用。

4.4.2 set 指令：自定义变量

Nginx 的set指令用于定义自定义变量并赋值，变量可用于 Rewrite 规则、条件判断、日志记录等场景，提升配置的灵活性，语法为：

set $variable value;

实战案例：定义变量并在返回内容中引用：

server {
    listen 80;
    default_type text/plain;
    location /demo {
        set $name "Nginx";  # 定义变量$name，赋值为Nginx
        return 200 "Hello, $name!";  # 引用变量
    }
}

访问http://192.168.10.101/demo，返回Hello, Nginx!，说明变量定义并引用成功。

4.5 Rewrite 典型应用场景

Rewrite 的应用场景覆盖了 Web 服务的大部分 URL 处理需求，核心典型场景：

1. 路径美化 ：将动态 URL/index.php?id=123重写为静态 URL/product/123，提升 URL 的可读性和 SEO 友好性；
2. 旧链接迁移 ：将过期的 URL/old/page.html通过 301 永久重定向至新 URL/new/page.html，避免用户访问 404；
3. 强制 HTTPS ：将所有 HTTP 请求http://xxx.com重定向至 HTTPShttps://xxx.com，提升网站安全性；
4. 域名统一 ：将www.xxx.com和xxx.com统一重定向至其中一个域名，避免 SEO 权重分散；
5. 动态路由：为单页应用（SPA）、RESTful API 实现灵活的路由规则，适配不同的业务需求。

五、总结

Nginx 的四大核心功能 ------ 正向代理、反向代理、缓存机制、Rewrite 正则匹配，构成了现代 Web 服务架构的基础，各自承担着不同的核心作用：

• 正向代理：作为客户端的 "中间人"，实现内网管控、匿名访问和资源缓存，是企业内网网络管理的重要工具；
• 反向代理：作为服务端的 "智能调度器"，支持七层 / 四层代理，实现负载均衡、动静分离、SSL 终端，是提升服务可用性和性能的核心；
• 缓存机制：通过代理缓存缓存后端服务器响应，实现 "一次转发，多次缓存"，大幅提升服务响应速度，降低后端负载；
• Rewrite 正则：作为 URL 的 "规则引擎"，实现 URL 的重写与跳转，满足路径美化、旧链接迁移、强制 HTTPS 等多样化的业务需求。

通过本文的理论解析和实操案例，相信大家已掌握 Nginx 核心功能的配置与实战技巧。在实际生产环境中，需结合业务场景灵活组合这些功能，例如 "反向代理 + 缓存 + Rewrite" 的组合，可构建出高性能、高可用、高灵活的 Web 服务架构，满足不同规模业务的需求。

Nginx 的能力远不止于此，其模块化设计支持丰富的第三方模块和扩展功能，后续可进一步学习 Nginx 的负载均衡算法、高可用配置、安全防护（如防盗链、限流）等内容，深入挖掘 Nginx 的性能潜力。