.htaccess重定向生成器实测：导入一份旧配置会丢掉多少规则

摘要：把它当规则生成器用没问题，当“接管现有配置”的工具用会出事。我们团队逐条打桩测下来：不带状态码的 Redirect /old /new 导入后解析出0条，一声不吭；RedirectPermanent 指令同样不认；能认出来的 Redirect 301 /service /new 会被回吐成 ^service$，前缀匹配被悄悄收窄成精确匹配，/service/foo.txt 从此不再跳转。还有三处：裸 [R,L] 被读成301，而Apache的默认是302；CSV导入时410被静默降成301，工具自带的示例数据就能触发；规则测试器用的是没转义的正则，比真实规则宽松，会给出和线上相反的结论。

重定向是那种“做对了没人注意，做错了半年后才发现”的活。规则写在配置文件里，不报错、不告警，浏览器该跳的跳、不该跳的静静躺着，只有排名和流量在慢慢变化。

正因为反馈这么迟钝，做这件事的工具就格外需要可信。这篇要做的是把这款生成器的每个功能挨个验一遍，看哪些结论能信、哪些不能。所有结论都来自实际调用，不是读代码推的。

这个工具的四个标签分别管什么？

界面顶部有四个标签，对应四种用法，能力差别很大。

和前面两款纯浏览器端的工具不同，这一款有真正的后端在干活。你点生成，请求会发到服务器，由服务器端的程序拼出配置代码再返回。解析和测试也都走同一条路。

这意味着你粘进去的地址清单会经过服务器。做客户站迁移、手里那份新旧地址对照表还没公开的时候，这一点值得留意。

它生成的规则长什么样？

先看一条最简单的。填入源地址 /about-us.html、目标 /about、类型选301，生成出来是这样：

<IfModule mod_rewrite.c>
RewriteEngine On

RewriteRule ^about\-us\.html$ /about [R=301,L]
</IfModule>

这条规则的结构是标准的：外面套着模块检测，避免服务器没装重写模块时整个站崩掉；里面开启重写引擎；然后是规则本身。

有个细节它做对了，值得表扬：源地址开头的斜杠被去掉了，生成的是 ^about 而不是 ^/about。这不是随手为之——Apache的文档明确说明，在目录级配置文件里，用于匹配的字符串永远不带前导斜杠，所以以 ^/ 开头的模式在这种上下文里永远匹配不上。手写规则的人在这儿栽跟头的不少，工具替你规避了。

另一个细节是特殊字符的转义。. 在正则里表示任意字符，直接写进规则会导致过度匹配。工具把它转成了 \.，只匹配真正的点号。这处理是对的——但请记住这一点，后面讲测试器的时候它是关键。

为什么导入一份现成的配置会丢规则？

这是这款工具最需要警惕的地方，而且丢得非常安静。

我们拿三种在真实配置文件里都很常见的写法去测，结果如下：

前两种全军覆没。第一种是不带状态码的写法，在Apache里完全合法，默认表示302临时跳转；第二种是 RedirectPermanent，同样是合法指令，等价于带permanent关键字的写法。工具的解析逻辑只认那几种固定格式，其余的直接跳过。

丢了会怎样？界面上会弹出一个绿色的框，写着“成功解析并导入N条重定向规则”。N是0的时候它也这么显示。你以为整份配置都进来了，实际上进来的可能只是一部分。

接下来的动作才是真正危险的：很多人导入之后会重新生成一份配置去覆盖线上文件。那些没被解析出来的规则，就在这次覆盖里消失了。原本好好跳转的地址开始返回404，而你完全不知道少了什么。

所以有一条纪律必须守住：用它导入现有配置之后，先数条数。粘进去多少条规则，界面上就该显示多少条。对不上，别往下走。

被导进来的规则，覆盖范围为什么变小了？

就算规则被成功识别出来了，它也未必还是原来那条规则。这一处更隐蔽。

我们做了一次完整的往返测试：粘进 Redirect 301 /service /new-service，工具正确识别出了这条规则。然后不做任何修改，直接点生成，回吐出来的是：

RewriteRule ^service$ /new-service [R=301,L]

