Nginx Rewrite基础教程

Nginx中rewrite规则是很多人头痛的问题，最近tennfy就被codeigniter在nginx中的伪静态问题折磨了挺长时间。因此，tennfy在这篇文章介绍下nginx rewrite基础教程。

Nginx rewrite基本语法

Nginx的rewrite语法其实很简单.主要用到如下指令

set
if
return
break
rewrite

下面来挨个介绍下这几个命令。

1.set

set主要是用来设置变量。

2.if

if主要用来判断一些在rewrite语句中无法直接匹配的条件,比如检测文件存在与否,http header,cookie等。

其用法为：

用法：if(条件) {…}
 
- 当if表达式中的条件为true,则执行if块中的语句
 
- 当表达式只是一个变量时,如果值为空或者任何以0开头的字符串都会当作false
 
- 直接比较内容时,使用 = 和 !=
 
- 使用正则表达式匹配时,使用
 
      ~ 大小写敏感匹配 
      ~* 大小写不敏感匹配 
      !~ 大小写敏感不匹配 
      !~* 大小写不敏感不匹配 
 
- 使用-f,-d,-e,-x检测文件和目录
 
      -f 检测文件存在
      -d 检测目录存在
      -e 检测文件,目录或者符号链接存在
      -x 检测文件可执行

举例分析一下：

if ($http_user_agent ~ MSIE) {
  rewrite  ^(.*)$  /msie/$1  break;
}

如果UA包含”MSIE”,rewrite 请求到/msie目录下

if ($http_cookie ~* "id=([^;] +)(?:;|$)" ) {
  set  $id  $1;
}

如果cookie匹配正则,设置变量$id等于正则引用部分

if ($request_method = POST ) {
  return 405;
}

如果提交方法为POST,则返回状态405 (Method not allowed)

if (!-f $request_filename) {
  break;
  proxy_pass  http://127.0.0.1;
}

如果请求文件名不存在,则反向代理localhost

if ($args ~ post=140){
  rewrite ^ http://example.com/ permanent;
}

如果query string中包含”post=140″,永久重定向到example.com

3.return

return可用来直接设置HTTP返回状态,比如403,404等(301,302不可用return返回,这个下面会在rewrite提到)。

4.break

立即停止rewrite检测,跟下面讲到的rewrite的break flag功能是一样的,区别在于前者是一个语句,后者是rewrite语句的flag

5.rewrite

这是最为重要的知识点

用法: rewrite 正则 替换 标志位
 
其中标志位有四种
 
break – 停止rewrite检测,也就是说当含有break flag的rewrite语句被执行时,该语句就是rewrite的最终结果
last – 停止rewrite检测,但是跟break有本质的不同,last的语句不一定是最终结果,这点后面会跟nginx的location匹配一起提到
redirect – 返回302临时重定向,一般用于重定向到完整的URL(包含http:部分)
permanent – 返回301永久重定向,一般用于重定向到完整的URL(包含http:部分)

因为301和302不能简单的只单纯返回状态码，还必须有重定向的URL，这就是return指令无法返回301，302的原因了。作为替换，rewrite可以更灵活的使用redirect和permanent标志实现301和302。

举例说明：

rewrite  ^(/download/.*)/media/(.*)\..*$  $1/mp3/$2.mp3  last;

如果请求为 /download/eva/media/op1.mp3，则请求被rewrite到 /download/eva/mp3/op1.mp3。

rewrite在使用中还有很多值得注意的地方：

rewrite的生效区块为sever, location, if
rewrite只对相对路径进行匹配,不包含hostname
使用相对路径rewrite时,会根据HTTP header中的HOST跟nginx的server_name匹配后进行rewrite,如果HOST不匹配或者没有HOST信息的话则rewrite到server_name设置的第一个域名,如果没有设置server_name的话,会使用本机的localhost进行rewrite
前面提到过,rewrite的正则是不匹配query string的,所以默认情况下,query string是自动追加到rewrite后的地址上的,如果不想自动追加query string,则在rewrite地址的末尾添加?
rewrite ^/users/(.*)$ /show?user=$1? last;

Nginx location 和 rewrite retry

