灵活应用 Nginx Rewrite：实战经验与实用方法

Nginx Rewrite 顺序优先级

 location =) > (location 完整路径) > (location ^~ 路径) > (location ~,~* 正则顺序) > (location 部分起始路径) > (/)

具体而言，当 Nginx 匹配请求 URL 时，先按照完全匹配（location =）进行匹配，然后是完整路径匹配（location 完整路径），接着是路径前缀匹配（location ^~ 路径），再然后是正则表达式匹配（location ~,~* 正则顺序），最后是部分起始路径匹配（location 部分起始路径），如果都没有匹配成功，则使用 / 作为默认匹配。

Nginx Rewrite Flag

Nginx Rewrite 指令中的 flag 用于控制重写操作的行为，常见的 flag 有以下几种：

last：相当于 Apache 中的 [L] 标记，表示完成重写操作，并跳过后续的 Rewrite 指令，直接选择下一个匹配的 location 进行处理。

break：终止当前匹配，不再执行后续的 Rewrite 指令，并使用当前重写后的 URL 进行请求处理。

redirect：返回 302 临时重定向，地址栏会显示跳转后的 URL，对搜索引擎爬虫来说不会更新 URL（因为是临时重定向）。

permanent：返回 301 永久重定向，地址栏会显示跳转后的 URL，对搜索引擎爬虫来说会更新 URL（因为是永久重定向）。

last 和 break 在使用上区别：

last 和 break 当出现在 location 块之外时:

两者的作用是一致的没有任何差异, 他们会跳过所有的在他们之后的 rewrite 模块中的指令, 去选择自己匹配的location.不写last和break, 会优先执行rewrite部分, 然后才会去匹配 location 块. 

last 和 break 当出现在 location 块内部时

 break: url重写后, 直接使用当前资源, 终止当前location的rewrite检测, 而且不再进行location匹配, 完成本次请求, 地址栏url不变.  last:  url重写后, 马上发起一个新的请求, 再次进入server块, 重试location匹配, 超过10次匹配不到报500错误, 地址栏url不变.  不写last和break, 那么流程就是依次执行这些rewrite.

例子

如下 Nginx 配置，回答下面 3 个问题

1 当 1 这条 rewrite 规则生效后, 2,3,4 规则将会如何处理。

2 当 5 这个 rewrite 指令处理完成之后，将会如何处理请求。

3 第二个 location 中的 rewrite(6)指令处理完成之后，将会如何处理请求。

rewrite xxx1 yyy last; 1rewrite xxx2 yyy last; 2rewrite xxx3 yyy last; 3rewrite xxx4 yyy last; 4 location ~  url1{    rewrite url1 url2 last; 5 } location ~  url2{    rewrite url3 url4 break;  6    fastcgi_pass 127.0.0.1:9000}

当 1 这条 rewrite 规则生效后, 它后面的 2,3,4 将被跳过不做判断, 而去直接选择 后面的 location.

当 5 这个 rewrite 指令处理完成之后, 会跳出 location, 再重新判断 rewrite 1-4 的规则.

第二个 location 中的 rewrite(6)指令处理完成之后, 不会跳出 location, 更不会重新判断 rewrite 1 ~ 4 的规则. 而只能将信息传递给后面的 fastcgi_pass 或者 proxy_pass 等指令。

Nginx 请求匹配到下面的 localtion 会返回 404 吗

location /eoc {    rewrite ^ $request_uri;    rewrite ^/eoc/(.*)$ /$1 break;    rewrite ^/eoc break;     return 404;    proxy_pass http://127.0.0.1:18002$uri;     proxy_http_version 1.1;    add_header Cache-Control 'public, max-age=0';}

根据 Nginx 的请求处理过程，当执行了 return 指令时，后续的 rewrite 和 return 指令不会执行，而是将其扔给了 fastcgi_pass 或者是 proxy_pass 指令去处理，而不会执行"return 404;"。因此，配置中的"return 404;"不会被执行。