nginx location匹配规则

2016-07-30 10:52:15来源:oschina作者:大陆大陆人点击

一些对location认识的误区

1、location的匹配顺序是“先匹配正则,再匹配普通”。


矫正:location的匹配顺序其实是“先匹配普通,再匹配正则”。我这么说,大家一定会反驳我,因为按“先匹配普通,再匹配正则”解释不了 大家平时习惯的按“先匹配正则,再匹配普通”的实践经验。这里我只能暂时解释下,造成这种误解的原因是:正则匹配会覆盖普通匹配(实际的规则,比这复杂, 后面会详细解释)。

2、location的执行逻辑跟location的编辑顺序无关。


矫正:这句话不全对,“普通location”的匹配规则是“最大前缀”,因此“普通location”的确与location编辑顺 序无关;但是“正则location”的匹配规则是“顺序匹配,且只要匹配到第一个就停止后面的匹配”;“普通location”与“正 则location”之间的匹配顺序是?先匹配普通location,再“考虑”匹配正则location。注意这里的“考虑”是“可能”的 意思,也就是说匹配完“普通location”后,有的时候需要继续匹配“正则location”,有的时候则不需要继续匹配“正 则location”。两种情况下,不需要继续匹配正则location:(1)当普通location前面指定了“^~”,特别告 诉Nginx本条普通location一旦匹配上,则不需要继续正则匹配;(2)当普通location恰好严格匹配上,不是最大前缀匹 配,则不再继续匹配正则。


总结一句话: “正则 location 匹配让步普通 location 的严格精确匹配结果;但覆盖普通 location 的最大前缀匹配结果”

官方文档解释

REFER:http://wiki.nginx.org/NginxHttpCoreModule#location

location


syntax:location [=|~|~*|^~|@] /uri/ { … }


default:no


context:server


This directive allows different configurations depending on the URI.


(译者注:1、different configurations depending on the URI说的就是语法格式:location [=|~|~*|^~|@] /uri/ { … },依据不同的前缀“=”,“^~”,“~”,“~*”和不带任何前缀的(因为[A]表示可选,可以不要的),表达不同的含义,简单的说尽 管location的/uri/配置一样,但前缀不一样,表达的是不同的指令含义。2、查询字符串不在URI范围内。例如: /films.htm?fid=123的URI是/films.htm。)


It can be configured using both literal strings and regular expressions. To use regular expressions, you must use a prefix:

“~” for case sensitive matching


“~*” for case insensitive matching

译文:上文讲到location /uri/可通过使用不同的前缀,表达不同的含义。对这些不同前缀,分下类,就2大类:正则location,英文说法是location using regular expressions和普通location,英文说法是location using literal strings。那么其中“~”和“~*”前缀表示正则location,“~”区分大小写,“~*”不区分大小写;其他前缀(包 括:“=”,“^~”和“@”)和无任何前缀的都属于普通location。


To determine whichlocationdirective matches a particular query, the literal strings are checked first.


译文:对于一个特定的HTTP请求(a particular query),nginx应该匹配哪个location块的指令呢(注意:我们在nginx.conf配置文件里面一般会定义多 个location的)?匹配规则是:先匹配普通location(再匹配正则表达式)。注意:官方文档这句话就明确说了,先普通 location,而不是有些同学的误区“先匹配正则location”。


Literal strings match the beginning portion of the query – the most specific match will be used.


前面说了“普通location”与“正则location”之间的匹配规则是:先匹配普通location,再匹配正则 location。那么,“普通location”内部(普通location与普通location)是如何匹配的呢?简单的说:最大前缀匹 配。原文:1、match the beginning portion of the query(说的是匹配URI的前缀部分beginning portion);2、the most specific match will be used(因为location不是“严格匹配”,而是“前缀匹配”,就会产生一个HTTP请求,可以“前缀匹配”到多个普通location, 例如:location /prefix/mid/ {}和location /prefix/ {},对于HTTP请求/prefix/mid/t.html,前缀匹配的话两个location都满足,选哪个?原则是:the most specific match,于是选的是location /prefix/mid/ {})。


Afterwards, regular expressions are checked in the order defined in the configuration file.The first regular expression to match the query will stop the search.


