伪静态规则生成器的十个预设能直接抄，转换出来的Nginx规则得盯着改

摘要：这个工具有四个功能区，成色差别很大。预设区是可以直接抄走的，十个预设里Apache和Nginx两栏基本都给了完整规则；但IIS那一栏有四个只写了一句"请参考某某规则"，点开是空的。转换区风险最高——保哥把WordPress官方的.htaccess丢进去转Nginx，两条决定成败的条件语句被降级成了注释，剩下一条无条件重写，照抄上线整站静态资源全挂。同一款工具的预设区给的Nginx配置反倒是对的。这篇把四个区挨个实测了一遍，告诉你哪些能抄、哪些得盯着改。

伪静态规则这东西有个特点：写错了不一定马上报错，但一定会在某个时刻集中爆发。可能是搜索引擎某天开始收录一堆重复URL，可能是改版之后老链接全变404，也可能是某个静态资源莫名其妙返回了HTML。

更麻烦的是，它横跨三种服务器，三种语法，三套思维方式。Apache那套条件加标志的写法，搬到Nginx上完全不成立；IIS那套XML，跟前两者更是两个世界。于是"找个工具帮我生成"就成了很自然的想法。

伪静态规则生成器就是干这个的。保哥把它四个功能区全部拿真实规则跑了一遍，结论是：能用，但得知道哪一块靠谱、哪一块只能当草稿。

这个伪静态规则生成器有哪四个功能区？

打开页面顶部是四个标签，对应四种完全不同的用法。分不清这四个的定位，很容易拿错工具干错活。

后端是真在算，不是前端拼字符串

这四个区都走服务端接口，请求体是JSON，服务端解析完再把结果发回来。这意味着规则的拼装、解析、转换逻辑都在服务端，不是浏览器里几行正则糊出来的。

好处是逻辑相对完整，比如解读区能识别十几种指令和七八种标志。代价是每次操作都有一次网络往返，断网就用不了。这跟保哥笔记工具站里那些纯前端的工具是两种路子。

三个服务器按钮是全局开关

页面上那排Apache、Nginx、IIS按钮不是某个功能区专属的，它管着预设和构建器两块的输出格式。切了服务器，同一份配置吐出来的东西完全不同。

这里有个容易忽略的点：切换服务器不会重新校验你已经填好的规则。你按Apache的思路填的正则，切到Nginx照样给你生成，但语义可能已经变了。后面会专门讲这件事。

另外解读区和转换区有各自独立的服务器选择，跟顶部那排按钮不是一套。转换区要的是"从哪儿转到哪儿"两个值，跟生成用的那个全局开关没关系。第一次用容易在这儿绕一下，以为顶部选了Nginx转换就会转成Nginx。

下载按钮会按服务器给扩展名

生成结果那一栏除了复制还有个下载，扩展名跟着当前服务器走：Apache给.htaccess，Nginx给.conf，IIS给.config。这个小设计挺省事，尤其是IIS那份XML，手工存文件时很容易存错后缀。

但要注意它只管扩展名，不管文件该放在哪儿。.htaccess得放到对应目录下才生效，Nginx那份.conf要么include进server块要么手工并进去，IIS那份得是站点根目录的web.config。工具不会提醒这些。

十个预设里，哪些能直接抄走？

预设区是这个工具最实在的部分。十个预设，六个是框架或CMS，四个是通用场景。保哥把十个预设乘三个服务器共三十种组合全部取回来，数了数每份里到底有几行真指令。

四个预设的IIS版是空头支票

表里那四个粗体的零，是实测数出来的：ThinkPHP、Drupal、Joomla、Next.js这四个预设，切到IIS之后返回的内容里一行可执行指令都没有，全是注释。

内容大致是"请参考WordPress的IIS规则"或者"请参考Laravel的IIS规则并调整index.php路径"。作为提示它不算错，但如果你是奔着"一键生成"来的，选完预设复制走，粘到web.config里会得到一段什么都不做的配置。

好在这四个的替代路径就写在注释里，照着WordPress或Laravel那两份改路径确实能用。所以更准确的说法是：这四个预设的IIS版需要手工二次加工，不是拿来即用。

Joomla和末尾斜杠的Nginx版偏薄

Joomla的Nginx版只有3行，末尾斜杠的Nginx版更是只有1行指令。它们不是占位，是真规则，只是给得非常克制。