nginx的rewrite有个很奇特的特性 — rewrite后的url会再次进行rewrite检查,最多重试10次,10次后还没有终止的话就会返回HTTP 500。

1、location基础

用过nginx的朋友都知道location区块,location区块有点像Apache中的RewriteBase,但对于nginx来说location是控制的级别而已,里面的内容不仅仅是rewrite。location是nginx用来处理对同一个server不同的请求地址使用独立的配置的方式。

举例说明：

location  = / {
  ....配置A
}
 
location  / {
  ....配置B
}
 
location ^~ /images/ {
  ....配置C
}
 
location ~* \.(gif|jpg|jpeg)$ {
  ....配置D
}

访问 / 会使用配置A
访问 /documents/document.html 会使用配置B
访问 /images/1.gif 会使用配置C
访问 /documents/1.jpg 会使用配置D

现在我们只需要明白一个情况: nginx可以有多个location并使用不同的配置。

2、location匹配命中规则

server区块中如果有包含rewrite规则,则会最先执行,而且只会执行一次, 然后再判断命中哪个location的配置,再去执行该location中的rewrite, 当该location中的rewrite执行完毕时,rewrite并不会停止,而是根据rewrite过的URL再次判断location并执行其中的配置。

location并非像rewrite那样逐条执行,而是有着匹配优先级的,当一条请求同时满足几个location的匹配时,其只会选择其一的配置执行.

其寻找的方法为:

1. 首先寻找所有的常量匹配,如location /, location /av/, 以相对路径自左向右匹配,匹配长度
   最高的会被使用

2. 然后按照配置文件中出现的顺序依次测试正则表达式,如 
   location ~ download\/$, location ~* \.wtf, 第一个匹配会被使用 

3. 如果没有匹配的正则,则使用之前的常量匹配

而下面几种方法当匹配时会立即终止其他location的尝试

1. = 完全匹配,location = /download/ 

2. ^~ 终止正则测试,如location ^~ /download/ 如果这条是最长匹配,则终止正则测试,这个符号
   只能匹配常量 

3. 在没有=或者^~的情况下,如果常量完全匹配,也会立即终止测试,比如请求为 /download/ 会完全
   命中
   location /download/而不继续其他的正则测试

总结:

1. 如果完全匹配(不管有没有=),尝试会立即终止

2. 以最长匹配测试各个常量,如果常量匹配并有 ^~, 尝试会终止
 
3. 按在配置文件中出现的顺序测试各个正则表达式 

4. 如果第3步有命中,则使用其匹配location,否则使用第2步的location

另外还可以定义一种特殊的named location,以@开头,如location @thisissparta 不过这种location定义不用于一般的处理,而是专门用于try_file, error_page的处理,这里不再深入.

举例说明：

location  = / {
  ....配置A
}
 
location  / {
  ....配置B
}
 
location ^~ /images/ {
  ....配置C
}
 
location ~* \.(gif|jpg|jpeg)$ {
  ....配置D
}

访问 / 会使用配置A -> 完全命中
访问 /documents/document.html 会使用配置B -> 匹配常量B,不匹配正则C和D,所以用B
访问 /images/1.gif 会使用配置C -> 匹配常量B,匹配正则C,使用首个命中的正则,所以用C
访问 /documents/1.jpg 会使用配置D -> 匹配常量B,不匹配正则C,匹配正则D,使用首个命中的正则,所以用D

3、rewrite retry

这里就存在一个问题,如果rewrite写的不正确的话,是会在location区块间造成无限循环的.所以nginx才会加一个最多重试10次的上限. 比如这个例子

location /download/ {
  rewrite  ^(/download/.*)/media/(.*)\..*$  $1/mp3/$2.mp3  last;
}

如果请求为 /download/eva/media/op1.mp3 则请求被rewrite到 /download/eva/mp3/op1.mp3

结果rewrite的结果重新命中了location /download/ 虽然这次并没有命中rewrite规则的正则表达式,但因为缺少终止rewrite的标志,其仍会不停重试download中rewrite规则直到达到10次上限返回HTTP 500。

这里需要介绍一下last标志位与break标志位的区别。

break是终止当前location的rewrite检测,而且不再进行location匹配
– last是终止当前location的rewrite检测,但会继续重试location匹配并处理区块中的rewrite规则

