Nginx配置location详解location正则写法
location使⽤语法：
location [ = | ~ | ~* | ^~ ]  uri  { }
# ~区分⼤⼩写的正则匹配；
# ~*不区分⼤⼩写的正则匹配；
# ^~常规字符串匹配；
location语法说明
⼀个⽰例：
location  = / {
# 精确匹配 / ，主机名后⾯不能带任何字符串
[ configuration A ]
}
location  / {
# 因为所有的地址都以 / 开头，所以这条规则将匹配到所有请求
# 但是正则和最长字符串会优先匹配
[ configuration B ]
}
location /documents/ {
# 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索
# 只有后⾯的正则表达式没有匹配到时，这⼀条才会采⽤这⼀条
[ configuration C ]
}
location ~ /documents/Abc {
# 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索
# 只有后⾯的正则表达式没有匹配到时，这⼀条才会采⽤这⼀条
[ configuration CC ]
}
location ^~ /images/ {
# 匹配任何以 /images/ 开头的地址，匹配符合以后，停⽌往下搜索正则，采⽤这⼀条。
[ configuration D ]
}
location ~* \.(gif|jpg|jpeg)$ {
# 匹配所有以 gif,jpg或jpeg 结尾的请求
# 然⽽，所有请求 /images/ 下的图⽚会被 config D 处理，因为 ^~ 到达不了这⼀条正则
[ configuration E ]
}
location /images/ {
# 字符匹配到 /images/，继续往下，会发现 ^~ 存在
[ configuration F ]
pdf文本框怎么设置透明}
location /images/abc {
# 最长字符匹配到 /images/abc，继续往下，会发现 ^~ 存在
# F与G的放置顺序是没有关系的
[ configuration G ]
}
location ~ /images/abc/ {
# 只有去掉 config D 才有效：先最长匹配 config G 开头的地址，继续往下搜索，匹配到这⼀条正则，采⽤[ configuration H ]
}
location ~* /js/.*/\.js
以=开头表⽰精确匹配
如 A 中只匹配根⽬录结尾的请求，后⾯不能带任何字符串。
^~开头表⽰uri以某个常规字符串开头，不是正则匹配
schedule into~ 开头表⽰区分⼤⼩写的正则匹配;
~* 开头表⽰不区分⼤⼩写的正则匹配
/ 通⽤匹配, 如果没有其它匹配，任何请求都会匹配到
顺序 no优先级：(location =) > (location 完整路径) > (location ^~ 路径) > (location ~,~* 正则顺序) > (location 部分起始路径) > (/)
上⾯的匹配结果按照上⾯的location写法，以下的匹配⽰例成⽴：
/ -> config A
精确完全匹配，即使/index.html也匹配不了
/downloads/download.html -> config B
匹配B以后，往下没有任何匹配，采⽤B
/images/1.gif -> configuration D
sumproduct函数的使用方法及实例(下)匹配到F，往下匹配到D，停⽌往下
/images/abc/def -> config D
最长匹配到G，往下匹配D，停⽌往下
你可以看到 任何以/images/开头的都会匹配到D并停⽌，FG写在这⾥是没有任何意义的，H是永远轮不到的，这⾥只是为了说明匹配顺序      /documents/document.html -> config C
匹配到C，往下没有任何匹配，采⽤C
/documents/1.jpg -> configuration E
匹配到C，往下正则匹配到E
/documents/Abc.jpg -> config CC
最长匹配到C，往下正则顺序匹配到CC，不会往下到E
实际使⽤建议
所以实际使⽤中，个⼈觉得⾄少有三个匹配规则定义，如下：
#直接匹配⽹站根，通过域名访问⽹站⾸页⽐较频繁，使⽤这个会加速处理，官⽹如是说。
#这⾥是直接转发给后端应⽤服务器了，也可以是⼀个静态⾸页
# 第⼀个必选规则
location = / {
}
# 第⼆个必选规则是处理静态⽂件请求，这是nginx作为http服务器的强项
# 有两种配置模式，⽬录匹配或后缀匹配，任选其⼀或搭配使⽤
location ^~ /static/ {
root /webroot/static/；
}
location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ {
root /webroot/res/;
}
#第三个规则就是通⽤规则，⽤来转发动态请求到后端应⽤服务器
#⾮静态⽂件请求就默认是动态请求，⾃⼰根据实际把握
#毕竟⽬前的⼀些框架的流⾏，带.php,.jsp后缀的情况很少了asp+access统计图源码
location / {
}
R ew r ite规则：
rite规则：
Nginx的rewrite的主要功能是实现URL地址重写。Nginx的rewrite规则需要PCRE软件的⽀持，即通过Perl兼容正则表达式语法进⾏规则匹配。Nginx rewrite语法：
rewrite regex replacement [flag]；
#应⽤位置：server、location、if
如果相对域名或参数字符串起作⽤，可以使⽤全局变量匹配，也可以使⽤proxy_pass反向代理。
表明看rewrite和location功能有点像，都能实现跳转，主要区别在于rewrite是在同⼀域名内更改获取资源的路径，⽽location是对⼀类路径做控制访问或反向代理，可以proxy_pass到其他机器。很多情况下rewrite也会写在location⾥，它们的执⾏顺序是：
1、执⾏server块的rewrite指令
position和location的区别
2、执⾏location匹配
3、执⾏选定的location中的rewrite指令
如果其中某步URI被重写，则重新循环执⾏1-3，直到到真实存在的⽂件；循环超过10次，则返回500 Internal Server Error错误。
fla g 标志位：
last : 相当于Apache的[L]标记，表⽰完成rewrite；
last
break : 停⽌执⾏当前虚拟主机的后续rewrite指令集；
break
redirect : 返回302临时重定向，地址栏会显⽰跳转后的地址；
redirect
permanent : 返回301永久重定向，地址栏会显⽰跳转后的地址；
permanent
#last和break⽤来实现URL重写，浏览器地址栏的URL地址不变，但在服务器端访问的程序及路径发⽣了变化；
#redirect和permanent⽤来实现URL跳转，浏览器地址栏会显⽰跳转后的URL地址；
flag标志说明
怎么弄因为301和302不能简单的只返回状态码，还必须有重定向的URL，这就是return指令⽆法返回301,302的原因了。这⾥ last 和 break 区别有点难以理解：
last⼀般写在server和if中，⽽break⼀般使⽤在location中；
last不终⽌重写后的url匹配，即新的url会再从server⾛⼀遍匹配流程，⽽break终⽌重写后的匹配；
break和last都能组织继续执⾏后⾯的rewrite指令；
使⽤proxy_pass指令时要使⽤break标记；
Nginx的rewrite功能在企业⾥应⽤⾮常⼴泛：
可以调整⽤户浏览的URL，使其看起来更规范，合乎开发⼈员及产品⼈员的需求；

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。