本篇文章给大家带来的内容是关于nodejs中http代理库http-proxy中常见的问题分析，有一定的参考价值，有需要的朋友可以参考一下，希望对你有所帮助。
http-proxy
http-proxy是一个nodejs的http代理库，已经被webpack-dev-server集成进来，做代理使用。原因是在前后端分离大行其道的今天，我们如果需要在本地调后端api接口，不配置hostname的话，必然是一个跨域的请求。因为浏览器的跨域安全限制，调取是不通的，所以本地代理就成了一个本地开发环境的必选项。
'/saasapi/*': {
target: 'http://ebk.17u.cn',
},意思呢大概就是把saasapi开头的ajax请求重定向到http://ebk.17u.cn
本地开发没有问题，线上如果也是用nodejs的服务器，如果恰巧也配置了代理，部署到线上出现了意想不到的问题~
后端nginx配置了反向代理
一个网站主域名是17u.cn，后端如果部署了多个api服务，那这样子他的api服务可能是这样子
| 主域名 | 二级域名1 | 二级域名2 | 二级域名3 |
|---|---|---|---|
| 17u.cn | ebk.17u.cn | ebk2.17u.cn | ebk3.17u.cn |
前端同样部署了3个nodejs服务，也同样配置了3个代理。部署到线上却发现，请求总是指向第一个二级域名，其他的二级域名访问不到。
百思不得姐！
后来仔细查看http的信息，发现几个服务的ajax请求发到服务器上之后，hostname都是浏览器的域名，而nginx的反向代理配置都是根据hostname来做转发的。因为我们的hostname对于nginx来说都是陌生的，所以就默认转发到默认的第一个服务上去了。
查了http-proxy配置，哈哈，果然有这种修改的配置，只要稍微改一下就好了。
'/saasapi/*': {
target: 'http://ebk.17u.cn',
changeOrigin: true
},changeOrigin: true意思就是把hostname改为和target一致就可以了。这样后端nginx就可以正常转发了。
后端配置了cookie Path
后端api，不仅仅配置了二级域名，还配置了二级目录，前端部署的服务也一样需要二级目录。
api地址就变成这个样子：
ebk.17u.cn/saasapi
前端地址：
trans.17u.cn/saas
代理配置做对应调整
'/saas/saasapi/*': {
target: 'http://ebk.17u.cn',
changeOrigin: true,
rewrite: path => path.replace(/^\/saas\/saasapi\/cxy/, '/saasapi')
},这样子看起来很正常吧，但是问题出在哪呢？后端把登录之后设置的cookie也设置了path：Path='/saasapi'。
这样子问题就来了，trans.17u.cn/saas当前域名下读取不到/saasapi下面的cookie，导致前端登录每次都通过，但就是不能正常调api，每次调取都提示没有登录。
有问题还是先查文档。
还是发现了解决方案
cookiePathRewrite: { '/saasapi': '/saas/saasapi' }重写cookie路径就好了，同理如果后端接口指定了cookie的domain，一样有方案解决
cookieDomainRewrite
还有一些其他rewrite，应该都比较好用的。
ps：在解决过程中，发现改了也总是不能成功，一度怀疑是库的bug。后来发现需要清除掉chrome的cookie。
直接点Application -> Cookie:删除下面的cookie是不行的。清理不掉全部的cookie，需要到Application -> clear storage中，clear site data才可以。最终成功
相关推荐：