这段话说了两层意思,第一层是:“Afterwards, regular expressions are checked”,意思是普通location先匹配,而且选择了最大前缀匹配后,不能就停止后面的匹配,最大前缀匹配只是一个临时的结 果,nginx还需要继续检查正则location(但至于最终才能普通location的最大前缀匹配,还是正则location的匹配,截止 当前的内容还没讲,但后面会讲)。第二层是“regular expressions are checked in the order defined in the configuration file. The first regular expression to match the query will stop the search.”,意思是说“正则location”与“正则location”内部的匹配规则是:按照正则location在配置文件中的物理顺 序(编辑顺序)匹配的(这句话就说明location并不是一定跟顺序无关,只是普通location与顺序无关,正则location还是与顺序 有关的),并且只要匹配到一条正则location,就不再考虑后面的(这与“普通location”与“正则location”之间的规则不一 样,“普通location”与“正则location”之间的规则是:选择出“普通location”的最大前缀匹配结果后,还需要继续搜索正则 location)。


If no regular expression matches are found, the result from the literal string search is used.


这句话回答了“普通location”的最大前缀匹配结果与继续搜索的“正则location”匹配结果的决策关系。如果继续搜索的“正则location”也有匹配上的,那么“正则location”覆盖“普通location”的最大前缀匹配(因为有这个覆盖关系,所以造成有些同学以为正则location先于普通location执行的错误理解);但是如果“正则location”没有能匹配上,那么就用“普通location”的最大前缀匹配结果。


For case insensitive operating systems, like Mac OS X or Windows with Cygwin, literal string matching is done in a case insensitive way (0.7.7). However, comparison is limited to single-byte locale’s only.


Regular expression may contain captures (0.7.40), which can then be used in other directives.


It is possible to disable regular expression checks after literal string matching by using “^~” prefix.If the most specific match literal location has this prefix: regular expressions aren’t checked.


通常的规则是,匹配完了“普通location”指令,还需要继续匹配“正则location”,但是你也可以告诉Nginx:匹配到了“普 通location”后,不再需要继续匹配“正则location”了,要做到这一点只要在“普通location”前面加上“^~”符号 (^表示“非”,~表示“正则”,字符意思是:不要继续匹配正则)。


By using the “=” prefix we define theexactmatch between request URI and location. When matched search stops immediately.E.g., if the request “/” occurs frequently, using “location = /” will speed up processing of this request a bit as search will stop after first comparison.


除了上文的“^~”可以阻止继续搜索正则location外,你还可以加“=”。那么如果“^~”和“=”都能阻止继续搜索正则 location的话,那它们之间有什么区别呢?区别很简单,共同点是它们都能阻止继续搜索正则location,不同点是“^~”依然遵守“最大 前缀”匹配规则,然而“=”不是“最大前缀”,而是必须是严格匹配(exact match)。


这里顺便讲下“location / {}”和“location = / {}”的区别,“location / {}”遵守普通location的最大前缀匹配,由于任何URI都必然以“/”根开头,所以对于一个URI,如果有更specific的匹 配,那自然是选这个更specific的,如果没有,“/”一定能为这个URI垫背(至少能匹配到“/”),也就是说“location / {}”有点默认配置的味道,其他更specific的配置能覆盖overwrite这个默认配置(这也是为什么我们总能看到location / {}这个配置的一个很重要的原因)。而“location = / {}”遵守的是“严格精确匹配exact match”,也就是只能匹配http://host:port/请 求,同时会禁止继续搜索正则location。因此如果我们只想对“GET /”请求配置作用指令,那么我们可以选“location = / {}”这样能减少正则location的搜索,因此效率比“location / {}”高(注:前提是我们的目的仅仅只想对“GET /”起作用)。


On exact match with literal location without “=” or “^~” prefixessearch is also immediately terminated.


前面我们说了,普通location匹配完后,还会继续匹配正则location;但是nginx允许你阻止这种行为,方法很简单,只需要在 普通location前加“^~”或“=”。但其实还有一种“隐含”的方式来阻止正则location的搜索,这种隐含的方式就是:当“最大前 缀”匹配恰好就是一个“严格精确(exact match)”匹配,照样会停止后面的搜索。原文字面意思是:只要遇到“精确匹配exact match”,即使普通location没有带“=”或“^~”前缀,也一样会终止后面的匹配。