看着挺像，实际上覆盖范围差了一大截。

原始的 Redirect 指令是前缀匹配。Apache的文档写得很清楚：它匹配路径前缀，超出匹配部分的路径信息会被追加到目标地址后面。所以 Redirect 301 /service /new-service 的实际效果是：/service 跳到 /new-service，/service/foo.txt 跳到 /new-service/foo.txt，整个目录树下的所有地址都会跟着走。

回吐出来的规则末尾多了个 $。这个符号在正则里表示“到此为止”，于是它变成了精确匹配——只有恰好等于 /service 的请求才会跳转，/service/foo.txt 从此不再跳，直接404。

我们顺手也用工具自己的测试器验了一下 /service/foo.txt，它回的是“无规则匹配此URL”——这倒是和它生成的规则一致，但和你原来那份配置的行为正相反。

一条覆盖整个目录树的规则，往返一趟之后只剩下一个地址还在跳。规则条数没变，界面上一切正常，只有几百个子页面在悄悄返回404。

迁移旧站的时候这类规则用得极多——整个 /blog/ 目录搬到 /articles/，一条前缀规则就能搞定。用这个工具往返处理一趟，就只剩目录首页还能跳了。

裸的 [R] 被读成301，差在哪儿？

这是解析环节的第三个问题，属于确凿的读错。

我们粘进这么一行：

RewriteRule ^old-page$ /new-page [R,L]

工具解析出来的类型是 301。

但Apache的重写标志文档写得明明白白：可以用 [R=305] 这样的语法指定任意合法状态码，不指定时默认使用302。也就是说裸写的 [R] 是临时跳转，不是永久跳转。

差别有多大？这两个状态码在搜索引擎眼里的含义几乎相反。谷歌的重定向文档说得很直接：永久跳转会被当作“目标地址才是规范网址”的信号，新地址会进搜索结果；临时跳转则不会传递这个信号，原地址可能继续留在搜索结果里。

所以这个误读的实际后果是：你导入一份配置，工具告诉你这是永久跳转，你据此认为迁移做得没问题。实际上线上跑的是临时跳转，权重一直没往新地址走，而你压根不知道要去查这件事。

反过来的风险同样存在——如果你信了工具的判断，重新生成配置时它会写成 [R=301,L]，等于把原本有意为之的临时跳转改成了永久的。永久跳转会被缓存，浏览器记住之后再想改回来相当费劲。

这条的应对很简单：解析结果里每一条的类型都要和原文对一遍。原文里凡是裸写 [R] 的，实际类型都是302。

CSV里的410为什么变成了301？

更有意思的是，触发这个问题只需要点一下工具自己的“加载示例”按钮。

那份示例数据的最后两行是这样的：

/deleted-page - 410
/expired-offer - 410

意思很明确：这两个页面已经删除，返回410告诉搜索引擎别再来了。但导入之后，这两条的类型变成了 301。

原因在解析代码里：它判断类型时只检查是不是 302，是就用302，其他一律当301。410不在判断范围内，于是被归到了默认那一类。工具自己写的示例数据，被工具自己的解析逻辑改了含义。

410和301是完全不同的两件事。410表示资源已经永久消失，MDN的说明里讲得清楚：它和404的区别在于确定性，404是“没找到，也许是临时的”，410是“确实没了，别再来了”，客户端不该重复请求，站点方也该把指向它的链接清掉。而301说的是“搬到别处了，请去那边”。

把删除页标成301，等于告诉搜索引擎“这个页面还在，只是换了地址”。它会顺着跳过去，然后发现目标是个不相干的页面——这类跳转通常会被判成软404，既没帮到旧地址，还给新地址添了噪音。

要在这个工具里做410，只能在规则构建界面里手动把类型选成410，别走CSV导入这条路。

那条目标为短横线的301会发生什么？

接着上一节。410被降成301之后，那两条规则的目标字段还留着示例里的短横线。生成出来是这样：

RewriteRule ^deleted\-page$ - [R=301,L]

