Nginx转发404问题的排查和思考

时代喔

目录

• 项目背景
  
• 问题
  
• 因端口映射导致的访问 502 问题
  
• proxy_pass 转发 url 丢弃路径导致的 404 问题
  
  
  
  • proxy_pass 配置以 / 结尾和不以 / 结尾的区别
    
  • 关于 proxy_pass 以及 location
    
  
  

项目背景

项目是 toG 项目，部署的网络环境是一个大的内网环境（又具体分为内网和内网互联网区），项目涉及到小程序、前端、后端（又包括 JAVA 和 GO 两个项目）的部署。整体的部署拓扑图大致如下：

1. 虚拟 IP 映射：大多数内网如何需要暴露对外访问，会在出口的核心路由上配置一个虚拟的 IP 作为对外的统一访问入口。比如你的内网地址及端口是 10.13.3.177:8080，则通过虚拟 IP 映射的地址及端口可能是：10.31.31.253:8080。

复制代码

在这个业务流程程，访问路径是：公网（小程序前台）-> 内网互联网区【10.31.1.142(nginx + 小程序后台)】 -> 【10.31.31.253 -> 10.13.3.177(nginx+后端)】 -> 【10.233.1.2 -> 172.13.7.249(nginx+后端)】。其中 10.13.3.177 和 172.13.7.249 是两台虚拟机，虚拟机上部署了nginx 和 后端服务。

1. <strong>PS：上述所有的 IP 均已做过处理，非正式 IP。</strong>

复制代码

问题

访问步骤及问题节点：

• 1、小程序访小程序后台服务
  
• 2、小程序后台服务发起调用到
  1. 10.31.31.253

  复制代码
  （这里实际上是
  1. 10.31.1.142

  复制代码
  要调用
  1. 10.233.1.2

  复制代码
  的服务，因为
  1. 10.31.1.142

  复制代码
  不能直接访问
  1. 10.233.1.2

  复制代码
  ，所以借用
  1. 10.31.31.253

  复制代码
  来实现一层转发逻辑）。
  

这里会涉及到两个转发，

• 1. 10.31.31.253

  复制代码
  对应的
  1. 10.13.3.177

  复制代码
  这台机器上的 nginx 需要将
  1. 10.31.1.142

  复制代码
  的请求转发给
  1. 10.233.1.2

  复制代码
• 1. 10.233.1.2

  复制代码
  对应的 nginx 需要将请求到当前机器的后台服务上
  

在转发时通过

1. 10.31.31.253

复制代码

调用

1. 10.233.1.2

复制代码

时出现 404，

1. 10.233.1.2

复制代码

调用本机后端服务时也出现 404；还有一个 502 是

1. 10.31.1.142

复制代码

访问

1. 10.31.31.253

复制代码

出现的。下面是分析问题的大体过程和解决办法。

因端口映射导致的访问 502 问题

前面提到

1. 10.31.31.253

复制代码

和

1. 10.233.1.2

复制代码

均是 虚拟 IP ，

1. 10.31.31.253:8805

复制代码

端口映射到虚拟机

1. 10.13.3.177

复制代码

上的端口是 18805，

1. 10.13.3.177

复制代码

上 nginx 配置的监听端口是 18805，所以

1. 10.31.1.142

复制代码

在访问的第一跳是

1. 10.31.31.253:8805

复制代码

，但在实际排查中发现，

1. 10.31.1.142

复制代码

访问的是

1. 10.31.31.253:18805

复制代码

，所以出现 502 问题。

1. 状态码 502 表示 HTTP 协议中的 "Bad Gateway"，通常用于表示服务器作为网关或代理时遇到了问题。这个错误通常会在一个服务器作为中介时，无法从另一个服务器获取有效响应以满足客户端请求时出现。

复制代码

proxy_pass 转发 url 丢弃路径导致的 404 问题

根据前面的背景，实际上两个 404 问题均是因为这个原因导致。

1. 10.31.1.142

复制代码

发起的请求是

1. 10.31.31.253:8805/miniapp/user/case

复制代码

, nginx access.log 的日志如下：

1. "POST /miniapp/user/case HTTP/1.1" 404 153 "-" "Java/1.8.0_351"
   
2. "POST /miniapp/user/case HTTP/1.1" 404 153 "-" "Java/1.8.0_351"
   
