return 指令
return 指令手册
在重定向满足两个条件时适用：
重写的 URL 适用于每个匹配的 server 或 location 的请求
可以使用标准的 nginx 变量构建重写的 URL
return 指令简单高效，建议尽量使用 return，而不是 rewrite。
return 指令放在 server 或 location 上下文中。语法很简单：
return code [text];
return code URL;
return URL;
将客户重定向到一个新域名的示例：
server {
listen 80;
listen 443 SSL;
server_name www.old-name.com;
return 301 $scheme://www.new-name.com$request_uri;
}
上面代码中，listen 指令表明 server 块同时用于 HTTP 和 HTTPS 流量。server_name 指令匹配包含域名 ‘www.old-name.com’ 的请求。return 指令告诉 Nginx 停止处理请求，直接返回 301 (Moved Permanently) 代码和指定的重写过的 URL 到客户端。$scheme 是协议（HTTP 或 HTTPS），$request_uri 是包含参数的完整的 URI。
对于 3xx 系列响应码，url 参数定义了新的（重写过的）URL：
return (301 | 302 | 303 | 307) url;
1
对于其他响应码，可以选择定义一个出现在响应正文中的文本字符串（HTTP 代码的标准文本，例如 404 的 Not Found，仍包含在标题中）。文本可以包含 NGINX 变量。
return (1xx | 2xx | 4xx | 5xx) ["text"];
1
例如，在拒绝没有有效身份验证令牌的请求时，此指令可能适用：
return 401 "Access denied because token is expired or invalid";
1
通过 error_page 指令，可以为每个 HTTP 代码返回一个完整的自定义 HTML 页面，也可以更改响应代码或执行重定向。
rewrite 指令
NGINX Rewrite 规则官方文档
Rewrite 模块手册
HTTP 响应码
rewrite 规则会改变部分或整个用户请求中的 URL，主要有两个用途：
通知客户端，请求的资源已经换地方了。例如网站改版后添加了 www 前缀，通过 rewrite 规则可以将所有请求导向新站点。
控制 Nginx 中的处理流程。例如当需要动态生成内容时，将请求转发到应用程序服务器。try_files 指令经常用于这个目的。
但是，如果需要测试 URL 之间更复杂的区别，或者要从原始 URL 中捕获的元素没有对应的 NGINX 变量，或者更改或添加路径中的元素（例如各大 PHP 框架常用的 index.php 入口文件），该怎么办？ 可以使用 rewrite 指令。
rewrite 指令放在 server 或 location 上下文中。语法很简单：
rewrite regex URL [flag];
1
第一个参数 regex 是正则表达式。
————————————————
版权声明：本文为CSDN博主「kikajack」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/kikajack/java/article/deTails/80669260
location
在 Nginx 的配置文件中，通过 location 匹配用户请求中的 URI。格式如下：
location 前缀字符串 URL {
[ 配置 ]
}
前缀字符串及优先级
其中，前缀字符串部分支持 5 种：
=：精确匹配，优先级最高。如果找到了这个精确匹配，则停止查找。
^~：URI 以某个常规字符串开头，不是正则匹配
~：区分大小写的正则匹配
~*：不区分大小写的正则匹配
/：通用匹配, 优先级最低。任何请求都会匹配到这个规则
优先级为： = > 完整路径 > ^~ > ~、~* > 部分起始路径 > /
示例
# 精确匹配 / ，域名后面不能带任何字符串。匹配到后，停止继续匹配
location = / {
}
# 匹配到所有请求
location / {
if (-f $request_filename) {
expires max;
break;
}
if (!-e $request_filename) {
rewrite ^/(.*)$ /index.php/$1 break;
}
index index.php;
autoindex off;
}
# 匹配任何以 /documents/ 开头的 URI。优先级低于正则表达式，匹配到后还会继续往下匹配，当后面没有正则匹配或正则匹配失败时，使用这里代码
location /documents/ {
}
# 最长字符匹配到 /images/abc，继续往下，会发现 ^~ 存在
location /images/abc {
}
# 匹配任何以 /images/ 开头的 URI。优先级高于正则表达式，匹配成功后，停止往下搜索正则。
location ^~ /images/ {
}
# 正则匹配，区分大小写。匹配任何以 /documents/Abc 开头的地址，匹配符合以后，还要继续往下搜索
location ~ /documents/Abc {
}
# 正则匹配，忽略大小写。匹配所有以 gif、jpg 或 jpeg 结尾的请求
location ~* \.(gif|jpg|jpeg)$ {
}
location 匹配原则
可以 参考这篇译文。
每个请求的处理逻辑顺序如下：
用所有的前缀字符串测试 URI。
等号 = 定义了前缀字符串和 URI 的精确匹配关系。如果找到了这个精确匹配，则停止查找。
如果 ^~ 修饰符预先匹配到最长的前缀字符串，则不检查正则表达式。
存储最长的匹配前缀字符串。
用正则表达式测试 URI。
匹配到第一个正则表达式后停止查找，使用对应的 location。
如果没有匹配到正则表达式，则使用之前存储的前缀字符串对应的 location。
nginx:192.168.3.142
后端蜘蛛服务器：192.168.2.147
修改Nginx配置文件
………….
upstream zhizhu {
server 192.168.2.147;
}
server{
location / {
if ($http_user_agent ~* “Baiduspider|360Spider|bingbot|Googlebot|Sogou web spider”) { #####判断多个蜘蛛，中间用| 隔开
proxy_pass http://zhizhu;
}
}
………………..
}
……….
完成之后，/etc/init.d/nginx reload
测试访问
# curl -I -A “Baiduspider” http://www.caonima.com
HTTP/1.1 200 OK
Server: nginx/1.6.3
Date: Fri, 08 Jul 2016 07:11:09 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Set-Cookie2: aiyuke_cookie=8b801b25.5371a8061fc8b; path=/; max-age=31536000
X-Powered-By: PHP/5.4.10
BackendServer: 2.147