举例说明：

location /download/ {
  rewrite  ^(/download/.*)/media/(.*)\..*$  $1/mp3/$2.mp3  ;
  rewrite  ^(/download/.*)/movie/(.*)\..*$  $1/avi/$2.mp3  ;
  rewrite  ^(/download/.*)/avvvv/(.*)\..*$  $1/rmvb/$2.mp3 ;
}

如果请求为 /download/acg/moive/UBW.avi

last的情况是: 在第2行rewrite处终止,并重试location /download..死循环
break的情况是: 在第2行rewrite处终止,其结果为最终的rewrite地址。

虽然如此，但是很多情况下还是需要使用last。典型的例子就是wordpress的permalink rewrite。

常见的情况下, wordpress的rewrite是放在location /下面,并将请求rewrite到/index.php

这时如果这里使用break就会出现问题，因为nginx返回的是没有解释的index.php的源码。

这里一定要使用last才可以在结束location / 的rewrite, 并再次命中location ~ .php$,将其交给fastcgi进行解释.其后返回给浏览器的才是解释过的html代码。

WordPress的Permalink+Supercache rewrite实现

这个rewrite写法其实是来自supercache作者本家的某个评论中,网上很容易查到,做了一些修改. 先给出该配置文件的全部内容..部分内容码掉了..绝对路径什么的你知道也没啥用对吧?

server {
    listen   80;
    server_name  cafeneko.info www.cafeneko.info;
 
    access_log  ***;
    error_log   *** ;
 
    root   ***;
    index  index.php;
 
    gzip_static on;
 
    if (-f $request_filename) {
        break;
    }
 
    set $supercache_file '';
    set $supercache_uri $request_uri;
 
    if ($request_method = POST) {
        set $supercache_uri '';
    }
 
    if ($query_string) {
        set $supercache_uri '';
    }
 
    if ($http_cookie ~* "comment_author_|wordpress_logged_|wp-postpass_" ) {
        set $supercache_uri '';
    }
 
    if ($supercache_uri ~ ^(.+)$) {
        set $supercache_file /wp-content/cache/supercache/$http_host/$1index.html;
    }
 
    if (-f $document_root$supercache_file) {
        rewrite ^(.*)$ $supercache_file break;
    }
 
    if (!-e $request_filename) {
        rewrite . /index.php last;
    }
 
    location ~ \.php$ {
 
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  ***$fastcgi_script_name;
        include        fastcgi_params;
    }
 
    location ~ /\.ht {
        deny  all;
    }
}

下面是解释:

gzip_static on;

如果浏览器支持gzip,则在压缩前先寻找是否存在压缩好的同名gz文件避免再次压缩浪费资源,配合supercache的压缩功能一起使用效果最好,相比supercache原生的Apache mod_rewrite实现,nginx的实现简单的多. Apache mod_rewrite足足用了两套看起来一模一样的条件判断来分别rewrite支持gzip压缩和不支持的情况.

if (-f $request_filename) {
    break;
}

如果是直接请求某个真实存在的文件,则用break语句停止rewrite检查

set $supercache_file '';
set $supercache_uri $request_uri;

用$request_uri初始化变量 $supercache_uri.

if ($request_method = POST) {
    set $supercache_uri '';
}

如果请求方式为POST,则不使用supercache.这里用清空$supercache_uri的方法来跳过检测,下面会看到

if ($query_string) {
    set $supercache_uri '';
}

因为使用了rewrite的原因,正常情况下不应该有query_string(一般只有后台才会出现query string),有的话则不使用supercache

if ($http_cookie ~* "comment_author_|wordpress_logged_|wp-postpass_" ) {
    set $supercache_uri '';
}

默认情况下,supercache是仅对unknown user使用的.其他诸如登录用户或者评论过的用户则不使用.

comment_author是测试评论用户的cookie, wordpress_logged是测试登录用户的cookie. wp-postpass不大清楚,字面上来看可能是曾经发表过文章的?只要cookie中含有这些字符串则条件成立.