3. "POST /miniapp/user/case HTTP/1.1" 404 153 "-" "Java/1.8.0_351"

复制代码

因为这个请求不是 10.31.31.253 对应的 10.13.3.177 这台机器上的服务处理，而是直接转发给 10.233.1.2 对应的 172.13.7.249 机器的，因此这里出现 404，因为是转发到 172.13.7.249 时没有找到相应的资源。查看 249 机器上的 nginx 访问日志

1. "POST /user/case HTTP/1.0" 404 153 "-" "Java/1.8.0_351"
   
2. "POST /user/case HTTP/1.0" 404 153 "-" "Java/1.8.0_351"
   
3. "POST /user/case HTTP/1.0" 404 153 "-" "Java/1.8.0_351"

复制代码

可以看到， 249 这台机器上的请求变成了 /user/case，丢失了 /miniapp 这个 prefix，10.13.3.177 机器的 nginx 配置如下：

1. location /miniapp/ {
   
2.     // 主要是这里
   
3.     proxy_pass http://10.31.31.253:8805/;
   
4. }

复制代码

关于这个问题，解决方案大致有如下几种（来源各种技术文章）：

• 1、修改代理配置：将匹配以 /miniapp 开头的所有请求，并将它们代理到 10.31.31.253:8805，保持请求 URI 不变。
  

1. location /miniapp {
   
2.     proxy_pass http://10.31.31.253:8805;
   
3. }

复制代码

• 2、使用正则表达式捕获和重写 URI：捕获以 /miniapp 开头的请求，并将 /miniapp 后面的部分传递给后端服务器。
  

1. location ~ ^/miniapp(/.*)$ {
   
2.     proxy_pass http://10.31.31.253$1;
   
3. }

复制代码

• 3、rewrite 重写：使用 rewrite 指令将 /miniapp 后面的部分提取出来，然后将其传递给后端服务器
  

1. location /miniapp/ {
   
2.     rewrite ^/miniapp(/.*)$ $1 break;
   
3.     proxy_pass http://10.31.31.253;
   
4. }

复制代码

• 4、保留 location 前缀：就是将 location 前缀保留在 proxy_pass 的后面
  

1. location /miniapp/ {
   
2.     proxy_pass http://10.31.31.253:8805/miniapp/;
   
3. }

复制代码

经测试，方案 1 和 方案 4 是可以解决 404 问题的。其中方案 4 是**有病治病的逻辑，转发丢弃则就加上。**这两个问题对于了解 nginx proxy_pass 配置的同学来说应该一眼就可以看到问题所在，但是 大多数时候，我们会忽略那些看起来并不是很显眼的东西，比如

1. /

复制代码

。

proxy_pass 配置以 / 结尾和不以 / 结尾的区别

• 以 / 结尾的proxy_pass配置
  

1. location /miniapp/ {
   
2.     proxy_pass http://10.31.31.253:8805/;
   
3. }

复制代码

这种配置方式没有斜杠 / 结尾，意味着 Nginx 会将原始请求的 URI 原封不动地传递给后端服务器。例如，如果原始请求是 http://10.31.1.142/miniapp/user/case，那么 Nginx 会将它代理到http://10.31.31.253:8805/miniapp/user/case。
所以说，如果你希望将请求映射到后端服务器的根目录，则可以使用以斜杠

1. /

复制代码

结尾的配置。如果你希望保持URI不变，可以使用不以

1. /

复制代码

结尾的配置。

关于 proxy_pass 以及 location

网上关于这两个介绍的文章非常多，本篇不做过多的阐述。

• proxy_pass 指令用于定义 Nginx 的 反向代理 功能。它指定了将客户端请求代理到的后端服务器的地址。
  
• location 指令用于匹配客户端请求的 URI，然后定义如何处理这些请求。
  

问题其实不是很复杂，主要还是对于 nginx 的一些配置作用不大清楚，另外就是在实际排查过程中，因为链路和网络环境问题走了很多弯路；但是如果把这些信息梳理清楚了，就会拨云见日；问题就在那里，复杂的是过程。
以上就是Nginx转发404问题的排查和思考的详细内容，更多关于Nginx转发404的资料请关注晓枫资讯其它相关文章！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

姬秋芸

感谢楼主分享。

白云映雪衷

感谢楼主，顶。