末尾斜杠那条尤其要当心。一行rewrite规则确实能把不带斜杠的URL跳到带斜杠，但它没有排除静态文件，也没有排除已经带斜杠的路径。Apache那一栏给了四行，多出来的正是这些防护条件。跨栏对比一下，你会更清楚Nginx那行少了什么。

四个通用场景预设比CMS预设更值钱

强制HTTPS、www跳转、末尾斜杠、单页应用这四个不绑定任何框架，是纯粹的场景配方。它们的复用价值反而比CMS预设高——CMS的伪静态规则官方文档里都有，而这四件事每次都要现查语法。

www跳转那份还额外给了双向写法：非www跳www的规则在上面，www跳非www的注释在下面，改一改就能反过来用。末尾斜杠也是同样的处理，加斜杠和去斜杠两套都给了。这种"给一份、附一份反向的"做法省掉了一次搜索。

选哪个方向不是技术问题是决策问题：站点已经被收录的那批URL是什么形态，就往哪个方向统一，别为了好看去改已经有排名的形态。

选错预设名会拿到一行提示

顺手试了个不在列表里的名字，返回的是一行"未找到对应预设"的注释。不会报错，也不会给你一个空串——这个处理算是体面的，至少你复制走之后能一眼看出不对劲。

同样两条规则，三种服务器的输出差在哪？

光看预设感觉不出差别，得拿同一份输入喂给三种服务器。保哥用了两条最常见的规则：一条挡住.env文件不让访问，一条把老路径临时跳到新路径。

Apache的输出

# 挡env
RewriteRule \.env$ - [F,L]

# 临时搬家
RewriteRule ^old/(.*)$ /new/$1 [R=302,L]

标志写在方括号里，F是禁止访问，R=302是临时重定向，L表示到此为止不再往下匹配。这是Apache最标准的写法。

Nginx的输出

# 挡env
location ~ \.env$ { return 403; }

# 临时搬家
rewrite ^old/(.*)$ /new/$1 redirect;

思路完全变了。禁止访问不再是一条重写规则加标志，而是一个独立的location块直接返回403。重定向的临时与永久，靠结尾的redirect和permanent两个词区分。

IIS的输出

<rule name="挡env" stopProcessing="true">
  <match url="\.env$" />
  <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
</rule>
<rule name="临时搬家" stopProcessing="true">
  <match url="^old/(.*)$" />
  <action type="Redirect" url="/new/{R:1}" redirectType="Found" />
</rule>

整个变成XML，规则要有名字，捕获组的引用写法从美元符号加数字变成了花括号包着的R冒号数字。临时重定向对应的是Found这个词，永久重定向对应Permanent。

这三份是不等价的，别当成翻译

把三份放一起看会发现一件事：正则表达式那部分长得几乎一样，但它们匹配的对象并不相同。Apache的RewriteRule在.htaccess里匹配的路径默认不带前导斜杠，Nginx的rewrite匹配的是带前导斜杠的完整URI。

所以像^old/(.*)$这种写法，在Apache的.htaccess里能匹配上，直接搬到Nginx很可能就匹配不上了——因为Nginx看到的字符串开头是斜杠。这个差异不会报错，只会静静地不生效，然后你对着一条语法完全正确的规则查一下午。

关于Apache这一侧的标志和条件到底怎么运作，保哥在Apache mod_rewrite重写规则到底怎么写才不绕晕？里从引擎的执行顺序讲起，配着这篇看更容易理解为什么两边搬不动。

捕获组的引用写法三家都不一样

再看一处细节：同样是"把匹配到的第一段原样搬到目标里"，Apache写成美元符号加1，Nginx也是美元符号加1，IIS写成花括号里的R冒号1。前两家凑巧一致，IIS单独一套。

这个差异在手工改规则时是头号笔误来源。从网上抄一段IIS规则改成Apache用，花括号那部分忘了改，结果就是目标地址里凭空多出一串字符。工具在生成时会按当前服务器给对写法，但你手工二次编辑的时候它就管不着了。

顺带说一句，IIS那个R其实是rule的意思，指的是当前规则的match捕获；如果引用的是条件里的捕获，前缀要换成C。这是IIS URL Rewrite特有的一层区分，Apache和Nginx没有对应概念。

把WordPress的.htaccess丢进转换器，为什么整站静态资源会挂？

这是保哥这次实测里最该说清楚的一件事。

WordPress官方那段.htaccess几乎人人见过，长这样：

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

把它原样丢进转换区，选Apache转Nginx，得到的是：