这行规则在Apache里的含义比较微妙。短横线在替换位置上是个特殊符号，表示“不做替换”，路径保持原样。而后面又跟着 [R=301] 要求发起一次跳转。

两个指令合在一起，等于让服务器把这个地址永久跳转到它自己。浏览器收到之后会再请求一次，服务器再跳一次，循环就此开始，最后浏览器放弃并报出重定向次数过多的错误。页面彻底打不开。

公道地说，工具在这里给了一条警告：“目标URL应以/或http开头”。这个提示是对的，但措辞太温和了——它听起来像个格式建议，而实际后果是页面完全无法访问。

而工具自带的循环检测这时候没吭声。那套检测只比较源和目标是否字面相同，/deleted-page 和 - 显然不同，于是判定没有循环。它没有意识到短横线的特殊含义。

这一串下来是个挺完整的连锁反应：点了示例按钮，410被降成301，目标留着短横线，生成出一条自我循环的规则，循环检测看不出来，只有一条温和的格式提示。真传上服务器，那两个地址就打不开了。

规则测试器给的结论可信吗？

不太可信，因为它用的判断逻辑和它自己生成的规则对不上。

我们设了一条最普通的规则：源地址 /about-us.html，目标 /about，非正则模式。然后拿一个明显不该匹配的地址去测：/about-usXhtml——注意中间那个点被换成了字母X。

测试器的回答是：✅ 匹配成功，跳转到 /about。

但同一套参数生成出来的真实规则是 RewriteRule ^about\-us\.html$ /about [R=301,L]，点号已经被转义成了 \.，Apache只会匹配真正的点号。/about-usXhtml 在线上不会被重定向。

两个结论正好相反。

原因是测试器在比对时直接把你填的源地址当正则用，没做生成时那道转义。于是点号在测试器眼里是“任意字符”，在真实规则里是“就是那个点”。所有含点号的地址——也就是几乎所有以 .html、.php、.aspx 结尾的老地址——测试结果都会比实际宽松。

这个偏差的方向值得注意：它只会多报匹配，不会漏报。所以测试器说“不匹配”时基本可信，说“匹配”时得自己再想想。真要验证，谷歌在站点迁移文档里给的建议是用网址检查工具逐个测，或者用命令行脚本批量跑——总之要拿真实的请求去撞真实的服务器。

链式检测为什么时灵时不灵？

工具有个链式重定向检测，能发现“A跳B、B又跳C”这种应该拉直的情况。它确实有用，但触发条件比想象中脆弱。

我们做了一组对照。第一次，两条规则的源地址都带前导斜杠：

/old  →  /new
/new  →  /final

工具给出警告：“链式重定向: /old → /new → /final（建议直接指向最终URL）”。检测到了，很好。

第二次，只把第二条的源地址改成不带前导斜杠的 new，其余完全不动。工具的警告一条都没有。

而两次生成出来的规则代码一模一样：

RewriteRule ^old$ /new [R=301,L]
RewriteRule ^new$ /final [R=301,L]

同样的规则、同样的链、同样的问题，只因为你在输入框里少打了一个斜杠，警告就消失了。

原因是这样：生成规则的时候，工具会把前导斜杠统一去掉再拼进代码，所以两次结果相同；但做链式检测的时候，它用的是你原样输入的字符串，/new 和 new 被当成两个不同的东西，链就接不上了。同一份数据在两个环节用了两套口径。

这类问题在实际使用中很容易碰到——从表格里复制、从旧配置里抄、手动补录，几种来源混在一起，前导斜杠写法不统一是常态。

对策是：录完规则之后统一格式，要么全带斜杠，要么全不带。这样至少能让检测正常工作。链式重定向该拉直还是得拉直，谷歌的建议是直接指向最终地址，中间每多一跳都在消耗抓取预算。

同一个源地址写了两条，工具为什么不吭声？

这是另一个检测盲区，比链式那个更常见。

我们填了两条源地址完全相同、目标不同的规则：

/promo  →  /summer
/promo  →  /winter

工具的反应是：统计显示“总规则数2”，警告栏空的，两条规则都老老实实写进了输出文件。

