为什么我不在 Nuxt 项目中再使用 @nuxtjs/proxy

Bug不知何起，一来来一堆。

故障起因

用户反馈网站无响应

立马查看日志

ERROR [HPM] Error occurred while proxying request

进入容器查看 tcp 连接被耗光，内存处于正常范围。

问题排查

初步通过日志和服务器排查是因为 并发数太多导致tcp链接被占用高。

但是运维那边不大肯加容器扩容。

于是开始分析一下项目。

这是一个 SSR 项目，而且由于项目初期开发人员对 SSR 的理解不太清晰，导致很多不必要的请求也放在了服务端，一个页面可能会发起多个请求。

项目使用了 @nuxtjs/proxy 模块，这个模块用于提供 api 的代理服务。

但是此时 服务端api 的请求是正常的，只是代理模块出现了异常。

初步考虑此模块存在的必要性。

解决方案

经过文档调研，此模块是为了解决部署和开发时跨域和cookie的问题。

当前请求路径为

用户请求页面 -> SSR服务端渲染页面 -> SSR服务端请求Proxy接口 -> 请求后台接口 -> 渲染组装页面。

SSR和接口之间存在一个中间层，是一个不稳定因素。

经过调研，生产移除是可行的，开发环境仍旧保留便于开发。

但是要处理下服务端渲染中axios请求存在的cookie问题。

// plugins  axios 需要设置一下 cookie
// 关键代码
 if (process.server) {
      // 用于处理在服务端请求的接口需要前端cookie的问题
      config.headers.common['Cookie'] = req?.headers?.cookie || '';
 }

修改之后请求路径为

用户请求页面 -> SSR服务端渲染页面 -> SSR服务端请求Proxy接口 -> 请求后台接口 -> 渲染组装页面

没有nodejs作为接口中间层，减少了 SSR 的不稳定性。

实际原因

Nuxt SSR Axios v0.21 内存泄漏问题排查