# RewriteBase /
rewrite ^index\.php$ - last;
# [条件] RewriteCond %{REQUEST_FILENAME} !-f (需手动转为Nginx if语句或location块)
# [条件] RewriteCond %{REQUEST_FILENAME} !-d (需手动转为Nginx if语句或location块)
rewrite . /index.php last;

两条条件被降级成了注释

原文里那两条RewriteCond是整段规则的灵魂。它们说的是：只有当请求的目标既不是一个真实存在的文件、也不是一个真实存在的目录时，才把请求交给index.php。

正因为有这两条，你的图片、样式表、脚本才能被直接读取，而不是全被塞进PHP。

转换之后，它们变成了两行注释。工具确实在注释里写了"需手动转为Nginx if语句或location块"，提示是给了的。但注释不执行，剩下能执行的只有最后那行。

剩下那行是无条件的

看清楚最后一行：rewrite . /index.php last;。那个点在正则里是"任意一个字符"，配上没有任何条件约束，等于说：任何请求，只要URI里有至少一个字符，全部重写到index.php。

照抄上线会发生什么？CSS请求返回HTML，JS请求返回HTML，图片请求返回HTML。页面能打开，但样式全没了，控制台里一片红。

顺带一提，第二行那个rewrite ^index\.php$ - last;也有问题。Apache里目标写成一个减号表示"不改写URL"，Nginx没有这个约定，它会老老实实把减号当成要替换成的目标路径。

讽刺的是，同一款工具的预设区给的是对的

回到预设区，选WordPress，切Nginx，拿到的是这个：

location / {
    try_files $uri $uri/ /index.php?$args;
}

一行try_files把整件事办得干干净净：先找同名文件，再找同名目录，都找不到才交给index.php。这正是那两条被注释掉的条件想表达的意思，只不过Nginx用一个指令就实现了。

所以同一个需求，这款工具的两个功能区给出了一对一错两份答案。结论很清楚：能用预设的时候，永远优先用预设，别用转换。转换只在预设覆盖不到的时候才拿来打个草稿。

WordPress在Nginx上的伪静态本来就是重灾区，尤其是后台路径那一块，保哥在WordPress Nginx伪静态后台404修复指南里单独处理过这个场景。

强制HTTPS那条规则转成Nginx，为什么会转出一个死循环？

另一个高频场景，翻车方式更狠。

Apache侧的原文是这样：

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

转成Nginx之后：

# [条件] RewriteCond %{HTTPS} !=on (需手动转为Nginx if语句或location块)
rewrite ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} permanent;

条件没了，等于对所有请求无条件跳转

原文那条条件说的是"当前不是HTTPS的时候才跳"。条件一没，就变成了不管当前是不是HTTPS都往HTTPS跳。

已经是HTTPS的请求进来，被跳到HTTPS；跳过去还是HTTPS，再跳一次。浏览器转几圈之后放弃，给你一个重定向次数过多的错误页。

而且用的还是永久重定向

这是雪上加霜的地方。规则末尾是permanent，也就是301。301是会被浏览器缓存的，而且缓存得相当顽固；搜索引擎那边也会把它当成一次正式的地址变更来处理。

换句话说，即便你十分钟后发现问题改回来了，那段时间访问过的浏览器可能还在按老规则跳，得手工清缓存或者等缓存过期。302那种临时重定向就没这个后遗症——这也是为什么涉及不确定的改动时，先用302试水是个好习惯。

那两个百分号花括号是Apache方言

还有一处更隐蔽：%{HTTP_HOST}和%{REQUEST_URI}是Apache的服务器变量写法。Nginx压根不认识这套语法，对应的是$host和$request_uri。

转换器原样保留了它们，所以生成的规则里这两串会被当成字面量。真跑起来，用户会被跳到一个域名里带着百分号和花括号的地址上去。

好在Nginx对这类配置通常在加载时就会报怨，不至于一路错到线上。但如果你是在容器里reload，没盯日志，一样会漏过去。

这类改动上线之后最该做的事是全站扫一遍链接健康度，看有没有新增的重定向链和404。做法在死链检测工具一次揪出改版后全站404与重定向链里写过。

转换器为什么只认Apache和Nginx这一个来回？

既然工具主打三服务器全覆盖，转换是不是六个方向都支持？实测下来不是。

凡是涉及IIS的方向都不支持

拿同一段Apache规则，选转成IIS，返回的是一句"该转换方向暂不支持自动转换，请参考手动调整"，后面把原始规则逐行注释着还给你。