先举例解释下,后面例题会用实践告诉大家。假设当前配置是:location /exact/match/test.html {配置指令块1},location /prefix/ {配置指令块2}和location ~ /.html$ {配置指令块3},如果我们请求GET /prefix/index.html,则会被匹配到指令块3,因为普通location /prefix/依据最大匹配原则能匹配当前请求,但是会被后面的正则location覆盖;当请求GET /exact/match/test.html,会匹配到指令块1,因为这个是普通location的exact match,会禁止继续搜索正则location。


To summarize, the order in which directives are checked is as follows:

Directives with the “=” prefix that match the query exactly. If found, searching stops.


All remaining directives with conventional strings. If this match used the “^~” prefix, searching stops.


Regular expressions, in the order they are defined in the configuration file.


If #3 yielded a match, that result is used. Otherwise, the match from #2 is used.

这个顺序没必要再过多解释了。但我想用自己的话概括下上面的意思“正则location匹配让步普通location的严格精确匹配结果;但覆盖普通location的最大前缀匹配结果”。


It is important to know that nginx does the comparison againstdecodedURIs. For example, if you wish to match “/images/ /test”, then you must use “/images/ /test” to determine the location.


在浏览器上显示的URL一般都会进行URLEncode,例如“空格”会被编码为 ,但是Nginx的URL的匹配都是针对URLDecode之后的。也就是说,如果你要匹配“/images/ /test”,你写location的时候匹配目标应该是:“/images/ /test”。


Example:


location= / {


# matches the query / only.


[ configuration A ]


}


location/ {


# matches any query, since all queries begin with /, but regular


# expressions and any longer conventional blocks will be


# matched first.


[ configuration B ]


}


location^~ /images/ {


# matches any query beginning with /images/ and halts searching,


# so regular expressions will not be checked.


[ configuration C ]


}


location~* /.(gif|jpg|jpeg)$ {


# matches any request ending in gif, jpg, or jpeg. However, all


# requests to the /images/ directory will be handled by


# Configuration C.


[ configuration D ]


}

上述这4个location的配置,没什么好解释的,唯一需要说明的是location / {[configuration B]},原文的注释严格来说是错误的,但我相信原文作者是了解规则的,只是文字描述上简化了下,但这个简化容易给读者造成“误解:先检查正则 location,再检查普通location”。原文:“matches any query, since all queries begin with /,butregular expressionsand any longer conventional blockswill be matched first.”大意是说:“location / {}能够匹配所有HTTP请求,因为任何HTTP请求都必然是以‘/’开始的(这半句没有错误)。但是,正则location和其他任何比‘/’更长的普通location(location / {}是普通location里面最短的,因此其他任何普通location都会比它更长,当然location = / {}和location ^~ / {}是一样长的)会优先匹配(matched first)。”原 文作者说“but regular expressions will be matched first.”应该只是想说正则location会覆盖这里的location / {},但依然是普通location / {}先于正则location匹配,接着再正则location匹配;但其他更长的普通location(any longer conventional blocks)的确会先于location / {}匹配。

Example requests:

/ -> configuration A


/documents/document.html -> configuration B


/images/1.gif -> configuration C


/documents/1.jpg -> configuration D

Note that you could define these 4 configurations in any order and the results would remain the same.


需要提醒下:这里说“in any order”和“… remain the same”是因为上面只有一个正则location。文章前面已经说了正则location的匹配是跟编辑顺序有关系的。


While nested locations are allowed by the configuration file parser, their use is discouraged and may produce unexpected results.


实际上nginx的配置文件解析程序是允许location嵌套定义的(location / { location /uri/ {} })。但是我们平时却很少看见这样的配置,那是因为nginx官方并不建议大家这么做,因为这样会导致很多意想不到的后果。


The prefix “@” specifies a named location. Such locations are not used during normal processing of requests, they are intended only to process internally redirected requests (seeerror_page,try_files).


