记录一次部署遇到的nginx反向代理的问题

最近，项目组的系统要在别的地方部署上线，虽然我并未被派去到现场，但是也得远程支撑。据我所了解到的现场状况是，现场使用ingress作为统一的入口，然后根据url前缀进行路由转发，而目前已经在根路径部署了一套前端系统，所以我们的系统需要部署在一个特定的路径下，即需要添加一个基础路由。项目是前后端分离，前端使用vue技术栈，后端使用spring boot，鉴权这块使用了公司内部开发的网关，服务在网关后面，大致的部署架构如下图所示：

对于架构本身的合理性不在此讨论，部署主要目的是要系统能正常访问。项目组也没人有过类似的部署经验，现场的兄弟也是头大，他一个后端开发被拉出去当运维，还得面对原生k8s的洗礼，想想都觉得挺难。

本人作为前端远程进行支撑，对于现场这样的需求，前端其实比较好修改，只需要修改vue-router配置中的base即可，nginx的配置也要做相应的修改。而在我周五快下班的时候打包发给现场以为部署可以很快结束，我可以按时下班的时候，现场反馈接口调用不通，无法进行登录，一种不祥的预感涌上心头，哎，老老实实加班吧。

后来现场把nginx配置发过来让公司的同事一起看看，顺便提一嘴，这个项目前端的容器中的nginx不仅负责静态资源的访问，还负责对请求接口的转发，nginx配置了所有匹配的后端接口都转发到网关服务的端口，在测试环境的nginx配置是这样的:

nginx 复制代码

#...

location /server1 {
  proxy_redirect off;
  proxy_pass http://192.168.1.1:8080;
}

location /server2 {
  proxy_redirect off;
  proxy_pass http://192.168.1.1:8080;
}

#...

http://192.168.1.1:8080就是网关服务所在的地址，但是由于现场的环境对网关的访问多了一层路由(/gateway)，因此现场把nginx修改为：

nginx 复制代码

#...

location /server1/ {
  proxy_redirect off;
  proxy_pass http://192.168.1.1:8080/gateway;
}

location /server2/ {
  proxy_redirect off;
  proxy_pass http://192.168.1.1:8080/gateway;
}

#...

我们也研究了很久，怎么也看不出问题，最后把家里测试环境也改成和现场一样，结果同样访问不同，接口报404，网关也没有日志，真是丈二和尚摸不着头脑，项目的boss给我们点了外卖，联系电话留得一个同事的，然后自己溜了，溜了也好，他在我们反而不自在，也帮不上什么忙。我们一边吃着外卖一边各种尝试。现场的同事发现，如果直接访问/web/server1/xxx就无法访问，但是访问/gateway/server1/xxx就能访问通(这里感谢现场同事)。这尼玛不就是意味着nginx代理有问题嘛！赶紧在网上找一下proxy_pass的使用方法，一查果然问题出在这里！

当proxy_pass的url只是host时，location 匹配的完整路径将直接透传给url。

nginx 复制代码

location /server1 {
  proxy_pass http://192.168.1.1:8080;
}

按照以上配置，当匹配到/server1/a/b，nginx代理的url就是http://192.168.1.1:8080/server1/a/b

而当proxy_pass的url包含路径，哪怕是只有一个/，就会转用另一套规则。

nginx 复制代码

location /server1/ {
  proxy_pass http://192.168.1.1:8080/gateway;
}

按照以上配置，当匹配到/server1/a/b，nginx代理的url就是http://192.168.1.1:8080/gatewaya/b。当proxy_pass的url包含路径，nginx只会把location作为匹配项，但是代理时会把匹配项之后的uri拼接到proxy_pass的url的后面。

所以接口怎么也访问不通，这个接口根本没办法转发到网关服务！后来修改代理的配置为：

nginx 复制代码

location /server1/ {
  rewrite ^/(.*) /gateway/$1 break;
  proxy_pass http://192.168.1.1:8080;
}

通过rewrite对路径进行重写，手动加上/gateway前缀。

至此，总算找到问题并顺利解决，这个细节性的东西，如果不认真的学一遍，真的没办法一下就找到问题，有了这次经历，以后配置nginx就不会犯这样"大聪明"的错误了。

参考链接： proxy_pass url 反向代理的坑