原来的写法中检测登录用户cookie用的是wordpress_,但是我在测试中发现登入/登出以后还会有一个叫wordpress_test_cookie存在,不知道是什么作用,我也不清楚一般用户是否会产生这个cookie.由于考虑到登出以后这个cookie依然存在可能会影响到cache的判断,于是把这里改成了匹配wordpress_logged_

if ($supercache_uri ~ ^(.+)$) {
    set $supercache_file /wp-content/cache/supercache/$http_host$1index.html;
}

如果变量$supercache_uri不为空,则设置cache file的路径

这里稍微留意下$http_host$1index.html这串东西,其实写成 $http_host/$1/index.html 就好懂很多

以这个rewrite形式的url为例

domain.com/year/month/postname/

其中

$http_host = ‘domain.com’ , $1 = $request_uri = ‘/year/month/postname/’

则

$http_host$1index.html = ‘domain.com/year/month/postname/index.html’

而

$http_host/$1/index.html = ‘domain.com//year/month/postname//index.html’

虽然在调试过程中两者并没有不同,不过为了保持正确的路径,还是省略了中间的/符号.

最后上例rewrite后的url为

‘domain.com/wp-content/cache/supercache/domain.com/year/month/postname/index.html’

if (-f $document_root$supercache_file) {
    rewrite ^(.*)$ $supercache_file break;
}

检查cache文件是否存在,存在的话则执行rewrite,留意这里因为是rewrite到html静态文件,所以可以直接用break终止掉.

if (!-e $request_filename) {
    rewrite . /index.php last;
}

执行到此则说明不使用suercache,进行wordpress的permalink rewrite

检查请求的文件/目录是否存在,如果不存在则条件成立, rewrite到index.php

顺便说一句,当时这里这句rewrite看的我百思不得其解. .

只能匹配一个字符啊?这是什么意思?

一般情况下,想调试nginx rewrite最简单的方法就是把flag写成redirect,这样就能在浏览器地址栏里看到真实的rewrite地址.

然而对于permalink rewrite却不能用这种方法,因为一旦写成redirect以后,不管点什么链接,只要没有supercache,都是跳转回首页了.

后来看了一些文章才明白了rewrite的本质,其实是在保持请求地址不变的情况下,在服务器端将请求转到特定的页面.

乍一看supercache的性质有点像302到静态文件,所以可以用redirect调试.

但是permalink却是性质完全不同的rewrite,这跟wordpress的处理方式有关. 我研究不深就不多说了,简单说就是保持URL不变将请求rewrite到index.php,WP将分析其URL结构再对其并进行匹配(文章,页面,tag等),然后再构建页面. 所以其实这条rewrite。

rewrite . /index.php last;

说的是,任何请求都会被rewrite到index.php.因为”.”匹配任意字符,所以这条rewrite其实可以写成任何形式的能任意命中的正则.比如说

rewrite . /index.php last;
rewrite ^ /index.php last;
rewrite .* /index.php last;

效果都是一样的,都能做到permalink rewrite.

最后要提的就是有人可能注意到我的rewrite规则是放在server块中的.网上能找到的大多数关于wordpress的nginx rewrite规则都是放在location /下面的,但是上面我却放在了server块中,为何?

原因是WP或某个插件会在当前页面做一个POST的XHR请求,本来没什么特别,但问题就出在其XHR请求的URL结构上.

正常的permalink一般为: domain.com/year/month/postname/ 或者 domain.com/tags/tagname/ 之类.

但这个XHR请求的URL却是 domain.com/year/month/postname/index.php 或者 domain.com/tags/tagname/index.php

这样一来就命中了location ~ .php$而交给fastcgi,但因为根本没有做过rewrite其页面不可能存在,结果就是这个XHR返回一个404

鉴于location之间匹配优先级的原因,将主要的rewrite功能全部放进了server区块中,这样就得以保证在进行location匹配之前是一定做过rewrite的.

所以要解决这个问题最简单的方法就是把rewrite规则放在比location先执行的server块里面就可以了。

参考文章：Nginx Rewrite研究笔记

标签：nginx

1.set

2.if

3.return

4.break

5.rewrite

Nginx location 和 rewrite retry

1、location基础

2、location匹配命中规则

3、rewrite retry

WordPress的Permalink+Supercache rewrite实现

你的评论