文章开始说了location的语法中,可以有“=”,“^~”,“~”和“~*”前缀,或者干脆没有任何前缀,还有“@”前缀,但是 后面的分析我们始终没有谈到“@”前缀。文章最后点内容,介绍了“@”的用途:“@”是用来定义“Named Location”的(你可以理解为独立于“普通location(location using literal strings)”和“正则location(location using regular expressions)”之外的第三种类型),这种“Named Location”不是用来处理普通的HTTP请求的,它是专门用来处理“内部重定向(internally redirected)”请求的。注意:这里说的“内部重定向(internally redirected)”或许说成“forward”会好点,以为内internally redirected是不需要跟浏览器交互的,纯粹是服务端的一个转发行为。

安装Nginx

wgethttp://nginx.org/download/nginx-1.4.6.tar.gz


tar zxvf nginx-1.1.0.tar.gz


./configure


make


make install


需要注意的是在configure这步遇到点小麻烦:


./configure: error: the HTTP rewrite module requires the PCRE library.


安装nginx的时候,rewrite模块默认是需要被安装的。但是rewrite模块所依赖的PCRE库需要额外安装。


You can either disable the module by using –without-http_rewrite_module


option, or install the PCRE library into the system, or build the PCRE library


statically from the source with nginx by using –with-pcre= option.

解决办法:http://apps.hi.baidu.com/share/detail/34331473


先执行:yum -y install pcre-devel openssl openssl-devel把依赖的东西安装上。


备注:PCRE(Perl Compatible Regular Expressions)是perl语言正则表达式。 Nginx的rewrite的正则表达式采用的是Perl语法集(常识:正则表达式有不同的语法集,我们常见的grep指令如果需要采用Perl语法集,需要grep -P 来指定)。

location实例练习


Nginx的语法形式是:location [=|~|~*|^~|@] /uri/ { … },意思是可以以“=”或“~*”或“~”或“^~”或“@”符号为前缀,当然也可以没有前缀(因为[A]是表示可选 的A;A|B表示A和B选一个),紧接着是/uri/,再接着是{…}指令块,整个意思是对于满足这样条件的/uri/适用指 令块{…}的指令。


上述各种location可分两大类,分别是:“普通location”,官方英文说法是location usingliteral strings和“正则location”,英文说法是location usingregular expressions。其中“普通location”是以“=”或“^~”为前缀或者没有任何前缀的/uri/;“正则location”是以“~”或“~*”为前缀的/uri/。


那么,当我们在一个server上下文编写了多个location的时候,Nginx对于一个HTTP请求,是如何匹配到一个location做处理呢?用一句话简单概括Nginx的location匹配规则是:“正则location”让步“普通location”的严格精确匹配结果;但覆盖“普通location”的最大前缀匹配结果。理解这句话,我想通过下面的实例来说明。


#1先普通location,再正则location

周边不少童鞋告诉我,nginx是“先匹配正则location再匹配普通location”,其实这是一个误区,nginx其实 是“先匹配普通location,再匹配正则location”,但是普通location的匹配结果又分两种:一种是“严格精确匹配”,官 方英文说法是“exact match”;另一种是“最大前缀匹配”,官方英文说法是“Literal strings match the beginning portion of the query – the most specific match will be used.”。我们做个实验:

例题1:假设nginx的配置如下


server {


listen9090;


server_namelocalhost;


location / {


roothtml;


indexindex.html index.htm;


deny all;


}


location ~ /.html$ {


allow all;


}


}


附录nginx的目录结构是:nginx->html->index.html


上述配置的意思是:location / {… deny all;}普通location以“/”开始的URI请求(注意任何HTTP请求都必然以“/”开始,所以“/”的意思是所有的 请求都能被匹配上),都拒绝访问;location ~/.html$ {allow all;}正则location以.html结尾的URI请求,都允许访问。

测试结果:


[root@web108 ~]#curl http://localhost:9090/



403 Forbidden



403 Forbidden



nginx/1.1.0




[root@web108 ~]#curl http://localhost:9090/index.html




Welcome to nginx!




Welcome to nginx!




[root@web108 ~]#curl http://localhost:9090/index_notfound.html



404 Not Found



404 Not Found



nginx/1.1.0




[root@web108 ~]#

测试结果如下:



URI请求
HTTP响应


