企业官网建设流程全解析

做网站时间长了，总会遇到一类需求：旧的详情页地址要换结构、带参数的URL要统一收口、动态接口要用伪静态对外发布。每次看到这种需求，第一反应就是打开Nginx配置文件写一条rewrite。但rewrite这玩意儿，看起来就是一行正则加一个地址，真跑起来之后，重定向循环、404、参数丢失、跳到了错误的后端服务，各种情况都容易冒出来。

如果你用Nginx做过一次彻底的Rewrite改造，应该能理解我说的这种纠结。它不是在URL后面加个斜杠那么简单，而是涉及Nginx整个请求处理流程里一个独立阶段的运算规则。这篇文章不谈官方文档复读，只讲我实际配置和排障过程中沉淀下来的判断方法、语法细节、真实场景的写法，以及那些配置完才发现“原来会这样”的坑。适合正在用Nginx做站点迁移、URL结构优化、接口网关路由调整的同学参考。

1. 动手写rewrite之前，先分清你要解决的是哪类URL问题

rewrite在Nginx里被翻译成“重写”，但在实际业务里，我们遇到的URL问题分为好几种，很多人不管三七二十一，全用rewrite硬写。这种做法的后果就是配置混乱，规则互相覆盖，最后只能靠叠规则碰运气。

1.1 URL跳转、URL重写和路由分发是三种需求

先说最常见的三种场景。

第一种是URL跳转，也就是说，用户在浏览器访问老地址，需要让浏览器主动发起新地址的请求，最典型的是旧域名迁新域名、HTTP升级成HTTPS、文章旧链接变成新链接。这种情况下客户端地址栏会改变，所以响应码应该是301或302。Nginx里完成这件事有两种方式，一种是rewrite加redirect或permanent标志，另一种是直接使用return 301。两者效果看起来一样，但实现阶段不同，后面会单独讲。

第二种是URL重写，形式上是把对外比较长的动态参数地址，变成简洁的静态化地址，或者反过来，前端访问简洁地址，内部转发到真实的PHP或Java处理脚本。用户地址栏通常不会变，或者说我们不希望它变，这种情况用的是rewrite加last或break标志，让Nginx在内部用新的URI继续找location。

第三种是路由分发，其本质不是改URL，而是根据URL里的某个特征，决定把这个请求交给哪个location或哪台后端服务器。这种情况更推荐直接在location层匹配，不一定需要rewrite介入。

为什么要先分清楚这三类？因为它们的配置位置和判断标准完全不同。把跳转写成内部重写，用户会看到地址栏没变，但页面已经换成了新内容；把内部重写写成跳转，每一次请求都会多一次网络往返，而且可能把后台接口地址暴露给用户。本质上，rewrite只是发起变换动作的指令，你在哪个阶段使用它、带什么标志，直接决定了这个变换是让客户端感知，还是只在服务端内部生效。

1.2 能不用rewrite就别用，先用return和try_files试一下

可能有人会觉得，既然rewrite功能这么强，那所有URL问题都应该用它。实际经验恰恰相反，相当一部分URL问题，用return或try_files能更干净地解决。

如果只是需要返回一个固定的301或302响应，应该直接写return。return会在较早的请求处理阶段直接终止连接，生成响应头中的Location。它的效率比rewrite高，规则也更简洁，而且不会出现很多人担心的正则回溯问题。比如HTTP强制跳HTTPS，最稳妥的写法是：

