开会员与付费前请必须阅读这篇文章，在首页置顶第一篇：（进站必看本站VIP介绍/购买须知）
本站所有源码均为自动秒发货，默认（百度网盘）
本站所有源码均为自动秒发货，默认（百度网盘）
前言：在Nginx服务器的日常运维与开发中，URL重写（rewrite）是一项核心且高频的技能。它不仅能实现URL的美化、路径的跳转，还能解决域名迁移、SEO优化、权限控制等实际问题。很多开发者在使用rewrite时，常常会陷入“规则写了不生效”“跳转逻辑混乱”的困境，本质上是对rewrite的核心原理、语法规则和执行流程理解不透彻。本文将从基础到实战，全面拆解Nginx rewrite规则，结合实例讲解其用法、技巧与避坑点，帮助大家真正掌握URL重写的“艺术”，让每一条rewrite规则都能精准发挥作用。
一、什么是Nginx rewrite？核心作用是什么？
Nginx的rewrite功能，是由ngx_http_rewrite_module模块提供的（该模块是Nginx的标准HTTP模块，默认启用），它允许我们根据预设的规则，对客户端请求的URL进行修改、跳转或转发，本质上是“请求路径的二次加工”过程。
很多人会混淆URL重写与地址转发，这里明确两者的核心区别，避免踩坑：
-
地址转发：仅发生在同一站点项目内，整个过程只产生一次网络请求，速度较快，且能传递request范围内的属性，转发目标无需完整路径。
-
URL重写：无站点范围限制，通常会产生两次请求，无法传递request属性，重写目标必须使用完整路径名表示。
rewrite的核心作用的可总结为6点，覆盖开发、运维、安全全场景：
-
URL美化：将复杂的动态路径（如
/index.php?id=123）伪装成简洁的静态路径（如/article/123.html），提升用户体验和SEO友好度。 -
域名/路径迁移：当网站域名更换、页面路径调整时，通过rewrite实现旧地址自动跳转至新地址，避免用户访问404页面，同时保留SEO权重。
-
兼容性支持：网站升级或重构后，通过rewrite兼容老版本的访问路径，保障老用户正常访问。
-
权限控制：对特定路径（如后台管理页面）进行重写或跳转，实现访问限制，提升网站安全性。
-
流量转发：运维场景中，可通过rewrite将特定请求转发至其他服务或页面（如维护页、备用服务器）。
-
伪静态实现：将动态页面伪装成静态页面，降低黑客抓取风险，同时适配搜索引擎的索引规则。
二、rewrite核心语法与执行流程
要熟练使用rewrite，首先必须掌握其核心语法和执行顺序，这是避免规则失效的关键。rewrite的核心依赖PCRE（Perl兼容正则表达式）引擎，所有匹配规则均基于正则表达式实现，建议学习时将思维从“字符串匹配”转变为“字符匹配”，多结合实例测试，更易理解。
2.1 核心语法
rewrite规则的基本语法格式如下，可配置在server块、location块或if块中：
rewrite <regex> <replacement> [flag];
各参数详解：
-
regex：正则表达式，用于匹配客户端请求的URL路径（仅匹配路径部分，不包含?后的请求参数），需遵循PCRE正则规范。 -
replacement：重写后的目标URL路径或跳转地址，可包含Nginx内置变量（如$host、$request_uri）和正则反向引用（如$1、$2）。 -
flag：可选参数，用于控制重写后的执行逻辑，是rewrite规则的“灵魂”，决定了重写后是否继续匹配、是否跳转等行为。
2.2 核心flag详解（必记）
flag参数直接决定rewrite的执行结果，常用的4个flag必须牢记，避免混淆：
|
flag
|
中文含义
|
核心逻辑
|
适用场景
|
|---|---|---|---|
|
last
|
终止当前块匹配
|
完成当前重写后，终止当前location块的rewrite匹配，将新URL交给Nginx重新匹配其他location块
|
目录别名、路径重写（需后续匹配其他location）
|
|
break
|
终止所有匹配
|
完成当前重写后，直接返回结果给客户端，不进入任何后续location匹配
|
简单路径替换（无需后续匹配）
|
|
redirect
|
临时重定向
|
返回302状态码，客户端下次仍会请求原URL，搜索引擎不更新索引
|
活动页面临时迁移、临时跳转
|
|
permanent
|
永久重定向
|
返回301状态码，客户端会缓存新URL，下次直接访问新地址，搜索引擎更新索引
|
域名更换、旧路径永久迁移（SEO友好）
|
关键区别：
last和break属于服务端内部重写，客户端地址栏不会变化；redirect和permanent属于客户端跳转，地址栏会显示新的URL。2.3 rewrite执行流程（重点）
很多开发者写的rewrite规则不生效，核心原因是不了解其执行顺序。Nginx处理rewrite的流程如下，按顺序执行，不可逆：
-
客户端发送请求至Nginx，Nginx先匹配server块（根据监听端口、server_name）；
-
进入匹配到的server块后，先执行server块内的rewrite规则（按从上到下顺序）；
-
执行完server块的rewrite后，根据重写后的URL，匹配对应的location块；
-
进入location块后，执行location块内的rewrite规则（按从上到下顺序）；
-
根据rewrite的flag，决定是否继续匹配、跳转或返回结果。
注意：同一区块（server或location）内的多条rewrite规则，按“从上到下”顺序执行，一旦某条规则匹配成功并触发
break或permanent/redirect，后续规则将不再执行；若触发last，则终止当前区块的rewrite，重新匹配location。三、rewrite依赖：if指令与常用匹配条件
rewrite常与if指令配合使用，实现“条件性重写”——根据不同的条件（如文件是否存在、请求方法、请求头）执行不同的重写规则。if指令可配置在server块或location块中，核心用于条件判断。
3.1 if指令基本语法
if (condition) { # 条件为真时执行的rewrite规则或其他配置 }
其中
condition是判断条件（true/false），支持5种常见设置方式：3.2 常用条件判断方式
-
变量判断：直接使用Nginx内置变量，若变量值为空字符串或以“0”开头的字符串，if判断为false，否则为true。 示例：
if ($slow) { rewrite ^/ /slow-page.html break; } -
等于/不等于判断：使用
=（等于）或!=（不等于）比较变量与字符串（字符串无需加引号）。 示例：if ($request_method = POST) { return 405; }（禁止POST请求） -
正则匹配判断：变量与正则表达式之间用
~（大小写敏感）、~*（大小写不敏感）、!（匹配失败为真）、!~*（大小写不敏感匹配失败为真）连接。 示例：if ($http_user_agent ~ MSIE) { rewrite ^/ /ie-compatible.html last; }（IE浏览器跳转到兼容页面） -
文件/目录存在判断： 示例：
if (!-f $request_filename) { rewrite ^/ /404.html break; }（文件不存在跳404）-
-f：请求的文件存在则为真，!-f：文件不存在且所在目录存在则为真； -
-d：请求的目录存在则为真，!-d：目录不存在且上级目录存在则为真； -
-e：请求的文件或目录存在则为真，!-e：文件和路径上的目录都不存在则为真； -
-x：请求的文件可执行则为真，!-x：文件不可执行则为真。
-
注意：若正则表达式中包含右花括号
}或分号;，必须给整个正则表达式添加引号，否则会导致配置报错。四、rewrite实战案例（直接套用，覆盖高频场景）
理论结合实践才是掌握rewrite的关键，以下案例均为生产环境高频场景，配置后需执行
nginx -t检测语法，再用systemctl reload nginx重载配置即可生效，每例均带详细解读。案例1：URL美化（伪静态，SEO优化）
场景：将动态路径
/index.php?id=123（文章ID为123）重写为简洁的静态路径/article/123.html，地址栏不变（内部重写）。server { listen 80; server_name example.com; # 替换为你的域名 root /usr/share/nginx/html; # URL美化：/article/数字.html → /index.php?id=数字 location /article/ { # 正则匹配：/article/后跟数字，以.html结尾 rewrite ^/article/(\d+)\.html$ /index.php?id=$1 last; # $1是正则中括号捕获的内容（即文章ID），last表示重新匹配location } # 处理PHP请求（需提前配置PHP环境） location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }
解读：用户访问
http://example.com/article/123.html，Nginx内部将其重写为http://example.com/index.php?id=123，地址栏不变，既美化了URL，又不影响后端逻辑，同时提升SEO收录率。案例2：域名永久跳转（域名迁移，SEO友好）
场景：旧域名
old.example.com迁移至新域名new.example.com，要求所有访问旧域名的请求，均永久跳转到新域名的对应路径，保留SEO权重。server { listen 80; server_name old.example.com; # 旧域名 # 匹配所有路径，永久跳转到新域名 rewrite ^/(.*)$ http://new.example.com/$1 permanent; # ^/(.*)$：匹配所有路径，$1捕获除根路径外的所有内容 # permanent：301永久重定向，搜索引擎会更新索引至新域名 }
解读：访问
http://old.example.com/article/123.html，会自动跳转到http://new.example.com/article/123.html，地址栏显示新域名，且浏览器会缓存跳转记录，下次直接访问新域名。案例3：HTTP自动跳转至HTTPS（生产环境必备）
场景：用户输入
http://example.com（HTTP协议），自动跳转到https://example.com（HTTPS协议），强制加密访问，提升网站安全性。# 监听HTTP 80端口，处理跳转 server { listen 80; server_name example.com; location / { # 条件判断：仅当访问域名为example.com时跳转 if ($host = example.com) { rewrite ^/(.*) https://example.com/$1 permanent; } } } # 监听HTTPS 443端口（需提前配置SSL证书） server { listen 443 ssl; server_name example.com; # SSL证书配置 ssl_certificate /usr/local/nginx/ssl/example.com.crt; ssl_certificate_key /usr/local/nginx/ssl/example.com.key; # 其他配置（如root、location等） root /usr/share/nginx/html; index index.html index.php; }
案例4：目录重写（隐藏真实路径）
场景：客户端访问
/mp3路径（如http://example.com/mp3/song.mp3），实际指向服务器内的/music目录，隐藏真实路径，提升安全性。server { listen 80; server_name example.com; root /usr/share/nginx/html; # 匹配/mp3下所有子路径，重写至/music目录 rewrite ^/mp3/(.*)$ /music/$1 last; location / { index index.html; } }
解读：用户访问
http://example.com/mp3/song.mp3，实际访问的是服务器内/usr/share/nginx/html/music/song.mp3，地址栏仍显示/mp3/song.mp3，隐藏了真实的/music目录。案例5：维护页面跳转（运维场景）
场景：网站后台维护期间，所有访问
/admin（后台路径）的请求，均跳转到维护提示页面/maintain.html，其他路径正常访问。server { listen 80; server_name example.com; root /usr/share/nginx/html; # 匹配后台路径，跳转到维护页面 location /admin/ { rewrite ^/admin/(.*)$ /maintain.html break; # break：重写后直接返回维护页面，不继续匹配其他规则 } location / { index index.html; } }
五、rewrite常见坑点与避坑技巧（必看）
很多开发者在使用rewrite时，明明规则写得“正确”，却始终不生效，以下是最常见的5个坑点，结合技巧逐一避坑：
坑点1：正则表达式匹配错误
问题：正则表达式书写不严谨，导致无法匹配目标URL（如漏写锚点
^、$，导致部分匹配）。 示例：想匹配/article/123.html，却写了rewrite /article/(\d+)\.html /index.php?id=$1 last;（漏写^和$），会导致/xxx/article/123.html也被匹配。 技巧：匹配具体路径时，务必加上^（开头）和$（结尾），精准匹配URL；同时可使用在线PCRE正则测试工具，提前验证正则的正确性。坑点2：flag使用错误
问题：混淆
last和break，导致重写后无法匹配后续location，或规则执行异常。 技巧：若重写后需要继续匹配其他location（如PHP请求），用last；若重写后无需后续匹配（如跳404、维护页），用break；跳转场景优先用permanent（永久）或redirect（临时），避免用last/break导致跳转失效。坑点3：rewrite执行顺序错误
问题：将优先级高的规则写在后面，导致被前面的规则覆盖，无法执行。 示例：先写
rewrite ^/ /index.html last;（匹配所有路径），再写rewrite ^/article/(\d+)\.html$ /index.php?id=$1 last;，后者永远不会执行。 技巧：同一区块内的rewrite规则，按“优先级从高到低”排列，具体路径（如/article/xxx）的规则写在前面，通用路径（如^/）的规则写在后面。坑点4：忘记重载Nginx配置
问题：修改rewrite规则后，未重载Nginx配置，导致规则不生效。 技巧：修改配置后，必须执行两步操作： 1.
nginx -t：检测配置文件语法是否正确（避免报错）； 2. systemctl reload nginx：重载配置，使规则生效（无需重启Nginx，不影响现有连接）。坑点5：变量使用错误
问题：使用未定义的变量，或反向引用错误（如$1、$2的顺序与正则括号顺序不匹配）。 技巧：使用变量前，确认变量已定义（如Nginx内置变量）；正则反向引用时，$1对应第一个括号捕获的内容，$2对应第二个括号，依次类推，避免顺序混淆。
六、总结与扩展
Nginx rewrite规则的核心，是“正则匹配+逻辑控制”——通过精准的正则表达式匹配请求URL，再通过flag控制重写后的执行逻辑，最终实现URL美化、跳转、权限控制等需求。掌握rewrite，不仅能解决日常运维中的高频问题，还能提升网站的用户体验和安全性。
本文从基础概念、语法、执行流程，到实战案例、避坑技巧，全面覆盖了rewrite的核心知识点。建议大家在学习时，多动手测试案例，结合自身业务场景灵活调整规则，同时牢记“正则要精准、flag要对应、顺序要合理”这三个核心原则，就能避免大部分问题。
扩展建议：若需更复杂的重写逻辑（如多条件组合、动态变量拼接），可结合Nginx的
set指令（定义自定义变量）、return指令（直接返回状态码）配合使用，进一步提升rewrite的灵活性。最后，若你在使用rewrite时遇到具体问题，可在评论区留言，一起交流探讨～ 原创不易，点赞收藏，后续持续更新Nginx实战干货！