curl http://localhost:9090/
403 Forbidden


curl http://localhost:9090/index.html
Welcome to nginx!


curl http://localhost:9090/index_notfound.html
404 Not Found


curlhttp://localhost:9090/的结果是“403 Forbidden”,说明被匹配到“location / {..deny all;}”了,原因很简单HTTP请求GET /被“严格精确”匹配到了普通location / {},则会停止搜索正则location;


curlhttp://localhost:9090/index.html结 果是“Welcome to nginx!”,说明没有被“location / {…deny all;}”匹配,否则会403 Forbidden,但/index.html的确也是以“/”开头的,只不过此时的普通location /的匹配结果是“最大前缀”匹配,所以Nginx会继续搜索正则location,location ~ /.html$表达了以.html结尾的都allow all;于是接着就访问到了实际存在的index.html页面。


curlhttp://localhost:9090/index_notfound.html同 样的道理先匹配location / {},但属于“普通location的最大前缀匹配”,于是后面被“正则location”location ~ /.html$ {}覆盖了,最终allow all;但的确目录下不存在index_notfound.html页面,于是404 Not Found。

如果此时我们访问http://localhost:9090/index.txt会 是什么结果呢?显然是deny all;因为先匹配上了location / {..deny all;}尽管属于“普通location”的最大前缀匹配结果,继续搜索正则location,但是/index.txt不是 以.html结尾的,正则location失败,最终采纳普通location的最大前缀匹配结果,于是deny all了。


[root@web108 ~]#curl http://localhost:9090/index.txt



403 Forbidden



403 Forbidden



nginx/1.1.0




[root@web108 ~]#


#2普通location的“隐式”严格匹配

例题2:我们在例题1的基础上增加精确配置

server {


listen9090;


server_namelocalhost;


location /exact/match.html {


allow all;


}


location / {


roothtml;


indexindex.html index.htm;


deny all;


}


location ~ /.html$ {


allow all;


}


}

测试请求:


[root@web108 ~]#curl http://localhost:9090/exact/match.html



404 Not Found



404 Not Found



nginx/1.1.0




[root@web108 ~]#

结果进一步验证了“普通location”的“严格精确”匹配会终止对正则location的搜索。这里我们小结下“普 通location”与“正则location”的匹配规则:先匹配普通location,再匹配正则location,但是如果普 通location的匹配结果恰好是“严格精确(exact match)”的,则nginx不再尝试后面的正则location;如果普通location的匹配结果是“最大前缀”,则正 则location的匹配覆盖普通location的匹配。也就是前面说的“正则location让步普通location的严格精确匹配 结果,但覆盖普通location的最大前缀匹配结果”。


#3普通location的“显式”严格匹配和“^~”前缀

上面我们演示的普通location都是不加任何前缀的,其实普通location也可以加前缀:“^~”和“=”。其中 “^~”的意思是“非正则,不需要继续正则匹配”,也就是通常我们的普通location,还会继续搜索正则location(恰好严格精确匹 配除外),但是nginx很人性化允许配置人员告诉nginx某条普通location,无论最大前缀匹配,还是严格精确匹配都终止继续搜索 正则location;而“=”则表达的是普通location不允许“最大前缀”匹配结果,必须严格等于,严格精确匹配。

例题3:“^~”前缀的使用


server {


listen9090;


server_namelocalhost;


location /exact/match.html {


allow all;


}


location ^~ / {


roothtml;


indexindex.html index.htm;


deny all;


}


location ~ /.html$ {


allow all;


}


}

把例题2中的location / {}修改成location ^~ / {},再看看测试结果:



URI请求
修改前
修改后


curl http://localhost:9090/
403 Forbidden
403 Forbidden


curl http://localhost:9090/index.html
Welcome to nginx!
403 Forbidden


curl http://localhost:9090/index_notfound.html
404 Not Found
403 Forbidden


curl http://localhost:9090/exact/match.html
404 Not Found
404 Not Found


除了GET /exact/match.html是404 Not Found,其余都是403 Forbidden,原因很简单所有请求都是以“/”开头,所以所有请求都能匹配上“/”普通location,但普 通location的匹配原则是“最大前缀”,所以只有/exact/match.html匹配到location /exact/match.html {allow all;},其余都location ^~ / {deny all;}并终止正则搜索。