server { listen 80; server_name example.com; return 301 https://$host$request_uri; }

这段配置不需要任何正则，$host保留原始域名，$request_uri保留原始完整地址，连查询参数都原封不动带上。如果用rewrite写，常见的写法是rewrite ^(.*)$ https://$host$1 permanent;，这就有个风险：如果URL里本身包含中文或特殊字符，$1拿到的是已经解码后的URI，在跳转时可能丢失编码信息，导致参数错乱。

再说伪静态场景。很多人会这样写一套“所有不存在的文件都转给index.php处理”的规则：

location / { if (!-e $request_filename) { rewrite ^/(.*)$ /index.php?/$1 last; } }

这种写法能用，它的正则看起来也不复杂。但它把“判断文件是否存在”和“URL重写”耦合在一起，每来一个静态资源请求，都要先做一次文件系统检查。相比之下，try_files的语义更清晰：

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

try_files按顺序检查文件是否存在，都不存在才把请求交给最后的/index.php，中间不需要写正则，也不会有if带来的隐患。因此，如果在写配置之前问自己一个问题：这个需求是非得正则替换不可，还是可以通过return跳转、try_files兜底、location匹配就能完成？大多数场景其实都可以用更简单的方式解决。

2. rewrite语法与正则的细节，决定了规则会不会按预期执行

当你已经确认某个场景确实需要rewrite，再来看它的语法就踏实得多。一条完整的rewrite指令长这样：

rewrite regex replacement [flag];

regex用于匹配当前请求的URI，注意不是匹配包含域名在内的完整URL；replacement是替换后的目标；flag是可选参数，控制匹配完成后是继续处理还是终止。

2.1 rewrite的匹配对象和正则需要知道的事

Nginx的rewrite指令默认匹配的是$uri，也就是经过解码、去掉了参数部分的路径。这意味着正则表达式里不需要考虑查询字符串，但也意味着我们不能在replacement里直接依赖参数结构。

所以一个很重要的常识是：如果你想根据URL里的参数来决定要不要重写，不能把这个判断写进正则本身，比如用rewrite ^.*\?id=123 /new last这种方式是无效的，因为匹配的URI本身不含问号。你需要两层思路配合：第一层用if ($arg_xxx)或$query_string判断参数条件，第二层再写rewrite根据不同参数值进行替换。

正则部分还有个容易踩的细节：Nginx的正则底层用PCRE库处理，默认是区分大小写的。如果你希望不区分大小写，正则前面要加(?i)修饰符，比如：

rewrite ^/category/(?i)apple/?$ /goods/apple last;

这段配置能同时匹配/category/apple和/category/Apple。但要注意(?i)只对它后面的部分生效，如果放在开头，通常会影响整个正则，实际项目中建议把需要忽略大小写的子串处理清楚，不要靠感觉。

捕获组是实战里最常用的能力，正则中用括号括起来的每一段，会被依次保存为$1、$2、$3。例如要做一个文章详情页的ID提取：

location / { rewrite ^/article/(\d{1,10})\.html$ /index.php?id=$1 last; }

访问/article/123.html时，内部的URI会被替换为/index.php?id=123。括号要尽量精确，写得太宽泛容易把不该进来的URL也替换掉。我在实际排查中就遇到过一个规则，写成了rewrite ^/(.*)\.html$ /index.php?id=$1 last，结果所有以.html结尾的地址，包括静态帮助页，全被吞进了动态脚本。

2.2 四个标志位的真正含义，比看起来更重要

rewrite后的flag一共有四种：last、break、redirect、permanent。它们的差别决定了这次URL变更是否继续影响后边的处理流程。

• last：停止执行当前server块或location块中的后续rewrite指令，然后把重写后的URI交给Nginx重新做一次location匹配。
• break：停止执行后续rewrite指令，但不再重新匹配location，直接在当前location继续处理。
• redirect：返回302临时跳转，常用于未确定规则是否长久有效时。
• permanent：返回301永久跳转，常用于确定性的链接结构迁移。

其中容易混淆的就是last和break。我用一种容易记住的方式来理解：

如果你改写的目标地址，希望它重新进入另一个location匹配流程，在这条规则里用last。典型例子是伪静态转发到PHP文件，因为PHP文件一般有自己的location ~ \.php$匹配块，需要last重新匹配。

如果你的rewrite就写在一个很具体的location块内，而且你只是想让后续指令在改写后的URI上继续执行，不指望它跳去别的location，用break。尤其是配合proxy_pass把规则改写成后端内部路由时，break能避免改写后的URI再次落入别的正则location，造成误匹配。

当然，也有一些团队习惯在server块内统一写rewrite规则，然后不带任何flag，让Nginx默认继续执行到末尾的location匹配阶段。这种写法在规则少的时候能工作，但规则一多，执行顺序不清晰，而且改写后的URI可能被后面的rewrite再次改动。稳妥的统一规范是：如果改写必须匹配某个location才继续处理，就用last，否则用break，尽量不依赖缺少flag时的默认行为。

2.3 标记redirect和permanent时，记得确认目标是否以http开头

有一种常见的误解是，rewrite加permanent标志就一定会跳转。实际上，replacement如果不以http://或https://开头，并且没有显式指定redirect、permanent，默认只是内部改写，不会把Location头发给浏览器。

比如这样写：

rewrite ^/old$ /new permanent;

当客户端访问/old时，Nginx确实会返回301，Location头会被补成站内URL。但如果site配置里同时用了server_name_in_redirect等变量，域名生成有的微妙差异。稳妥起见，跳转到站外地址时，replacement必须写完整协议，例如：

rewrite ^/link/(\w+)$ https://partner.example.com/go?id=$1 permanent;

另外，像301这种永久跳转，浏览器和应用都会缓存。正式上线前如果还没有完全确定新地址，先用302调，等地址确认稳定了再切301。我做过一次旧栏目迁移，最初把跳转写成permanent，结果后来发现新版页面路径少加了一层目录，但老用户和搜索引擎已经缓存了旧301地址，只能再等缓存过期。

3. 五类高频场景的rewrite写法与思路拆解

聊完语法和规则，就到了“抄作业”环节。我整理了实际项目中反复出现的几类需求，每类都给了配置和说明，你可以根据自己的情况改域名、改路径。

3.1 老地址迁移：旧URL整体换新路径

比如旧站点中所有/product/...路径要换到/goods/...，并且要告诉搜索引擎这是永久迁移，规则可以这样写：

server { listen 80; server_name example.com; rewrite ^/product/(.*)$ https://example.com/goods/$1 permanent; }

此时$1会把/product/后面剩余的所有路径原样带到新地址。由于URL中旧路径只有一层，也可以用.*消费掉剩余内容。如果旧路径有参数，前面已经提到，参数不会被匹配进这段正则中，但有一个隐藏现象需要注意：当使用rewrite生成301时，Nginx会把当前请求的$request_uri追加到新地址后面吗？不会。$1只是URI的路径部分。如果你想完整保留参数，应该在replacement里显式加上?$args：

rewrite ^/product/(.*)$ https://example.com/goods/$1?$args permanent;

但这会产生一个问题：当原URL没有参数时，新URL会以一个空问号结尾，比如https://example.com/goods/123?。为了避免这个问题，可以把判断和跳转拆开写，放在server块配合if：

server { listen 80; server_name example.com; if ($args) { rewrite ^/product/(.*)$ https://example.com/goods/$1?$args permanent; } rewrite ^/product/(.*)$ https://example.com/goods/$1 permanent; }

这样带参数的请求会走带参数跳转的规则，不带参数的请求走后一条。虽然比一个rewrite完成所有事显得繁琐，但实际线上请求类型五花八门，用这种“参数有无分支”处理，能避免目标URL出现空问号之类的瑕疵。

3.2 只转发带参数的某个URL，其他请求一律拒绝

有一类网关场景很典型：内网有一个服务，只允许接收带特定参数的请求。比如客户端的支付回调或扫码登录跳转，URL必须是/callback?token=xxx格式，不带参数的裸/callback请求，直接返回404。

服务端配置可以这么写：

server { listen 80; server_name gateway.internal; location = /callback { if ($args = "") { return 404; } proxy_pass http://backend_server/callback/verify; } }

这里用location = /callback做精确匹配，保证只有不带其它路径的/callback才会进入这个块。里面的if ($args = "")判断请求是否带参数，为空则直接终止，返回404，不再往后端转发。如果带了参数，则通过proxy_pass转发给后端服务。

这种“先条件判断再转发”的做法，比单纯在rewrite正则里嵌套参数判断清晰得多。因为proxy_pass和rewrite在同一条链路下，只要请求能到达这个location，就说明路径匹配了，接下来区分的就是参数。需要注意，if块里能安全使用的指令非常有限，日常配置中我默认只建议在if里使用return、rewrite和set这三种，它们的行为经过长期验证是可靠的。不要随便在if里挂proxy_pass，这块存在很多历史兼容问题。

如果不想使用if，还有一种更符合Nginx哲学的写法，利用map把参数通过变量转成开关：

map $args $has_args { "" 0; default 1; } server { listen 80; location = /callback { if ($has_args = "0") { return 404; } proxy_pass http://backend_server/callback/verify; } }

两种方法本质相同，主要看团队是否对if的使用规范有严格要求。

3.3 伪静态：动态地址和静态地址互相转换

伪静态，从用户视角是把/index.php?id=123&page=2变成/article/123/page/2.html，但从Nginx视角，它是把静态化的URL还原成动态脚本能识别的参数。下面是一个典型的规则：

server { listen 80; server_name example.com; location / { try_files $uri $uri/ @rewrite_to_php; } location @rewrite_to_php { rewrite ^/article/(\d+)/page/(\d+)\.html$ /index.php?id=$1&page=$2 last; rewrite ^/article/(\d+)\.html$ /index.php?id=$1 last; } }

这种写法有几个好处：第一，先把静态文件和目录交给try_files处理，只有真正不存在的静态地址才会进入命名location；第二，在命名location里写两条rewrite规则，前一条匹配带分页的地址，后一条匹配不带分页的地址。rewrite是按顺序匹配的，一旦命中就会停，不会继续往下执行。

为什么把rewrite放进命名location而不是直接在根location里写？因为要尽量避免在location /这种大范围块内做正则匹配，尽量减少对静态文件请求的干扰。把规则收拢到一个专门的命名location中，让业务规则内聚，排障时打开对应文件就能看到。

3.4 替换URL中的一段特定目录，且路径深度不同

有时URL不是整体换结构，只是中间某个路径段变了，比如后台管理地址由/admin/manage/user改成/console/manage/user。一个简单粗暴的规则是：

rewrite ^/admin(.*)$ /console$1 last;

这类规则要注意两个问题。一是.*能匹配到空字符串，所以/admin会改写成/console，如果/console正好也有独自的location，这是预期行为；二是防止把/administrator之类以admin开头的地址也误改。所以更严格的规则要使用边界描述，例如要求admin后面紧跟斜杠或结尾：

rewrite ^/admin(?:/(.*))?$ /console/$1 last;

如果你熟悉Nginx的location匹配，也可以直接在location层做：

location ^~ /admin/ { rewrite ^/admin/(.*)$ /console/$1 last; }

这样路径前缀的匹配交给location，rewrite只需要处理斜杠后面的部分。实际上，左侧前缀越明确，改写逻辑越简单，越不容易把不相干的地址卷进来。

3.5 多域名跳转和HTTP跳HTTPS的组合

对于有多域名归属的老站，经常会在一个server块里完成“非规范域名跳转”和“升级HTTPS”两件事。可以直接复用跳转能力：

server { listen 80; server_name old-site.com www.old-site.com; if ($host = "old-site.com") { rewrite ^(.*)$ https://www.old-site.com$1 permanent; } rewrite ^(.*)$ https://www.old-site.com$1 permanent; }

这个配置的逻辑是：访问老域名时，先跳到带www的域名，然后再跳到HTTPS版本。其实在这个场景下，两次跳转可以合并成一行：

server { listen 80; server_name old-site.com www.old-site.com; return 301 https://www.old-site.com$request_uri; }

无论请求来自old-site.com还是www.old-site.com，最终都会301到https://www.old-site.com。这个例子是想强调，很多步骤看起来要用rewrite逐步过渡，但return 301可以一步到位。真正需要rewrite的通常是路径层面做了结构替换的场景，域名层面的规整尽量用return完成。

4. rewrite执行阶段与location匹配，决定内部转发的最终归宿

为什么同一个rewrite，放在server块里和放在location块里，表现完全不同？这就要理解Nginx处理一个HTTP请求的大致流程。Nginx不是拿到请求后直接执行rewrite，而是先解析配置，确定这个请求要进哪个server，然后在server内部先做一系列重写阶段操作，再进入location匹配。

4.1 server级rewrite先于location匹配执行

server块内的rewrite规则，会在Nginx寻找具体location之前执行。如果你在server块里写：

server { listen 80; rewrite ^/upload/(.*)$ /storage/uploads/$1 break; location /storage/ { alias /data/files/; } }

请求/upload/avatar.png时，Nginx会先执行server里的rewrite，把它改写成/storage/uploads/avatar.png，然后再匹配到location /storage/，最终通过alias返回/data/files/uploads/avatar.png。

这里有个很容易被忽视的执行顺序：server块内的rewrite会在所有location匹配之前把URI改掉。所以如果你在rewrite规则里用了last，它就会以改写后的URI重新做一次location查找，等效于用户直接请求了新路径里的内容。

4.2 location内的rewrite配合last让请求跳到对应的带正则location

在实际项目中，最常见的rewrite场景是我前面提到的伪静态转发。比如PHP环境，通常会有这样的location配置：

location ~ \.php$ { include fastcgi_params; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; }

用户在外部访问/article/123.html时，这个URL不会匹配到.php$这个location，因为它的后缀是.html。所以必须把静态化的路径，先改写成/index.php这样的URI，并且让它重新进入location匹配阶段，找到\.php$的规则。这一步就需要last。

server { location / { rewrite ^/article/(\d+).html$ /index.php?id=$1 last; } }

用了last，Nginx会把/index.php?id=123按新URI再次匹配location，这次能进入location ~ \.php$，交给PHP-FPM执行。

如果用break替代，结果就是当前location /里继续执行后续指令，但因为没有fastcgi相关配置，请求最终会以普通文件形式匹配，多半以404告终。所以在“需要从普通路径跳到另一个专项location”的场景，必须用last。

4.3 防止内部路径被用户直接访问题，如何利用rewrite的break

有内部需求时，问题可能反过来：你反而不希望用户直接访问内部location。比如后台真实的脚本路径是/app/backend/render.php?id=xxx，但不想让别人猜测到这套结构，只开放一个公开的/render?xxx入口，Nginx内部再改成真实路径。

这种情况下，可以建一个只供内部跳转使用的命名location，配合last从公共入口跳过去：

server { location /render { rewrite ^/render/?$ /app/backend/render.php?$args last; } location @deny_direct { return 404; } location ~ ^/app/backend/ { try_files $uri @deny_direct; } }

用户访问/render?id=1，URI会被改写为/app/backend/render.php?id=1，然后重新匹配到location ~ ^/app/backend/，接着正常被PHP处理。如果用户手动访问/app/backend/render.php?id=1，同样会进入这个location，但由于没走公共入口的合法性校验，用try_files把请求推到@deny_direct，返回404。这种隔离方式，避免了内部PHP文件被外部直接扫描出来的风险。

4.4 与proxy_pass联动的rewrite，注意代理阶段后的URI

rewrite的服务端内部转发，除了给PHP这类fastcgi业务用，另一个大方向就是反向代理。Nginx作为代理层时，经常要把外部URL改写成后端服务能识别的内部路径。

假设后端服务只识别/internal/order/detail这个地址，但对外网关收到的地址是/gateway/order?orderId=123。配置可以这样处理：

server { listen 80; location /gateway/ { rewrite ^/gateway/order/?$ /internal/order/detail break; proxy_pass http://backend_cluster; } }

这里用break而不是last，是因为当请求进入location /gateway/后，改写完URL，并不需要再让Nginx重新匹配其他location，而是要直接在当前location内继续做代理操作。如果用last，改写后的/internal/order/detail可能又会被别的location截获，从而造成路由混乱。

但要注意一个问题，此时的proxy_pass如果写成：

proxy_pass http://backend_cluster;

不带URI，那么真正转发给后端时，会使用改写后的URI，也就是/internal/order/detail。如果写成：

proxy_pass http://backend_cluster/;

带了一个URI路径，即使location里已经用rewrite改写了，proxy_pass里带URI的部分也可能替换掉改写后的路径，结果可能与预期不符。Nginx中proxy_pass尾部是否带斜杠，和alias的语义有得一拼，非常容易踩坑。

建议的方案是：当你在location内用了rewrite改写URI，并且希望改写后的URI传给后端，proxy_pass就不要带URI，保持proxy_pass http://upstream;这种裸上游写法。如果proxy_pass本身带了路径（例如http://upstream/apis/），那它跟location前缀之间有自己的一套拼接规则，此时rewrite是否生效会取决于正则location的匹配方式。很多网上教程建议，只要涉及复杂改写加代理，就直接把rewrite目标设为变量，配合命名location，可以绕开proxy_pass的URI拼接迷雾：

server { location /gateway/ { rewrite ^/gateway/order/?$ /internal/order/detail break; proxy_pass http://backend_cluster$uri$is_args$args; } }

这里用$uri让proxy_pass拼接改写后的URI，$is_args判断是否带参数，$args携带参数。这种做法更透明、更可控，但如果后端地址本身已经配置了路径前缀，就要确保最终拼接结果符合后端预期，不然要去掉或调整URI部分。

5. 调试rewrite与规避经典大坑，全凭这套排查链路

rewrite虽小，却牵扯正则、变量、阶段、缓存，排障过程必须一环一环拆解。结合我自己的经验，把最常见的几类故障和排查办法列出来。

5.1 配置检查和日志定位的基本功

写完rewrite，先别着急reload，执行：

nginx -t

这一步能检查语法错误和server块里重复监听的冲突。语法没问题再执行nginx -s reload。

但语法正确不表示逻辑正确，这时候要看error日志。默认的error_log级别通常不打印rewrite匹配细节，需要临时提升：

error_log logs/error.log notice;

如果要更细的匹配过程，可以开到debug级别，并通过--with-debug编译时开启日志支持。生产环境不建议长时间开debug，它会产生海量日志，影响磁盘IO，一般排障完再调回error级别。

除了日志，curl是最快的验证手段：

curl -I http://example.com/old/123

查看响应码和Location头，判断是301还是302，Location地址中的路径和参数是否符合预期。这条命令可以在不打开浏览器的情况下反复测试不同URL变体，非常适合我们批量验证规则。

5.2 重定向循环：URL在两个规则之间反复套娃

重定向循环是最经典的rewrite问题。比如你写了一条规则，希望把不带www的地址跳转到带www的地址：

server { listen 80; server_name example.com; rewrite ^(.*)$ http://www.example.com$1 permanent; }

但如果还有一个server块监听www.example.com，并且里面也有类似的rewrite规则，比如把路径去掉某前缀，而新路径又符合第一条rewrite的条件，请求就会在两个server之间反复跳转，直到浏览器提示“重定向次数过多”。

还有一个常见的循环案例，是把HTTP跳HTTPS的规则写在HTTPS的server里。比如：

server { listen 443 ssl; rewrite ^(.*)$ https://example.com$1 permanent; }

当请求已经通过HTTPS到达这个server后，rewrite又把同一URL重写到HTTPS地址，但这条server本身就是处理该地址的，于是请求又一次进入同一个server，再次执行rewrite，无限循环。HTTP跳HTTPS的规则，只应该放在监听80端口的server块中，443的server块里正常返回业务内容。

定位这类循环，除了看error日志的rewrite or internal redirection cycle提示，还需要打开浏览器的网络面板看请求链路中Location头的变化规律，一旦发现域名或路径在两步之间反复出现，基本就能判断是哪几个规则在轮流命中。

5.3 rewrite后404，先确认内部地址能被location和实际文件接住

另一个高频问题：rewrite配置后页面还是404。比如这样：

location /download { rewrite ^/download/(.+)$ /files/$1 last; }

访问/download/setup.exe，理论上应该转发到/files/setup.exe。但如果location /files没有配置正确的alias或root规则，或者/files目录在文件系统中不存在，最终依然会得到404。

这种情况下的排查思路是：

1. 确认rewrite确实执行了，最直接的办法是在error日志查匹配到的规则行。
2. 确认改写后的URI能匹配到哪个location，可以临时在对应的location块中加一段return 200来验证。
3. 确认location下的root/alias路径正确，文件真实存在于磁盘中。

有一点要避免：在win环境或某些IDE里，路径大小写和结尾斜杠经常出问题。文件系统严格区分大小写时，/Files/和/files/是两个目录，rewrite生成的目标必须与实际路径大小写一致。

5.4 别忘了永久跳转的缓存问题

这个坑严格来说不是rewrite写错了，而是使用301后的上线流程问题。rewrite配置中加permanent会返回301，这会导致浏览器、CDN和搜索引擎同时缓存这条跳转。

有一次我在测试环境调试旧链接迁移，先用permanent跳转，后来发现目标URL的路径层级需要调整，改完后反复刷新浏览器，看到的还是旧地址。原因就是浏览器已经把请求/old/123缓存为/new/abc，后端的修改根本不会被触发。解决方法是把这类临时调整的规则先写成默认的302，或者redirect标志，等最终确认后再上线301。

如果已经发出过错误的301，而且用户手里已经缓存，只能建议用户无痕模式或清理缓存。对于线上大范围业务，这几乎不可控。所以凡是涉及永久跳转的配置，务必在正式发布前做足测试。

5.5 关于Nginx里臭名昭著的if，我建议守住两个原则

Nginx社区长期流传一句话，叫“if is evil”，核心原因在于if块中的指令行为在某些历史场景下不符合直觉，容易产生地雷。但在实践中，rewrite相关的if使用频率非常高，也并非完全不能碰。

结合了大量运维经验后，我给自己定的两个原则是：

第一，能用map或location表达的条件判断，不要用if表达。参数切换、域名切换、UA切换这些，map变量和location匹配都能以更结构化的方式完成。

第二，如果不得不用if，只允许在其中使用return、rewrite、set这三种指令，不把proxy_pass、fastcgi_pass等其它指令放进if块。比如下面的配置：

location /admin/ { if ($remote_addr !~ ^192\.168\.) { return 403; } rewrite ^/admin/(.*)$ /management/$1 last; }

这个配置中if只做了条件拦截，返回403；rewrite在if块外执行，逻辑简单清晰。遵守这两个原则后，遇到的多数组件兼容问题都能被提前绕开。

6. rewrite之外的扩展，什么时候用map和location代替重写

最后补充一种容易被忽略的思路：并非所有URL映射问题都要靠rewrite逐个写规则。当规则数量多、URL和跳转目标关系明确时，map是更优雅的方案。

map指令通常定义在http块中，它做的事情本质上是建立一个字典映射。例如：

map $uri $new_uri { default /404; /page/about /about-us; /page/contact /contact-us; /page/terms /legal/terms; }

然后在server里：

server { listen 80; server_name example.com; if ($new_uri) { rewrite ^ $new_uri permanent; } }

这段逻辑的意思是：当请求的URI能在map表中找到对应新地址时，执行跳转；找不到时，因为没有$new_uri变量（或者变量内容为空），就不执行rewrite，继续走正常处理流程。

相比一条条写rewrite正则，map方案的可维护性明显更强。尤其是URL映射清单经常变化时，只需要改map这块，不用动server里的逻辑。它的另一个优点是map是启动时一次性加载的哈希结构，性能远好于反复跑正则匹配。

类似的场景，如果跳转规则只是针对某个目录或参数条件，能用location的多层嵌套表示的，也不要硬写成规则：

location /old/ { location /old/static/ { try_files $uri =404; } rewrite ^/old/(.*)$ /archive/$1 permanent; }

这种写法，精准地把静态文件请求和动态跳转请求分流开。静态文件仍然走正常文件读取，其它路径才进入跳转逻辑，规则之间不会再互相干扰。

总之，rewrite是Nginx抵御URL变化的一把利器，但使用它的关键是理解它在请求处理流程中所处的阶段，明确它究竟是写给客户端看的跳转，还是写给内部路由看的重写。希望上面这些从场景出发的配置思路和踩坑经验，能让你在下次处理Rewrite需求时，少花一点时间在“为什么没按我的想法跳”上。