但在Apache里，这两条规则只有第一条会生效。因为每条规则末尾都带着 [L] 标志，意思是“匹配上就到此为止，别再往下看了”。第二条永远等不到自己被执行的那一刻。

为什么检测不出来？因为它在做检测时是用源地址当索引来存这些规则的，同一个源地址存第二次会把第一次覆盖掉。等到检测的时候，内存里只剩一条，自然看不出冲突。而生成代码走的是另一条路径，两条都照写不误。

这种重复在真实项目里出现得很频繁：促销页改过两次方向，两个人分别加了规则；或者从两份不同的对照表里各导入了一批。文件里躺着两条相互矛盾的规则，跑起来只认第一条，而你可能一直以为生效的是后加的那条。

解决办法只能靠自己：规则录完之后按源地址排个序，重复的一眼就能看出来。或者干脆导出成CSV，丢进表格软件里用去重功能过一遍。

通配符规则里那个 $1忘了写会怎样？

整个目录搬家是最常见的迁移形态，工具支持在源地址里用星号做通配。这部分它做得不错，但有个陷阱。

正常用法是这样：源地址填 /blog/*，目标填 /articles/$1，生成出来是

RewriteRule ^blog\/(.*)$ /articles/$1 [R=301,L]

星号被转成了捕获组，目标里的 $1 会被替换成实际捕获到的那段路径。实测 /blog/2024/hello 会正确跳到 /articles/2024/hello，整个目录树一条规则搞定。

陷阱在于：目标里那个 $1 得你自己写，工具不会帮你加，也不会提醒你漏了。我们把目标改成 /articles/ 再生成一次：

RewriteRule ^blog\/(.*)$ /articles/ [R=301,L]

警告栏空空如也。而这条规则的实际效果是——/blog/ 下面所有页面，无论几百篇还是几千篇，全部跳到同一个地址。

这正是谷歌在站点迁移文档里点名反对的做法：不要把大批旧地址跳到一个不相干的单一目标。用户体验上是每篇文章都变成了列表页，搜索引擎那边则容易把这些跳转判成软404，旧地址积累的信号一点都传不过去。

而工具的循环检测同样看不出这个问题——源和目标不相同，不算循环；只有一条规则，不算链式。它的检测网眼比较大，只能捞出最直白的那两类问题。

所以凡是源地址里带星号的规则，生成之后一定要盯一眼目标里有没有 $1。这个检查花两秒，漏了就是几千个页面一起塌方。

地址后面的查询参数会跟着跳过去吗？

这个问题分两种情况，工具没有区分，得自己心里有数。

目标地址不带问号时，原来的查询参数会自动跟着走。比如规则是 /old 跳 /new，用户访问 /old?ref=weibo，会跳到 /new?ref=weibo，跟踪参数不丢。这是重写引擎的默认行为，多数场景下正是你想要的。

目标地址自带问号时，情况就变了。我们生成了这么一条：

RewriteRule ^p$ /product?id=5 [R=301,L]

这种写法下，原始请求里的查询参数不会被保留——目标自带的查询串会整个替换掉原来的。用户带着的跟踪参数、渠道标记，跳转之后全没了。

想两边都留住，需要在标志里加一个附加查询串的选项，写成 [R=301,QSA,L]。工具的界面上没有这个开关，生成的代码里也不会自动加，只能下载文件之后手动改。

这件事对做投放的团队影响不小。广告落地页改版，旧地址跳新地址，如果目标写成了带参数的形式，所有从广告来的流量在跳转那一刻就丢了归因标记，后台看到的全是直接访问。这类问题查起来相当费神，因为跳转本身工作得好好的。

301、302和410分别该在什么时候用？

工具把选择权完全交给了你，而这三个选项的后果差别很大，值得单独讲清楚。

判断标准其实只有一句话：这个变化是不是永久的？是，用301；不是，用302；页面根本不打算再有了，用410。

最常见的误用是拿302当301。有人觉得“先临时跳着，以后再说”更保险，实际效果是权重一直卡在旧地址上，新地址迟迟起不来。谷歌明确说过临时跳转不会被当作规范化信号，这不是玄学。

反方向的误用是拿301当302。永久跳转会被浏览器缓存，用户访问过一次之后，就算你在服务器上删掉了规则，他的浏览器还是会继续跳。限时活动用301，活动结束后一堆老用户被困在跳转里，处理起来相当麻烦。

410用得最少，但在特定场景下很有价值。大批下架的商品页，用410明确告诉搜索引擎“这些没了”，比让它们一直挂着404收敛得更快。这几个状态码的完整取舍，HTTP状态码怎么影响SEO那篇有更细的展开。

生成的文件传上去之前该验什么？

工具管到“生成文件”为止，后面这几步没人替你做，但每一步都能救命。

第一，备份原文件。配置文件写错足以让整个站返回500错误，而且是全站级别的。上传之前先把原文件复制一份留着，出事能秒回滚。

第二，条数对一遍。如果这份配置是导入现有文件生成的，务必核对规则条数。前面讲过，静默丢规则是这个工具最危险的行为。

第三，类型对一遍。重点看两处：原文里裸写 [R] 的都是302不是301；走CSV导入的410都被降成301了。这两类得手动改回来。

第四，找重复源。按源地址排序扫一遍，同一个地址出现两次的，留一条删一条。

第五，上线后拿真实请求撞。挑十几条地址，用能看到状态码的工具挨个请求，确认返回的码和目标地址都对。这一步不能用工具自带的测试器代替，理由前面讲透了。

这套动作里第五步最花时间也最不能省。改版之后全站扫一遍死链是标配动作，死链检测工具可以把404和跳转链一次性揪出来，比人眼挨个点快得多。

整站迁移时这套工具该怎么用？

把前面所有结论汇总成一条可执行的动线，迁移场景下按这个顺序走。

第一步，做地址对照表。这是全过程唯一真正重要的事，也是工具帮不上忙的事。旧地址从哪儿来？sitemap、服务器日志、分析工具里的落地页报告，三个来源合并去重。谷歌在站点迁移文档里的提醒值得记住：别把一大批旧地址一股脑跳到首页，那样既坑用户也容易被判成软404，应该逐个映射到内容最接近的新页面。

第二步，用规则构建功能录入。直接在表单里填，或者整理成CSV批量导入。别用配置解析功能去接管旧文件——这是本文反复强调的那个坑。旧文件里的规则该保留的手动抄进来，抄的时候顺便核对类型。

第三步，生成、检查、上传。按上一节那五条过一遍。

第四步，跳转要保留足够久。谷歌的建议是尽可能长期保留，一般至少一年。这个时间是让搜索引擎把排名信号完整转移到新地址所需要的，急不得。有条件的话干脆一直留着。

第五步，别只依赖跳转。跳转是兜底手段，不是终点。站内链接、导航、sitemap里的地址都该直接指向新地址。迁移之后记得重新生成一份网站地图，做法可以参考Sitemap生成器那篇；如果站点还有多语言版本，语言标注里的地址也得跟着换，别留下一堆指向跳转地址的标注，这个坑在hreflang生成器那篇里讲过。

还有一条容易被忽略的顺序问题：规则在文件里的排列次序是有意义的。重写引擎从上往下逐条比对，每条末尾的终止标志意味着先匹配上的先赢。所以通配符这类覆盖面广的规则应该放在后面，精确匹配的单条规则放在前面，否则前面那条大网会把后面的具体规则全挡住。

顺带说个运维层面的建议：配置文件里的规则最好按批次加注释分段，写明这批是哪次改版加的、什么时候可以清理。重定向规则只增不减是常态，几年下来文件里堆着几百条谁也不敢删的规则，每次请求都要从头比对一遍，对性能是实打实的负担。

保哥经手过的迁移里，出问题最多的从来不是规则写错，而是对照表做得不全——总有那么几百个从来没人注意过的老地址，迁移时没人想起它们，上线之后才从404报告里冒出来。这活儿没有捷径，前期把清单做扎实，后面才轻松。

常见问题解答

可以用它把现有的配置文件导入进来接着改吗？

不建议，它会静默丢规则。实测不带状态码的Redirect写法解析出0条，RedirectPermanent指令同样一条都认不出来，而这两种在真实配置里都很常见。更麻烦的是丢了之后界面照样显示绿色的成功提示，你如果据此重新生成一份去覆盖线上文件，那些没被识别的规则就永久消失了。非要导入的话，粘进去多少条就核对界面显示多少条，对不上别往下走。

为什么导入再导出之后，规则的覆盖范围变小了？

因为原始的Redirect指令是前缀匹配，而工具回吐出来的规则末尾多了个结束符，变成了精确匹配。实测Redirect 301 /service /new-service会被回吐成 ^service$ 的形式，原本 /service/foo.txt这类子路径会跟着跳转，回吐之后只有恰好等于 /service的请求才跳，整个目录树下的地址全部失效。迁移旧站时这类前缀规则用得极多，往返一趟就只剩目录首页还能跳了。

规则测试器说匹配成功，就能相信吗？

不能。测试器在比对时直接把你填的源地址当正则用，没做生成时那道特殊字符转义。实测一条 /about-us.html的规则，拿 /about-usXhtml去测，测试器报匹配成功，而真实生成的规则里点号已被转义，线上根本不会跳。偏差方向是只会多报不会漏报，所以它说不匹配基本可信，说匹配得自己再核。真要验证得拿真实请求撞真实服务器。

CSV导入的410为什么变成了301？

解析代码判断类型时只检查是不是302，其他一律归到301，410不在判断范围内。工具自带的示例数据最后两行正是410，点一下加载示例就能复现。更麻烦的是这两条的目标字段是个短横线，降级成301之后会生成一条把地址永久跳转到它自己的规则，浏览器侧表现为重定向次数过多，页面彻底打不开。要做410只能在规则构建界面手动选类型。

解析出来的类型都准吗？

有一处确定的读错：裸写的 [R,L] 会被解析成301，而Apache的文档明确说R不带状态码时默认是302。这两个码在搜索引擎眼里含义几乎相反，永久跳转会把规范化信号传给新地址，临时跳转不会。解析结果里每条类型都要和原文对一遍，原文里凡是裸写R的实际都是302。

链式重定向检测为什么有时候不报警告？

因为检测用的口径和生成用的口径不一致。生成规则时工具会统一去掉前导斜杠，检测时却用你原样输入的字符串比对。实测同一条链，两条规则的源地址都带斜杠时能正常告警，只把第二条改成不带斜杠就一条警告都没有，而生成出来的规则代码完全相同。对策是录完规则后统一格式，要么全带斜杠要么全不带。

同一个源地址写了两条规则，工具会提醒吗？

不会，实测两条源地址相同目标不同的规则，警告栏是空的，两条都写进了输出文件。但在Apache里只有第一条生效，因为每条规则末尾都带着表示到此为止的标志，第二条永远轮不到。检测不出来是因为它内部用源地址当索引存规则，重复的会互相覆盖。只能自己按源地址排序扫一遍，或者导出CSV用表格软件去重。

权威参考资料

• Apache重写标志文档——“不指定状态码时默认使用302”这句原文，是判断工具把裸写R读成301属于误读的直接依据，同页还说明了G标志返回410并隐含终止。
• Apache mod_alias模块文档——Redirect指令按路径前缀匹配、未匹配部分会追加到目标地址的说明，解释了为何往返一趟后覆盖范围会从整个目录树收窄到单个地址。
• Apache mod_rewrite模块文档——目录级配置中用于匹配的字符串永远不带前导斜杠、因而以斜杠开头的模式永远匹配不上，这一条正是工具做对的那处细节的出处。
• 谷歌重定向指南——永久跳转被用作规范网址信号而临时跳转不会的区分，也是推荐优先采用服务器端永久跳转的原文所在。
• MDN 410 Gone状态码——410与404在确定性上的区别、客户端不应重复请求、站点方应清理指向它的链接，这些说明了把删除页误标成301的实际代价。
• 谷歌网址变更的站点迁移指南——跳转至少保留一年、不要把大批旧地址跳到首页、以及用网址检查工具或命令行脚本验证跳转的具体建议。