网络编程 
首页 > 网络编程 > 浏览文章

解决VueCil代理本地proxytable无效报错404的问题

(编辑:jimmy 日期: 2024/12/28 浏览:3 次 )

前言

因为项目中遇到了这个bug:Vue cil2中配置代理proxytable成功,却无效报错404,在后端和代理都配置无误的情况下,还是报404,先已解决,特记录,希望能帮助到他人;

正文

1. 为什么要使用代理?

代理的作用是:把请求代理转发到其他服务器的中间件;

例如:我们当前主机为http://localhost:8080/,现在我们有一个需求,如果我们请求/api,我们不希望由3000来处理这个请求,而希望由另一台服务器https://www.example.org/api来处理这个请求怎么办?

这时候就要使用代理来解决!

2. 在vue中如何使用多个代理?

module.exports = {
dev: {
 proxyTable: {
  // 第一个代理
  '/api-test': { 
  target: 'https://www.example.org:', /// 目标服务器 host
  ws:true, //是否启用websocket
  secure: true, // 如果是https接口,需要配置这个参数
  changeOrigin: true, // // 默认false,是否需要改变原始主机头为目标URL,是否跨域
  pathRewrite: {
   '^/api-test/old': '/api-test/new' // 重写请求,比如我们源访问的是api-test/old,那么请求会被解析为/api-test/new
  },
  //第二个代理
  '/api-else': { 
  target: 'https://197.32.22.33:8090', 
  ws:true, //是否启用websocket
  secure: true, 
  changeOrigin: true, 
  pathRewrite: {
   '^/api-else': '' //默认写法,如果不写pathRewrite就是默认为空;
  },
  //第三个代理
  '/api-three': { 
  target: 'https://197.32.22.33:9090', 
  changeOrigin: true, 
  pathRewrite: {
   '^/api-three': '/api-three' //重写请求,这样本地请求不会有两次/api-three
  },
  }
 },

上述代码即可在vue-cil项目中配置代理;

代理的参数有很多,详细可以查看:http-proxy-middleware中的Options,自行添加;

那下面我们来解析一下为什么会:Vue代理本地proxytable成功,却无效报错404的几种情况

3. bug 原因分析

1.在浏览器或postman中测试接口是否正常访问;(最重要!!不然改半天都没用)

那怎么才是成功的访问呢?

例如:拿第二个代理举例:你要访问的接口为https://197.32.22.33:8090/api-else/getsomething.json,在浏览器直接输入有返回值并测试无误后再进行下一步;

2.要确保书写方式完全正确!

2.1(参考写法2) 这时候你本地去请求的接口地址会变成:http://localhost:8080/api-else/api-else/getsomething.json才是正常的!

是不是会好奇为什么会有两个/api-else,因为在本地:http://localhost:8080/api-else相当于:https://197.32.22.33:8090,这才是正常的!

2.2 (参考写法3)

在按上述写法还是有误的情况下,可以参考写法3的路由去更改测试。例:你要访问的接口为https://197.32.22.33:9090/api-three/getThreething.json,本地配置后:http://localhost:8080/api-three/getThreething.json。

多说一句,为什么要提第三种写法?

这种适用于前后端分离多后台项目,后台项目的包名为:api-three,使用第2中写法,在打包之后部署生产环境会出现请求的问题(我们自己项目踩过的坑,偶发),所以之后规定代理和后台包名统一,并且不能直接写在请求中,而是在配置代理后,重写代理的请求,指向包名;

3.请修改完config的index.js后,答应我一定重启下项目npm run dev;

4.也是我这次bug的原因(正经脸,这个超级细微!)

在配置多个代理的情况下,代理名称不能相同,也不能出现重叠的情况!

错误示范(第二个代理失效):

 proxyTable: {
  // 第一个代理
  '/api-test': { 
  target: 'https://www.example.org:', /// 目标服务器 host
  },
  //第二个代理
  '/api-testAAA': { 
  target: 'https://197.32.22.33:8090', 
}

这的错误真的很难发现,在查了源码才看懂的;

这里说一下,为什么这样写会404!

vue的代理是基于 http-proxy-middleware实现的,而http-proxy-middleware对走哪个代理名称的的方法如下:

function matchSingleStringPath(context, uri) {
 const pathname = getUrlPathName(uri);
 return pathname.indexOf(context) === 0;
}

是的!他用的是indexOf() === 0来判断的!!!所以如果你的多个代理重叠/api-testAAA和/api-test这样出现的话,他们是都会返回true的!

但是/api-test更快判断完,所以/api-testAAA就失效了!!!

结语

说明:Vue cil的版本号是2,老版本的项目了;之后会记录下新版本vue cil 3+学习过程;

好了,吐槽完了,希望大家都不要踩坑~

补充知识:关于Vue的生产环境proxyTable代理问题

1、通过在 config/index.js 配置文件中找到proxyTable配置项

dev: {
 // Paths
 assetsSubDirectory: 'static',
 assetsPublicPath: '/',
 proxyTable: {
  '/api': { //3
  target: 'http://xxx:8080',
  changeOrigin: true,
// secure:false 代理https必须要加
  pathRewrite: {
   // 1 '^/api': '/api' 这种接口配置出来  http://xxx:8080/api/getlist
   // 2 ^/api': '/' 这种接口配置出来  http://xxx:8080/getlist
  }
  }
 }
 }

2、上面代码里的1和2的区别

当你接口有api的时候就需要^api的意思就是有api会首先使用api,防止被系统认为3处的api,如果接口中没有api则不需要,即可以省略,总结:

接口以“/api”开头的配置 数字1 ,没有则不需要

3、如果配置多个代理

dev: {
 // Paths
 assetsSubDirectory: 'static',
 assetsPublicPath: '/',
 proxyTable: {
  '/api': { //3
  target: 'http://xxx:8080',
  changeOrigin: true,
  pathRewrite: {
   // A '^/api': '/api' 这种接口配置出来  http://xxx:8080/api/getlist
   // ^/api': '/' 这种接口配置出来  http://xxx:8080/getlist
  }
  },
 '/api/1': { //
  target: 'http://xxx:8081',
  changeOrigin: true,
  pathRewrite: {
   // A '^/api/1': '/api/1' 这种接口配置出来  http://xxx:8081/api/1/getlist
   // ^/api/1': '/' 这种接口配置出来  http://xxx:80801/getlist
  }
  }
 
 }
 }

上面的调用接口的时候:

A /api/1/getlist 即可 http://xxx:8081/api/1/getlist

/api/getlist 即可 http://xxx:8080/api/getlist

第二种情况

/api/1/getlist 即可 http://xxx:8081/getlist

/api/getlist 即可 http://xxx:8080/getlist

以上这篇解决VueCil代理本地proxytable无效报错404的问题就是小编分享给大家的全部内容了,希望能给大家一个参考,也希望大家多多支持。

上一篇:Nodejs + sequelize 实现增删改查操作
下一篇:Nuxt 项目性能优化调研分析
一句话新闻
微软与英特尔等合作伙伴联合定义“AI PC”:键盘需配有Copilot物理按键
几个月来,英特尔、微软、AMD和其它厂商都在共同推动“AI PC”的想法,朝着更多的AI功能迈进。在近日,英特尔在台北举行的开发者活动中,也宣布了关于AI PC加速计划、新的PC开发者计划和独立硬件供应商计划。
在此次发布会上,英特尔还发布了全新的全新的酷睿Ultra Meteor Lake NUC开发套件,以及联合微软等合作伙伴联合定义“AI PC”的定义标准。
友情链接:杰晶网络 DDR爱好者之家 南强小屋 黑松山资源网 白云城资源网 站点导航 SiteMap