例题4:“=”前缀的使用


server {


listen9090;


server_namelocalhost;


location /exact/match.html {


allow all;


}


location = / {


roothtml;


indexindex.html index.htm;


deny all;


}


location ~ /.html$ {


allow all;


}


}


例题4相对例题2把location / {}修改成了location = / {},再次测试结果:



URI请求
修改前
修改后


curl http://localhost:9090/
403 Forbidden
403 Forbidden


curl http://localhost:9090/index.html
Welcome to nginx!
Welcome to nginx!


curl http://localhost:9090/index_notfound.html
404 Not Found
404 Not Found


curl http://localhost:9090/exact/match.html
404 Not Found
404 Not Found


curl http://localhost:9090/test.jsp
403 Forbidden
404 Not Found


最能说明问题的测试是GET /test.jsp,实际上/test.jsp没有匹配正则location(location ~/.html$),也没有匹配location = / {},如果按照location / {}的话,会“最大前缀”匹配到普通location / {},结果是deny all。


#4正则location与编辑顺序

location的指令与编辑顺序无关,这句话不全对。对于普通location指令,匹配规则是:最大前缀匹配(与顺序无关),如果恰好是 严格精确匹配结果或者加有前缀“^~”或“=”(符号“=”只能严格匹配,不能前缀匹配),则停止搜索正则location;但对于正 则location的匹配规则是:按编辑顺序逐个匹配(与顺序有关),只要匹配上,就立即停止后面的搜索。

配置3.1


server {


listen9090;


server_namelocalhost;

location ~ /.html$ {


allow all;


}

location ~ ^/prefix/.*/.html$ {


deny all;


}

}


配置3.2


server {


listen9090;


server_namelocalhost;


location ~ ^/prefix/.*/.html$ {


deny all;


}

location ~ /.html$ {


allow all;


}

}

测试结果:



URI请求
配置3.1
配置3.2


curl http://localhost:9090/regextest.html
404 Not Found
404 Not Found


curl http://localhost:9090/prefix/regextest.html
404 Not Found
403 Forbidden


解释:


Location ~ ^/prefix/.*/.html$ {deny all;}表示正则location对于以/prefix/开头,.html结尾的所有URI请求,都拒绝访 问;location ~/.html${allow all;}表示正则location对于以.html结尾的URI请求,都允许访问。实际上,prefix的是~/.html$的 子集。


在“配置3.1”下,两个请求都匹配上location ~/.html$ {allow all;},并且停止后面的搜索,于是都允许访问,404 Not Found;在“配置3.2”下,/regextest.html无法匹配prefix,于是继续搜索~/.html$,允许访问,于 是404 Not Found;然而/prefix/regextest.html匹配到prefix,于是deny all,403 Forbidden。

配置3.3


server {


listen9090;


server_namelocalhost;

location/prefix/ {


deny all;


}

location/prefix/mid/ {


allow all;


}

}


配置3.4


server {


listen9090;


server_namelocalhost;


location/prefix/mid/ {


allow all;


}


location/prefix/ {


deny all;


}


}


测试结果:



URI请求
配置3.1
配置3.2


curl http://localhost:9090/prefix/t.html
403 Forbidden
403 Forbidden


curl http://localhost:9090/prefix/mid/t.html
404 Not Found
404 Not Found


测试结果表明:普通location的匹配规则是“最大前缀”匹配,而且与编辑顺序无关。

#5 “@”前缀Named Location使用

REFER:http://wiki.nginx.org/HttpCoreModule#error_page


假设配置如下:


server {


listen9090;


server_namelocalhost;

location/ {


roothtml;


indexindex.html index.htm;


allow all;


}


#error_page 404http://www.baidu.com#直接这样是不允许的


error_page 404 = @fallback;

location @fallback {


proxy_pass http://www.baidu.com;


}


}

上述配置文件的意思是:如果请求的URI存在,则本nginx返回对应的页面;如果不存在,则把请求代理到baidu.com上去做个弥 补(注:nginx当发现URI对应的页面不存在,HTTP_StatusCode会是404,此时error_page 404指令能捕获它)。

