说到 Nginx 就不得不说 Nginx 的反向代理是多么的好用，一个指令 proxy_pass 搞定反向代理，对于接口代理、负载均衡很是实用，但 proxy_pass 指令后面的参数很有讲究。

网上有很多什么绝对路径、相对路径的说法，其实在实际的应用中就分为两种情况：

url 只是 host

这里指不包含 $uri ，如：

  • http://host – √
  • https://host – √
  • http://host:port – √
  • https://host:port – √
  • http://host/ – x
  • http://host:port/ – x

这时候 location 匹配的完整路径将直接透传给 url ，如：

// 访问：   /                               后端：   /
// 访问：   /api/xx                         后端：   /api/xx
// 访问：   /api/xx?aa                      后端：   /api/xx?aa
location / {
    proxy_pass http://node:8080;
}

// 访问：   /api/                           后端：   /api/
// 访问：   /api/xx                         后端：   /api/xx
// 访问：   /api/xx?aa                      后端：   /api/xx?aa
// 访问：   /api-xx?aa                      后端：
location /api/ {
    proxy_pass http://node:8080;
}

// 访问：   /api/                           后端：   /api/
// 访问：   /api/xx                         后端：   /api/xx
// 访问：   /api/xx?aa                      后端：   /api/xx?aa
// 访问：   /api-xx?aa                      后端：   /api-xx?aa
location /api {
    proxy_pass http://node:8080;
}

url 包含路径

注意，这里的路径哪怕只是一个 / 也是存在的，如：

  • http://host – x
  • https//host/ – √
  • http://host:port – x
  • https://host:port/ – √
  • http://host/api – √
  • http://host/api/ – √

当 proxy_pass url 的 url 包含路径时，匹配时会根据 location 的匹配后的链接透传给 url ，注意匹配后就是这样：

 
location 规则 访问的原始链接 匹配之后的路径
location / /  
location / /a a
location / /a/b/c?d a/b/c?d
location /a/ /a/  
location /a/ /a/b/c?d b/c?d

 

 

 

明白匹配之后的路径后，在 proxy_pass url 包含路径时，将会把匹配之后的路径透传给 url ，如：

 
  

// 访问：   /                               后端：   /
// 访问：   /api/xx                         后端：   /api/xx
// 访问：   /api/xx?aa                      后端：   /api/xx?aa
location / {
    proxy_pass http://node:8080/;
}

// 访问：   /api/                           后端：   /
// 访问：   /api/xx                         后端：   /xx
// 访问：   /api/xx?aa                      后端：   /xx?aa
// 访问：   /api-xx?aa                      未匹配
location /api/ {
    proxy_pass http://node:8080/;
}

// 访问：   /api                            后端：   /
// 访问：   /api/                           后端：   //
// 访问：   /api/xx                         后端：   //xx
// 访问：   /api/xx?aa                      后端：   //xx?aa
// 访问：   /api-xx?aa                      后端：   /-xx?aa
location /api {
    proxy_pass http://node:8080/;
}

// 访问：   /api/                           后端：   /v1
// 访问：   /api/xx                         后端：   /v1xx
// 访问：   /api/xx?aa                      后端：   /v1xx
// 访问：   /api-xx?aa                      未匹配
location /api/ {
    proxy_pass http://node:8080/v1;
}

// 访问：   /api/                           后端：   /v1/
// 访问：   /api/xx                         后端：   /v1/xx
// 访问：   /api/xx?aa                      后端：   /v1/xx
// 访问：   /api-xx?aa                      未匹配
location /api/ {
    proxy_pass http://node:8080/v1/;
}

由以上规则可以看出，当 proxy_pass url 中包含路径时，结尾的 / 最好同 location 匹配规则一致。

当 proxy_pass 遇到正则

当 location 以正则形式匹配时，proxy_pass 就不能以 / 结束了，也就是不能包含路径了，比如错误的：

  

location ~* ^/api/ {
    proxy_pass http://host/;
}

location / {
    if ($uri ~* ^/api/) {
        proxy_pass http://host/;
    }
}

解决办法就是把链接中的路径去掉。

 

重写代理链接 – url rewrite

当原始链接（浏览器访问的链接）和代理服务器链接规则不一致时，可以使用 Nginx URL Rewrite 功能去动态的重写，如：

location ~* ^/api/ {
    rewrite ^/api/(.*) /?path=$1 break;
    proxy_pass http://node:8080;
}

以上请求会把匹配 /api/ 的链接重写为 /?path= 的链接透传给 node:8080 服务，有意思的是当使用 rewrite 指令并且生效后，proxy_pass url 链接中的路径会被忽略，如：

  

// 访问：   /                               后端：   /node/
// 访问：   /api                            后端：   /node/api
// 访问：   /api/                           后端：   /?path=
// 访问：   /api/a/b/c                      后端：   /?path=a/b/c
location / {
    rewrite ^/api/(.*) /?path=$1 break;
    proxy_pass http://node:8080/node/;
}

 

原文地址：http://www.cnblogs.com/CnKker/p/16818495.html

1. 本站所有资源来源于用户上传和网络，如有侵权请邮件联系站长！ 2. 分享目的仅供大家学习和交流，请务用于商业用途! 3. 如果你也有好源码或者教程，可以到用户中心发布，分享有积分奖励和额外收入！ 4. 本站提供的源码、模板、插件等等其他资源，都不包含技术服务请大家谅解！ 5. 如有链接无法下载、失效或广告，请联系管理员处理！ 6. 本站资源售价只是赞助，收取费用仅维持本站的日常运营所需！ 7. 如遇到加密压缩包，默认解压密码为"gltf",如遇到无法解压的请联系管理员！ 8. 因为资源和程序源码均为可复制品，所以不支持任何理由的退款兑现，请斟酌后支付下载 声明：如果标题没有注明"已测试"或者"测试可用"等字样的资源源码均未经过站长测试.特别注意没有标注的源码不保证任何可用性