这个处理其实挺得体——它没有硬转出一份看着像模像样、实际跑不通的XML来骗你。明确说不支持，比给个半成品强。

所以真正能用的只有Apache转Nginx和Nginx转Apache这一个来回。三服务器指的是生成能力，不是转换能力，这两件事在页面上没有分得很清楚。

就算这一个来回，也不是可逆的

保哥试了一次往返：把Nginx那两条规则转回Apache。

RewriteEngine On

RewriteRule ^old/(.*)$ /new/$1 [R=301,L]
# location ~ \.env$ { return 403; }

重定向那条转回来了。但挡.env的那个location块，被整行注释掉了。

也就是说，Apache转Nginx的时候防护规则能转过去，Nginx转回Apache的时候它就丢了。如果你拿转换器做一次往返迁移，最后那份配置里少了一条安全规则，而且不会有任何警告。

这类"静默丢失"是所有自动转换工具的通病：语法层面能对上的照搬，对不上的降级成注释，而注释在配置文件里等于不存在。所以用转换器之后，最该做的不是看生成了什么，而是数一数行数对不对得上。

规则解读能读懂什么，又会读错什么？

解读区是拿来看别人配置的。贴一段规则进去，它逐行给中文解释。这个功能对接手老项目的人挺有用，但也有两处得留神。

它读不懂IIS，包括这个工具自己生成的

保哥做了个有点损的测试：把这个工具自己生成的IIS配置，原样贴回它自己的解读区。

结果四行全部被判成"其他，未识别的指令行"。自己产的自己不认。

原因不难理解，解读逻辑是按行匹配Apache和Nginx的指令关键字写的，XML那套标签结构完全不在识别范围内。但页面上的服务器切换按钮里明明有IIS，容易让人以为解读也支持。

所以解读区的实际适用范围是：Apache的.htaccess，以及Nginx的rewrite和location配置。手里拿的是web.config的话，这个区帮不上忙，去查IIS强制HTTPS跳转：URL Rewrite5步实战那种针对性的文章更快。

它读得最好的是条件语句

说完毛病也得说说它强在哪。解读区对RewriteCond的处理是整个功能里最见功夫的一块：它会把服务器变量翻成中文，再把匹配模式翻成人话，最后拼成一句完整的条件描述。

比如那条判断文件是否存在的条件，它给出的是"当请求的文件路径不是一个真实存在的文件时，执行下一条RewriteRule"。这句话把感叹号和短横线f这两个符号背后的意思讲全了，对不熟悉Apache写法的人来说，比查文档直观得多。

常见的服务器变量它认得七八个，请求路径、请求URI、域名、是否HTTPS、端口、用户代理、查询参数都在里面。碰到不认识的变量它会原样保留，不会硬编一个解释出来，这个处理也算克制。

PT标志会被读成代理请求

这个错更隐蔽。保哥贴了一条ThinkPHP风格的常见规则：

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?s=/$1 [QSA,PT,L]

解读给出的标志说明是：最后一条规则、保留原有查询参数、代理请求。

前两个对，第三个错了。方括号里是PT不是P。PT是passthrough，意思是把重写结果交给后续的处理器继续处理；P才是proxy，那是真的走反向代理，需要额外的模块支持。两者行为差得很远。

问题出在匹配方式上——它是在标志串里找有没有出现字母P，而PT里恰好含P。这跟前一篇讲Emoji搜索时遇到的子串匹配是同一类毛病：不看边界，只看有没有出现过。

实际影响是：如果你照着解读的说法去理解一份陌生配置，可能会以为这个站配了反向代理，然后花时间去找根本不存在的上游服务。看到"代理请求"这四个字时，回头确认一下方括号里到底写的是P还是PT。

规则贴上去之前，该验哪几件事？

不管规则是抄的、拼的还是转的，上线前这几步能挡掉绝大多数事故。

先数行数，再看内容

把生成的规则和你的原始需求逐条对一遍，重点看有没有条目在中途消失。转换器丢东西的时候是安静的，只有数量对不上才看得出来。

尤其注意两类容易蒸发的：条件语句和安全类规则。前者会被降级成注释，后者在跨服务器时经常没有对应写法。

确认正则匹配的是带斜杠还是不带斜杠

这是Apache和Nginx之间最常见的静默失效点。规则从一边搬到另一边，先把开头那个斜杠的问题捋清楚，能省下大量排查时间。