测试一:


[root@web108 ~]#curl http://localhost:9090/nofound.html -i


HTTP/1.1 302 Found


Server: nginx/1.1.0


Date: Sat, 06 Aug 2011 08:17:21 GMT


Content-Type: text/html; charset=iso-8859-1


Location: http://localhost:9090/search/error.html


Connection: keep-alive


Cache-Control: max-age=86400


Expires: Sun, 07 Aug 2011 08:17:21 GMT


Content-Length: 222



302 Found



Found


The document has moved here.



[root@web108 ~]#

当我们GET /nofound.html发送给本nginx,nginx找不到对应的页面,于是error_page 404 = @fallback,请求被代理到http://www.baidu.com,于是nginx给http://www.baidu.com发送了GET /nofound.html,但/nofound.html页面在百度也不存在,百度302跳转到错误页。


直接访问http://www.baidu.com/nofound.html结果:


[root@web108 ~]#curl http://www.baidu.com/nofound.html -i


HTTP/1.1 302 Found


Date: Sat, 06 Aug 2011 08:20:05 GMT


Server: Apache


Location: http://www.baidu.com/search/error.html


Cache-Control: max-age=86400


Expires: Sun, 07 Aug 2011 08:20:05 GMT


Content-Length: 222


Connection: Keep-Alive


Content-Type: text/html; charset=iso-8859-1



302 Found



Found


The document has moved here.



[root@web108 ~]#

测试二:访问一个nginx不存在,但baidu存在的页面


[root@web108 ~]#curl http://www.baidu.com/duty/ -i


HTTP/1.1 200 OK


Date: Sat, 06 Aug 2011 08:21:56 GMT


Server: Apache


P3P: CP=” OTI DSP COR IVA OUR IND COM ”


P3P: CP=” OTI DSP COR IVA OUR IND COM ”


Set-Cookie: BAIDUID=5C5D2B2FD083737A0C88CA7075A6601A:FG=1; expires=Sun, 05-Aug-12 08:21:56 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1


Set-Cookie: BAIDUID=5C5D2B2FD083737A2337F78F909CCB90:FG=1; expires=Sun, 05-Aug-12 08:21:56 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1


Last-Modified: Wed, 05 Jan 2011 06:44:53 GMT


ETag: “d66-49913b8efe340″


Accept-Ranges: bytes


Content-Length: 3430


Cache-Control: max-age=86400


Expires: Sun, 07 Aug 2011 08:21:56 GMT


Vary: Accept-Encoding,User-Agent


Connection: Keep-Alive


Content-Type: text/html


“http://www.w3.org/TR/html4/loose.dtd”>


。。。。




显示,的确百度这个页面是存在的。


[root@web108 ~]#curl http://localhost:9090/duty/ -i


HTTP/1.1 200 OK


Server: nginx/1.1.0


Date: Sat, 06 Aug 2011 08:23:23 GMT


Content-Type: text/html


Connection: keep-alive


P3P: CP=” OTI DSP COR IVA OUR IND COM ”


P3P: CP=” OTI DSP COR IVA OUR IND COM ”


Set-Cookie: BAIDUID=8FEF0A3A2C31D277DCB4CC5F80B7F457:FG=1; expires=Sun, 05-Aug-12 08:23:23 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1


Set-Cookie: BAIDUID=8FEF0A3A2C31D277B1F87691AFFD7440:FG=1; expires=Sun, 05-Aug-12 08:23:23 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1


Last-Modified: Wed, 05 Jan 2011 06:44:53 GMT


ETag: “d66-49913b8efe340″


Accept-Ranges: bytes


Content-Length: 3430


Cache-Control: max-age=86400


Expires: Sun, 07 Aug 2011 08:23:23 GMT


Vary: Accept-Encoding,User-Agent


“http://www.w3.org/TR/html4/loose.dtd”>



。。。




当curl http://localhost:9090/duty/ -i时,nginx没找到对应的页面,于是error_page = @fallback,把请求代理到baidu.com。注意这里的error_page = @fallback不是靠重定向实现的,而是所说的“internally redirected(forward)”。

最新文章

123

最新摄影

微信扫一扫

第七城市微信公众平台