HTTP Core模块

2019-02-15 17:13:19
linefo
526
最后编辑:linefo 于 2019-02-21 10:15:37


【error_page】

语法: error_page code [ code... ] [ = | =answer-code ] uri | @named_location

缺省值:

放的位置:http, server, location, if in location

指定用在错误出现时的错误页面,可以针对不同错误指定不同错误页面。

如error_page 404 /404.html

该配置需要要将proxy_intercept_errors设置为on才会起效。


【index】

语法: index file [file...]
缺省值: index index.html

放的位置:http, server, location

即指定默认访问的页面,可以用空格隔开多个页面表示一种顺序访问(从左到右,直到读到第一个有效页面)


【listen】

语法: listen address:port [ default [ backlog=num | rcvbuf=size | sndbuf=size | accept_filter=filter | deferred | bind | ssl ] ]
缺省值: listen 80

放的位置:server

指定监听 (IP)和端口。

这里放一些参考吧:

listen 127.0.0.1:8000;
listen 127.0.0.1 #不加端口,默认监听80端口;
listen 8000 #不加ip,默认监听所有ip?
listen *:8000
listen localhost:8000


【location】

语法: location [=|~|~*|^~] /uri/ { ... }
缺省值: no

放的位置:server

= 开头表示精确匹配
^~ 开头表示uri以某个常规字符串开头,理解为匹配 url路径即可。nginx不对url做编码,因此请求为/static/20%/aa,可以被规则^~ /static/ /aa匹配到(注意是空格)。
~ 开头表示区分大小写的正则匹配
~*  开头表示不区分大小写的正则匹配
!~和!~*分别为区分大小写不匹配及不区分大小写不匹配 的正则
/ 通用匹配,任何请求都会匹配到。

参考:


location = / {  
   #规则A  
}  
location = /login {  
   #规则B  
}  
location ^~ /static/ {  
   #规则C  
}  
location ~ \.(gif|jpg|png|js|css)$ {  
   #规则D  
}  
location ~* \.png$ {  
   #规则E  
}  
location !~ \.xhtml$ {  
   #规则F  
}  
location !~* \.xhtml$ {  
   #规则G  
}  
location / {  
   #规则H  
}  




那么产生的效果如下:

访问根目录/, 比如http://localhost/ 将匹配规则A
访问 http://localhost/login 将匹配规则B,http://localhost/register 则匹配规则H
访问 http://localhost/static/a.html 将匹配规则C
访问 http://localhost/a.gif, http://localhost/b.jpg 将匹配规则D和规则E,但是规则D顺序优先,规则E不起作用,而 http://localhost/static/c.png 则优先匹配到 规则C
访问 http://localhost/a.PNG 则匹配规则E, 而不会匹配规则D,因为规则E不区分大小写。
访问 http://localhost/a.xhtml 不会匹配规则F和规则G,http://localhost/a.XHTML不会匹配规则G,因为不区分大小写。规则F,规则G属于排除法,符合匹配规则但是不会匹配到,所以想想看实际应用中哪里会用到。
访问 http://localhost/category/id/1111 则最终匹配到规则H,因为以上规则都不匹配,这个时候应该是nginx转发请求给后端应用服务器,比如FastCGI(php),tomcat(jsp),nginx作为方向代理服务器存在。

所以实际使用中,通常至少有三个匹配规则定义,如下:



#直接匹配网站根,通过域名访问网站首页比较频繁,使用这个会加速处理,官网如是说。  
#这里是直接转发给后端应用服务器了,也可以是一个静态首页  
# 第一个必选规则  
location = / {  
    proxy_pass http://tomcat:8080/index  
}  
   
# 第二个必选规则是处理静态文件请求,这是nginx作为http服务器的强项  
# 有两种配置模式,目录匹配或后缀匹配,任选其一或搭配使用  
location ^~ /static/ {  
    root /webroot/static/;  
}  
location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ {  
    root /webroot/res/;  
}  
   
#第三个规则就是通用规则,用来转发动态请求到后端应用服务器  
#非静态文件请求就默认是动态请求,自己根据实际把握  
#毕竟目前的一些框架的流行,带.php,.jsp后缀的情况很少了  
location / {  
    proxy_pass http://tomcat:8080/  
}  




【root】

语法: root path
缺省值: root html

放的位置:http, server, location, if in location

即设置根目录,一般在server块中放一个即可,当然也可以根据不同的url规则,放在location指令块中。


【server】

语法: server {...}
缺省值: no
放的位置: http
可以把一个server看做一个端口web映射的整体配置块


【server_name】

语法: server_name name [... ]
缺省值: server_name hostname
放的位置: server
这里写供指定的域名


【try_files】

语法: try_files file1 [file2 ... filen] fallback
缺省值: none
放的位置: location

这个稍微复杂一点,贴一段英文翻译的原文:

按顺序检查文件是否存在,返回第一个找到的文件。结尾的斜线表示为文件夹 -$uri/。如果所有的文件都找不到,会进行一个内部重定向到最后一个参数。
务必确认只有最后一个参数可以引起一个内部重定向,之前的参数只设置内部URI的指向。 最后一个参数是回退URI且必须存在,否则将会出现内部500错误。
命名的location也可以使用在最后一个参数中。与rewrite指令不同,如果回退URI不是命名的location那么$args不会自动保留,如果你想保留$args,必须明确声明。

try_files 将尝试你列出的文件并设置内部文件指向


示例1:


try_files $uri $uri/ /index.php;



示例1解析

http://servers.blog.ustc.edu.cn/example 时,这里的 $uri 就是 /example。try_files 会到硬盘里尝试找这个文件。如果存在名为 /$root/example(其中 $root 是 WordPress 的安装目录)的文件,就直接把这个文件的内容发送给用户。显然,目录中没有叫 example 的文件。然后就看 $uri/,增加了一个 /,也就是看有没有名为 /$root/example/ 的目录。又找不到,就会 fall back 到 try_files 的最后一个选项 /index.php,发起一个内部 “子请求”,也就是相当于 nginx 发起一个 HTTP 请求到 http://servers.blog.ustc.edu.cn/index.php。这个请求会被 location ~ \.php$ { ... } catch 住,也就是进入 FastCGI 的处理程序。而具体的 URI 及参数是在 REQUEST_URI 中传递给 FastCGI 和 WordPress 程序的,因此不受 URI 变化的影响。


示例2:


location / {
     try_files index.html index.htm @fallback;
}
 
location @fallback {
    root  /var/www/error;
    index index.html;
}


示例3:


try_files $uri $uri/ @rewrite;
location @rewrite {
    rewrite ^/(.*)$ /index.php?_url=/$1;
}