永久重定向先用临时的试

任何拿不准的跳转规则，先用302上线跑两天，确认没有循环、没有跳错目标，再改成301。301一旦被缓存和收录，回滚成本高得多。

关于301在搜索层面到底意味着什么、什么时候该用什么时候不该用，网站URL用扁平还是层级，SEO上到底差在哪？含301改版实战里结合改版场景讲得比较细。

上线后立刻看一眼日志和抓取

规则生效之后，先看服务器日志里有没有突然多出来的重定向和403，再看搜索控制台那边的抓取报告有没有异常。改错的规则通常在几小时内就会在日志里露出马脚。

如果已经出现了404，别等它自己好，按GSC404错误修复：301重定向与软404排查实战的路子处理掉。

三档用法，对应三种人

把上面的结论收成三种典型用法。

第一档，只抄预设

适合刚搭好站、要把伪静态跑起来的人。选框架、选服务器、复制、粘贴，结束。注意避开那四个IIS版是空注释的预设，其余的可以直接用。

这一档的收益最扎实，风险也最低，因为预设是人工写好的，不经过任何自动转换。

第二档，用构建器拼自定义规则

适合有具体需求的人：某个老栏目要整体跳走、某类文件要挡掉、某个路径要重写。构建器覆盖重定向、重写、禁止访问这几种常见类型，填好之后按目标服务器生成。

这一档要留心的是，构建器不校验你填的正则在目标服务器上是否成立。它负责语法拼装，语义得你自己把关。

第三档，读别人的配置

适合接手老项目、或者要看懂运维给的一段规则的人。把配置贴进解读区，逐行看中文说明，比对着文档一个个查快得多。

记住两条边界：IIS的XML它不认；看到"代理请求"先确认是P还是PT。

转换区放在哪一档

严格说它不该单独算一档。它的正确用法是当草稿纸：需要把一份Apache配置搬到Nginx时，先扔进去看个大概结构，然后把每一条对着目标服务器的文档重写一遍。

把转换结果直接粘进生产配置，前面那两个例子已经说明后果了。这个工具在注释里其实一直在提醒你"需手动转"，只是那句话太容易被当成背景音。

常见问题解答

预设生成的规则可以直接用吗？

Apache和Nginx两栏基本可以直接用，都是人工写好的完整规则。IIS那一栏要看具体预设：WordPress、Laravel和四个通用场景给的是真规则，而ThinkPHP、Drupal、Joomla、Next.js这四个只有注释提示，需要照着WordPress或Laravel那两份改路径。

为什么把.htaccess转成Nginx之后网站样式全没了？

因为原文里那两条判断"文件或目录是否真实存在"的条件在转换时被降级成了注释，只剩一条无条件重写规则。结果是所有请求包括CSS、JS、图片都被重写到了入口文件。正确做法是改用Nginx的try_files指令，或者直接用这个工具预设区给的Nginx版本。

转换功能支持哪些方向？

只支持Apache转Nginx和Nginx转Apache。任何涉及IIS的转换方向都会返回一句不支持的提示，并把原始规则注释着还给你。而且这一个来回也不是完全可逆的，Nginx的location块转回Apache时会被整行注释掉。

同一条正则从Apache搬到Nginx为什么不匹配？

因为两者匹配的字符串不一样。Apache在.htaccess里匹配的路径默认不带前导斜杠，Nginx的rewrite匹配的是带前导斜杠的完整URI。像以old开头的正则在Apache里能命中，搬到Nginx就命中不了。这种情况不报错，只是规则静默不生效。

解读功能能看web.config吗？

不能。解读逻辑是按行匹配Apache和Nginx的指令关键字写的，XML标签结构不在识别范围内。实测把这个工具自己生成的IIS配置贴回解读区，四行全部被判为未识别指令。手里是web.config的话，这个功能帮不上忙。

解读说某条规则是代理请求，可信吗？

要先确认方括号里写的是P还是PT。判断逻辑是在标志串里查有没有字母P，而PT里恰好含P，所以带PT的规则会被误报成代理请求。PT是把结果传递给后续处理器，P才是真正走反向代理，两者行为差别很大。

新规则上线前怎么降低风险？

四步：把生成的规则条数和原始需求逐条对一遍，看有没有中途消失的；确认正则里前导斜杠的处理符合目标服务器；拿不准的跳转先用302上线，跑稳了再改301；生效后立刻查服务器日志和搜索控制台的抓取报告。

权威参考资料