在新主機的遷移過(guò)程中,最大的困難就是WP permalink rewrite的設置.
因為舊主機是用的Apache, 使用的是WP本身就可以更改的.htaccess,沒(méi)有太大的難度.而這次在VPS上跑的是Nginx,主要是因為Nginx的速度比Apache要快很多.
但是另一方面就不是那么舒服了,因為Nginx的rewrite跟Apache不同,而且是在服務(wù)器上面才能更改.
下面是其間的一些研究筆記.(以下用例如無(wú)特別說(shuō)明均摘自nginx wiki)
/1 Nginx rewrite基本語(yǔ)法
Nginx的rewrite語(yǔ)法其實(shí)很簡(jiǎn)單.用到的指令無(wú)非是這幾個(gè)
- set
- if
- return
- break
- rewrite
麻雀雖小,可御可蘿五臟俱全.只是簡(jiǎn)單的幾個(gè)指令卻可以做出絕對不輸apache的簡(jiǎn)單靈活的配置.
1.set
set主要是用來(lái)設置變量用的,沒(méi)什么特別的
2.if
if主要用來(lái)判斷一些在rewrite語(yǔ)句中無(wú)法直接匹配的條件,比如檢測文件存在與否,http header,cookie等,
用法: if(條件) {…}
- 當if表達式中的條件為true,則執行if塊中的語(yǔ)句
- 當表達式只是一個(gè)變量時(shí),如果值為空或者任何以0開(kāi)頭的字符串都會(huì )當作false
- 直接比較內容時(shí),使用 = 和 !=
- 使用正則表達式匹配時(shí),使用
~ 大小寫(xiě)敏感匹配
~* 大小寫(xiě)不敏感匹配
!~ 大小寫(xiě)敏感不匹配
!~* 大小寫(xiě)不敏感不匹配
這幾句話(huà)看起來(lái)有點(diǎn)繞,總之記住: ~為正則匹配, 后置*為大小寫(xiě)不敏感, 前置!為”非”操作
隨便一提,因為nginx使用花括號{}判斷區塊,所以當正則中包含花括號時(shí),則必須用雙引號將正則包起來(lái).對下面講到的rewrite語(yǔ)句中的正則亦是如此.
比如 “\d{4}\d{2}\.+”
- 使用-f,-d,-e,-x檢測文件和目錄
-f 檢測文件存在
-d 檢測目錄存在
-e 檢測文件,目錄或者符號鏈接存在
-x 檢測文件可執行
跟~類(lèi)似,前置!則為”非”操作
舉例
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,則返回狀態(tài)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可用來(lái)直接設置HTTP返回狀態(tài),比如403,404等(301,302不可用return返回,這個(gè)下面會(huì )在rewrite提到)
4.break
立即停止rewrite檢測,跟下面講到的rewrite的break flag功能是一樣的,區別在于前者是一個(gè)語(yǔ)句,后者是rewrite語(yǔ)句的flag
5.rewrite
最核心的功能(廢話(huà))
用法: rewrite 正則 替換 標志位
其中標志位有四種
break – 停止rewrite檢測,也就是說(shuō)當含有break flag的rewrite語(yǔ)句被執行時(shí),該語(yǔ)句就是rewrite的最終結果
last – 停止rewrite檢測,但是跟break有本質(zhì)的不同,last的語(yǔ)句不一定是最終結果,這點(diǎn)后面會(huì )跟nginx的location匹配一起提到
redirect – 返回302臨時(shí)重定向,一般用于重定向到完整的URL(包含http:部分)
permanent – 返回301永久重定向,一般用于重定向到完整的URL(包含http:部分)
因為301和302不能簡(jiǎn)單的只單純返回狀態(tài)碼,還必須有重定向的URL,這就是return指令無(wú)法返回301,302的原因了. 作為替換,rewrite可以更靈活的使用redirect和permanent標志實(shí)現301和302. 比如上一篇日志中提到的Blog搬家要做的域名重定向,在nginx中就會(huì )這么寫(xiě)
rewrite ^(.*)$ http://newdomain.com/ permanent;
舉例來(lái)說(shuō)一下rewrite的實(shí)際應用
rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 last;
如果請求為 /download/eva/media/op1.mp3 則請求被rewrite到 /download/eva/mp3/op1.mp3
使用起來(lái)就是這樣,很簡(jiǎn)單不是么? 不過(guò)要注意的是rewrite有很多潛規則需要注意
- rewrite的生效區塊為sever, location, if
- rewrite只對相對路徑進(jìn)行匹配,不包含hostname 比如說(shuō)以上面301重定向的例子說(shuō)明
rewrite ~* cafeneko\.info http://newdomain.com/ permanent;
這句是永遠無(wú)法執行的,以這個(gè)URL為例
http://blog.cafeneko.info/2010/10/neokoseseiki_in_new_home/?utm_source=rss&utm_medium=rss&utm_campaign=neokoseseiki_in_new_home
其中cafeneko.info叫做hostname,再往后到?為止叫做相對路徑,?后面的一串叫做query string
對于rewrite來(lái)說(shuō),其正則表達式僅對”/2010/10/neokoseseiki_in_new_home”這一部分進(jìn)行匹配,即不包含hostname,也不包含query string .所以除非相對路徑中包含跟域名一樣的string,否則是不會(huì )匹配的. 如果非要做域名匹配的話(huà)就要使用if語(yǔ)句了,比如進(jìn)行去www跳轉
if ($host ~* ^www\.(cafeneko\.info)) { set $host_without_www $1; rewrite ^(.*)$ http://$host_without_www$1 permanent;}
- 使用相對路徑rewrite時(shí),會(huì )根據HTTP header中的HOST跟nginx的server_name匹配后進(jìn)行rewrite,如果HOST不匹配或者沒(méi)有HOST信息的話(huà)則rewrite到server_name設置的第一個(gè)域名,如果沒(méi)有設置server_name的話(huà),會(huì )使用本機的localhost進(jìn)行rewrite
- 前面提到過(guò),rewrite的正則是不匹配query string的,所以默認情況下,query string是自動(dòng)追加到rewrite后的地址上的,如果不想自動(dòng)追加query string,則在rewrite地址的末尾添加?
rewrite ^/users/(.*)$ /show?user=$1? last;
rewrite的基本知識就是這么多..但還沒(méi)有完..還有最頭疼的部分沒(méi)有說(shuō)…
/2 Nginx location 和 rewrite retry
nginx的rewrite有個(gè)很奇特的特性 — rewrite后的url會(huì )再次進(jìn)行rewrite檢查,最多重試10次,10次后還沒(méi)有終止的話(huà)就會(huì )返回HTTP 500
用過(guò)nginx的朋友都知道location區塊,location區塊有點(diǎn)像Apache中的RewriteBase,但對于nginx來(lái)說(shuō)location是控制的級別而已,里面的內容不僅僅是rewrite.
這里必須稍微先講一點(diǎn)location的知識.location是nginx用來(lái)處理對同一個(gè)server不同的請求地址使用獨立的配置的方式
舉例:
location = / { ....配置A} location / { ....配置B} location ^~ /images/ { ....配置C} location ~* \.(gif|jpg|jpeg)$ { ....配置D}
訪(fǎng)問(wèn) / 會(huì )使用配置A
訪(fǎng)問(wèn) /documents/document.html 會(huì )使用配置B
訪(fǎng)問(wèn) /images/1.gif 會(huì )使用配置C
訪(fǎng)問(wèn) /documents/1.jpg 會(huì )使用配置D
如何判斷命中哪個(gè)location暫且按下不婊, 我們在實(shí)戰篇再回頭來(lái)看這個(gè)問(wèn)題.
現在我們只需要明白一個(gè)情況: nginx可以有多個(gè)location并使用不同的配.
sever區塊中如果有包含rewrite規則,則會(huì )最先執行,而且只會(huì )執行一次, 然后再判斷命中哪個(gè)location的配置,再去執行該location中的rewrite, 當該location中的rewrite執行完畢時(shí),rewrite并不會(huì )停止,而是根據rewrite過(guò)的URL再次判斷location并執行其中的配置. 那么,這里就存在一個(gè)問(wèn)題,如果rewrite寫(xiě)的不正確的話(huà),是會(huì )在location區塊間造成無(wú)限循環(huán)的.所以nginx才會(huì )加一個(gè)最多重試10次的上限. 比如這個(gè)例子
location /download/ { rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 last;}
如果請求為 /download/eva/media/op1.mp3 則請求被rewrite到 /download/eva/mp3/op1.mp3
結果rewrite的結果重新命中了location /download/ 雖然這次并沒(méi)有命中rewrite規則的正則表達式,但因為缺少終止rewrite的標志,其仍會(huì )不停重試download中rewrite規則直到達到10次上限返回HTTP 500
認真的朋友這時(shí)就會(huì )問(wèn)了,上面的rewrite規則不是有標志位last么? last不是終止rewrite的意思么?
說(shuō)到這里我就要抱怨下了,網(wǎng)上能找到關(guān)于nginx rewrite的文章中80%對last標志的解釋都是
last – 基本上都用這個(gè)Flag
……這他媽坑爹呢!!! 什么叫基本上都用? 什么是不基本的情況? =皿=
有興趣的可以放狗”基本上都用這個(gè)Flag”…
我最終還是在stack overflow找到了答案:
last和break最大的不同在于
- break是終止當前l(fā)ocation的rewrite檢測,而且不再進(jìn)行location匹配
– last是終止當前l(fā)ocation的rewrite檢測,但會(huì )繼續重試location匹配并處理區塊中的rewrite規則
還是這個(gè)該死的例子
location /download/ { rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 ; rewrite ^(/download/.*)/movie/(.*)\..*$ $1/avi/$2.mp3 ; rewrite ^(/download/.*)/avvvv/(.*)\..*$ $1/rmvb/$2.mp3 ;}
上面沒(méi)有寫(xiě)標志位,請各位自行腦補…
如果請求為 /download/acg/moive/UBW.avi
last的情況是: 在第2行rewrite處終止,并重試location /download..死循環(huán)
break的情況是: 在第2行rewrite處終止,其結果為最終的rewrite地址.
也就是說(shuō),上面的某位試圖下載eva op不但沒(méi)下到反而被HTTP 500射了一臉的例子正是因為用了last標志所以才會(huì )造成死循環(huán),如果用break就沒(méi)事了.
location /download/ { rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 break;}
對于這個(gè)問(wèn)題,我個(gè)人的建議是,如果是全局性質(zhì)的rewrite,最好放在server區塊中并減少不必要的location區塊.location區塊中的rewrite要想清楚是用last還是break.
有人可能會(huì )問(wèn),用break不就萬(wàn)無(wú)一失了么?
不對.有些情況是要用last的. 典型的例子就是wordpress的permalink rewrite
常見(jiàn)的情況下, wordpress的rewrite是放在location /下面,并將請求rewrite到/index.php
這時(shí)如果這里使用break乃就掛了,不信試試. ｂ（￣▽?zhuān)洹驗閚ginx返回的是沒(méi)有解釋的index.php的源碼…
這里一定要使用last才可以在結束location / 的rewrite, 并再次命中location ~ \.php$,將其交給fastcgi進(jìn)行解釋.其后返回給瀏覽器的才是解釋過(guò)的html代碼.
關(guān)于nginx rewrite的簡(jiǎn)介到這里就全部講完了,水平及其有限,請大家指出錯漏…
/3 實(shí)戰! WordPress的Permalink+Supercache rewrite實(shí)現
這個(gè)rewrite寫(xiě)法其實(shí)是來(lái)自supercache作者本家的某個(gè)評論中,網(wǎng)上很容易查到,做了一些修改. 先給出該配置文件的全部?jì)热?.部分內容碼掉了..絕對路徑什么的你知道也沒(méi)啥用對吧?
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實(shí)現,nginx的實(shí)現簡(jiǎn)單的多. Apache mod_rewrite足足用了兩套看起來(lái)一模一樣的條件判斷來(lái)分別rewrite支持gzip壓縮和不支持的情況.
if (-f $request_filename) { break;}
//如果是直接請求某個(gè)真實(shí)存在的文件,則用break語(yǔ)句停止rewrite檢查
set $supercache_file '';set $supercache_uri $request_uri;
//用$request_uri初始化變量 $supercache_uri.
if ($request_method = POST) { set $supercache_uri '';}
//如果請求方式為POST,則不使用supercache.這里用清空$supercache_uri的方法來(lái)跳過(guò)檢測,下面會(huì )看到
if ($query_string) { set $supercache_uri '';}
//因為使用了rewrite的原因,正常情況下不應該有query_string(一般只有后臺才會(huì )出現query string),有的話(huà)則不使用supercache
if ($http_cookie ~* "comment_author_|wordpress_logged_|wp-postpass_" ) { set $supercache_uri '';}
//默認情況下,supercache是僅對unknown user使用的.其他諸如登錄用戶(hù)或者評論過(guò)的用戶(hù)則不使用.
comment_author是測試評論用戶(hù)的cookie, wordpress_logged是測試登錄用戶(hù)的cookie. wp-postpass不大清楚,字面上來(lái)看可能是曾經(jīng)發(fā)表過(guò)文章的?只要cookie中含有這些字符串則條件成立.
原來(lái)的寫(xiě)法中檢測登錄用戶(hù)cookie用的是wordpress_,但是我在測試中發(fā)現登入/登出以后還會(huì )有一個(gè)叫wordpress_test_cookie存在,不知道是什么作用,我也不清楚一般用戶(hù)是否會(huì )產(chǎn)生這個(gè)cookie.由于考慮到登出以后這個(gè)cookie依然存在可能會(huì )影響到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這串東西,其實(shí)寫(xiě)成 $http_host/$1/index.html 就好懂很多
以這個(gè)rewrite形式的url為例
cafeneko.info/2010/09/tsukihime-doujin_part01/
其中
$http_host = ‘cafeneko.info’ , $1 = $request_uri = ‘/2010/09/tsukihime-doujin_part01/’
則 $http_host$1index.html = ‘cafeneko.info/2010/09/tsukihime-doujin_part01/index.html’
而 $http_host/$1/index.html = ‘cafeneko.info//2010/09/tsukihime-doujin_part01//index.html’
雖然在調試過(guò)程中兩者并沒(méi)有不同,不過(guò)為了保持正確的路徑,還是省略了中間的/符號.
最后上例rewrite后的url = ‘cafeneko.info/wp-content/cache/supercache/cafeneko.info/2010/09/tsukihime-doujin_part01/index.html’
if (-f $document_root$supercache_file) { rewrite ^(.*)$ $supercache_file break;}
//檢查cache文件是否存在,存在的話(huà)則執行rewrite,留意這里因為是rewrite到html靜態(tài)文件,所以可以直接用break終止掉.
if (!-e $request_filename) { rewrite . /index.php last;}
//執行到此則說(shuō)明不使用suercache,進(jìn)行wordpress的permalink rewrite
檢查請求的文件/目錄是否存在,如果不存在則條件成立, rewrite到index.php
順便說(shuō)一句,當時(shí)這里這句rewrite看的我百思不得其解. .
只能匹配一個(gè)字符啊?這是什么意思?
一般情況下,想調試nginx rewrite最簡(jiǎn)單的方法就是把flag寫(xiě)成redirect,這樣就能在瀏覽器地址欄里看到真實(shí)的rewrite地址.
然而對于permalink rewrite卻不能用這種方法,因為一旦寫(xiě)成redirect以后,不管點(diǎn)什么鏈接,只要沒(méi)有supercache,都是跳轉回首頁(yè)了.
后來(lái)看了一些文章才明白了rewrite的本質(zhì),其實(shí)是在保持請求地址不變的情況下,在服務(wù)器端將請求轉到特定的頁(yè)面.
乍一看supercache的性質(zhì)有點(diǎn)像302到靜態(tài)文件,所以可以用redirect調試.
但是permalink卻是性質(zhì)完全不同的rewrite,這跟wordpress的處理方式有關(guān). 我研究不深就不多說(shuō)了,簡(jiǎn)單說(shuō)就是保持URL不變將請求rewrite到index.php,WP將分析其URL結構再對其并進(jìn)行匹配(文章,頁(yè)面,tag等),然后再構建頁(yè)面. 所以其實(shí)這條rewrite
rewrite . /index.php last;
說(shuō)的是,任何請求都會(huì )被rewrite到index.php.因為”.”匹配任意字符,所以這條rewrite其實(shí)可以寫(xiě)成任何形式的能任意命中的正則.比如說(shuō)
rewrite . /index.php last;rewrite ^ /index.php last;rewrite .* /index.php last;
效果都是一樣的,都能做到permalink rewrite.
最后要提的就是有人可能注意到我的rewrite規則是放在server塊中的.網(wǎng)上能找到的大多數關(guān)于wordpress的nginx rewrite規則都是放在location /下面的,但是上面我卻放在了server塊中,為何?
原因是WP或某個(gè)插件會(huì )在當前頁(yè)面做一個(gè)POST的XHR請求,本來(lái)沒(méi)什么特別,但問(wèn)題就出在其XHR請求的URL結構上.
正常的permalink一般為: domain.com/year/month/postname/ 或者 domain.com/tags/tagname/ 之類(lèi).
但這個(gè)XHR請求的URL卻是 domain.com/year/month/postname/index.php 或者 domain.com/tags/tagname/index.php
這樣一來(lái)就命中了location ~ \.php$而交給fastcgi,但因為根本沒(méi)有做過(guò)rewrite其頁(yè)面不可能存在,結果就是這個(gè)XHR返回一個(gè)404
鑒于location之間匹配優(yōu)先級的原因,我將主要的rewrite功能全部放進(jìn)了server區塊中,這樣就得以保證在進(jìn)行location匹配之前是一定做過(guò)rewrite的.
這時(shí)有朋友又要問(wèn)了,為什么命中的是location ~ \.php$而不是location / ?
…望天…長(cháng)嘆…這就要扯到天殺的location匹配問(wèn)題了….
locatoin并非像rewrite那樣逐條執行,而是有著(zhù)匹配優(yōu)先級的,當一條請求同時(shí)滿(mǎn)足幾個(gè)location的匹配時(shí),其只會(huì )選擇其一的配置執行.
其尋找的方法為:
1. 首先尋找所有的常量匹配,如location /, location /av/, 以相對路徑自左向右匹配,匹配長(cháng)度最高的會(huì )被使用,
2. 然后按照配置文件中出現的順序依次測試正則表達式,如 location ~ download\/$, location ~* \.wtf, 第一個(gè)匹配會(huì )被使用
3. 如果沒(méi)有匹配的正則,則使用之前的常量匹配
而下面幾種方法當匹配時(shí)會(huì )立即終止其他location的嘗試
1. = 完全匹配,location = /download/
2. ^~ 終止正則測試,如location ^~ /download/ 如果這條是最長(cháng)匹配,則終止正則測試,這個(gè)符號只能匹配常量
3. 在沒(méi)有=或者^(guò)~的情況下,如果常量完全匹配,也會(huì )立即終止測試,比如請求為 /download/ 會(huì )完全命中location /download/而不繼續其他的正則測試
總結:
1. 如果完全匹配(不管有沒(méi)有=),嘗試會(huì )立即終止
2. 以最長(cháng)匹配測試各個(gè)常量,如果常量匹配并有 ^~, 嘗試會(huì )終止
3. 按在配置文件中出現的順序測試各個(gè)正則表達式
4. 如果第3步有命中,則使用其匹配location,否則使用第2步的location
另外還可以定義一種特殊的named location,以@開(kāi)頭,如location @thisissparta 不過(guò)這種location定義不用于一般的處理,而是專(zhuān)門(mén)用于try_file, error_page的處理,這里不再深入.
暈了沒(méi)? 用前文的例子來(lái)看看
location = / { ....配置A} location / { ....配置B} location ^~ /images/ { ....配置C} location ~* \.(gif|jpg|jpeg)$ { ....配置D}
訪(fǎng)問(wèn) / 會(huì )使用配置A -> 完全命中
訪(fǎng)問(wèn) /documents/document.html 會(huì )使用配置B -> 匹配常量B,不匹配正則C和D,所以用B
訪(fǎng)問(wèn) /images/1.gif 會(huì )使用配置C -> 匹配常量B,匹配正則C,使用首個(gè)命中的正則,所以用C
訪(fǎng)問(wèn) /documents/1.jpg 會(huì )使用配置D -> 匹配常量B,不匹配正則C,匹配正則D,使用首個(gè)命中的正則,所以用D
那么再回頭看我們剛才說(shuō)的問(wèn)題.為什么那個(gè)URL結果奇怪的XHR請求會(huì )命中location ~ \.php$而不是location / ? 我相信你應該已經(jīng)知道答案了.
所以要解決這個(gè)問(wèn)題最簡(jiǎn)單的方法就是把rewrite規則放在比location先執行的server塊里面就可以了喲.
這次的研究筆記就到此為止了.
最后留一個(gè)思考題,如果不將rewrite規則放入server塊,還有什么方法可以解決這個(gè)XHR 404的問(wèn)題?
原來(lái)的location /塊包含從location ~ \.php$到root為止的部分.
答案是存在的.在用使用目前的方法前我死腦筋的在保留location /的前提下嘗試了很多種方法…請不要嘗試為各種permalink構建獨立的location.因為wp的permalink種類(lèi)很多,包括單篇文章,頁(yè)面,分類(lèi),tag,作者,存檔等等..歡迎在回復中討論 /
參考:
Nginx wiki
-EOF-
更新 @2010.10.23
之前的supercache rewrite規則適用于大部分的WP.但是并不適用于mobile press插件的移動(dòng)設備支持.
因為其中并沒(méi)有檢測移動(dòng)設備的user agent,從而導致移動(dòng)設備也會(huì )被rewrite到cache上.這樣的結果是在移動(dòng)設備上也是看到的跟PC一樣的完全版blog. 對于性能比較好的手機比如iphone安卓什么的大概沒(méi)什么問(wèn)題,但比較一般的比如nokia上用opera mini等看就會(huì )比較辛苦了,這次把supercache原本在htaccess中的移動(dòng)設備檢測的代碼塊也移植了過(guò)來(lái).
在前文的配置文件中cookie檢測后面加入以下代碼段
# Bypass special user agent if ($http_user_agent ~* "2.0 MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo Wii|Nitro|Nokia|Opera Mini|Palm|PlayStation Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915 Obigo|LGE VX|webOS|Nokia5800") { set $supercache_uri ''; } if ($http_user_agent ~* "w3c |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-") { set $supercache_uri ''; }
這樣就可以對移動(dòng)設備繞開(kāi)cache規則,而直接使用mobile press產(chǎn)生的移動(dòng)版的效果了.
