nginx location配置看看文档都会，主要是记不住，写下来方便查询。主要是优先级要搞清楚，不然工程大了，匹配的莫名其妙。本文按优先级依次介绍。

总述：精确匹配(=) > 字符串打头匹配(^~)  >  正则匹配(~或~*) >否定式正则匹配（!~或!~*） > 通用匹配（/）。两种正则当中，区分大小写的优先级高，也就是不带*的优先级高

1.精确匹配

= 精确匹配
location = / {
   #精确匹配访问网站根目录
}
location = /login {
   #精确匹配http://xxx.com/login
}
精确匹配优先级最高，匹配是唯一的

2.以什么打头

^~ 表示以什么打头，关键在于正则的开头符 ^
location ^~ /static/ {
   #以/static打头，比如 http://xxx.com/static/jQuery.js
}

3. 正则匹配，区分大小写优先于不区分大小写

~ 区分大小写的正则， ~* 不区分大小的正则
location ~ \.png {
    #以png结尾，比如比如 http://xxx.com/img/a.png
}
location ~* \.png$ {
    #以png或者PNG或者Png等等结尾，比如比如 http://xxx.com/img/a.pNg。如果是png结尾，会优先匹配上面一条。
}

4.排除法的正则，同样区分大小写优先于不区分大小写

!~ 区分大小写的排除法正则， !~*不区分大小的排除法正则

排除法正则是指，url与该正则不匹配，才算合格，才能进入此location。相当于正则匹配的否定写法。不建议实际工程中使用，毕竟肯定能表达的干嘛写否定式呢？很不利于排除问题。小心装逼不成，坑了自己的KPI。
location !~ \.png$ {
   #匹配“以png结尾”失败，进入location，那就情况多了去了，只要不以png结尾就行
}
location !~* \.xhtml$ {
   #匹配“以png或者PNG或者PnG等等”结尾失败，进入location，那情况也多了去了，只要不是PNG的各种大小写变体就行
}

5.通用匹配

/ 通用匹配，任何请求都会匹配到。
location / {
   #用来兜底的，当前面其他所有的规则都不满足条件，就归入这个通用的
}

6.另类字符串匹配


location /prefix/mid/ { # 啥也不写，不属于以上任何一种 }


首先，不建议写这种，原因有点深：对于location，分为两大类：官方英文说法是 location using literal strings 和 location using regular expressions，我们就字面翻译为字符串location和正则location.总体上字符串location优先于正则location。

字符串location不使用=或者^~，nginx会采用“最大前缀匹配”原则在字符串location里面选出匹配度最高的一个做为临时选择结果Temp，然后继续在正则location中匹配，如果匹配到某个正则location，则立即停止并且最终使用该正则location，如果没有匹配到正则location，那么就选择临时结果Temp(此结果由“最大前缀匹配”原则产生，与location编辑顺序无关)。

那么字符串location选择出了最大前缀匹配临时结果，能不能停止，不在考虑正则呢？可以。就是使用=或者^~。那就回到了上面讲的几类。

7.“@”前缀


server { listen 80; server_name localhost; 

location  / {
        root   html;
        index  index.html index.htm;
        allow all;
    }

    #error_page 404 http://www.error.com # 直接这样是不允许的
    error_page 404 = @fallback;

    location @fallback {
        proxy_pass http://www.error.com;
    }

}


error_page 404指令能捕获404错误，并且转发给fallback