作者：寒斜
说到前端代理，相信每一个做过前后端联调的同学都有遇到过。当下涉及前后端工程项目的研发，主流模式一定是前后端的分离。它让前后端的角色分工更加明确，对项目的研发质量提供了更好的保障。但同时也带来了诸多调试上的不便。
我们这里以 web 开发为例， 前后端工程分开，并且开启了各自的服务，前端的服务主要是为了方便前端开发实时观测所写代码的呈现结果，这里为了保障更加真实的工程效果，我们希望优先走真实的后台接口拿数据，但因为浏览器自身的跨域限制，前端无法直接让从浏览器发起的请求 到达后端的服务器。
这个时候就必须加入一层代理的能力，帮助我们解决跨域的问题。
解决的方法很简单，只需要在 webpack 里面配置一下代理的地址，就可以开始前后端联调之旅了。可是……多数情况下，联调的情况往往比单纯的后端给你提供一个 ip 地址要复杂。
你可能要面对这样的情景
情景 1
后端的工程一般需要对接口增加一些限制，像登录认证多数情况下是必不可少的，这时候你直接配置代理的服务地址并发起请求，往往会收到这样的提示：
情景 2
1 对多，很真实的例子。现在的项目组的研发配比一般都是一个前端对多个后端，后端同学并发开发，到跟前端联调的时候转为并行，这个时候我们可能会遇到 每个后端同学针对自己的服务都做了一个不同的服务部署，因为还没有到最终大家把代码合并，并且放到一个服务地址让前端联调的阶段，这个时候前端只能不停的切换代理。
情景 3
除了登录验证的情况，还有比较特殊的就是，我们的后端服务被隐藏到了堡垒机的后面。相当于安全验证的等级又提高了一层，像我们客户的专有云环境就是这种。这个时候普通的代理设定包括使用 host 就没有办法解决了。
你可能的解决方案
情景 1 的解决方案
绕过登录权限的法子很简单-按照正常方式登录，从接口获取cookie信息，然后用某些方式让你的本地请求带上这段cookie，让服务端识别通过即可。这时候如果测试服务端是以域名方式提供服务，你可以引入 ihosts这种 host管理工具，并且配置好本地ip 跟测试服务域名的映射，激活他就行，因为相同域名不同端口是可以共享cookie的，所以可以顺利访问到。但是，如果测试服务只提供ip访问，又设定了登录验证，这个时候就没法通过绑定host的方式实现cookie传输了，我们会想到webpack,但是非常遗憾的是 webpack 的cookie 设定比较复杂，通过搜索学习搞定这件事的时间往往会很长，而且你可能需要不停的是错最终才有可能达到成功的结果。显然，对于一个调试的小小需求来说这个代价还是有点大。
情景 2 的解决方案
设定多个代理配置，对应不同开发环境的时候进行切换，不过需要重新启动项目，还得自己写逻辑判断具体环境的差别。
情景 3 的解决方案
利用某些现有的代理工具，比如 Charles，PostMan。chrome 插件 SwitchyOmega 等，PostMan,SwitchyOmega 更适合后端模拟发起请求测试自己的接口， Charles 比较全面，可以用来抓包，也可以用来做代理调试，但是配置起来相对复杂。或者熟悉nginx 的同学可以用nginx做代理实现，但对于新手而言以上这些方式实现可调通代理的成本还是太高了。
到底怎样才能 5 分钟解决前后端联调问题？
那究竟有没有更好的即简洁，又能触达痛点的一站式解决方案呢，答案是必须有，这里给大家推荐提款 利器 - Alibaba CloudTookit vscode 插件版。插件的安装非常方便打开 vscode ，选中插件面板，搜索 “Alibaba Cloud Tookit”选中并安装即可。
接下来就用实际的例子给大家看看 CloudTookit 相关的“疗效”。
真实部署环境前段联调
很多情况下前端研发希望在更加贴近真实的环境中做联调，遇到问题的时候我们需要在类似预发这种环境中进行本地联调测试，这个时候势必会遇到较为严格的鉴权问题，比如我们现在联调某款云产品的预发环境，需要拿到 sec_token，并且需要把登录验证的 cookie 也拿到才能通过校验 ，但是我们都知道，常规的 webpack 代理对鉴权的设置并不直接友好。
接下来演示带鉴权的联调效果，预发环境 host: xx.xxx.xxx.xx mse.console.aliyun.com ，登入控制台
未配置代理前我们看看本地启动的效果：
可以看到数据不通。接下来直接用 Cloud Tookit 快速搞起来：
点击查看视频
总结下来，代理鉴权调试只要分三步：
1.登录，拿到cookie, sec_token (注意保护鉴权数据的安全性)
2.打开vscode ,选中cloud tookit proxy，创建代理配置并粘贴cookie，保存并激活该代理
3.复制代理host ，替换webpack的代理配置，启动项目即可
多环境对接联调
PTS 是阿里云一款云上专门用来做性能测试的产品，目前有新老两个版本的迭代开发需求，每个版本都分别有一个预发环境和线上环境，前端开发本身的代理跟代码耦合，管理和切换都不方便。
老版本：pre-pts.aliyun.com, pts.aliyun.com
新版本：pts.console.aliyun.com 通过不同host 切换预发和线上
因为某些特殊功能现在又增加一个 pre-s.pts.aliyun.com 新的域，也就是说同一套前端工程代码可能需要对接至少 5 个的联调环境，对于开发来讲其实还是很痛苦的，但是使用 Cloud Tookit 插件会有完全不同的体验。
根据相应的域名我们打开CloutTookit 插件进行设置,为了做效果区分我取不同账号的 cookie
proxy1 - 取完整 的pts账号 cookie 1
proxy2- 取不完全授权的账号 cookie 2
先开启用 proxy 1 指向 pre-pts.aliyun.com，这个时候 proxy 1 用的cookie 账号是主账号，数据比较全，我们把代理配置到项目里，启动项目看一下效果：
点击视频查看效果
接下来我们不重启项目的情况下，切换第二套 pre-s.pts.aliyun.com，这套用的账号没有足够权限，数据也不多，我们打开 proxy2, 然后直接浏览器执行刷新看看结果：
可以看到，非常完美的实现了联调环境的切换，中间不需要进行项目重启。
专有云环境联调
由于本地环境的限制，某些项目的功能只能到真实的环境中去验证。真实环境对安全的要求比较高，往往会采用堡垒机进行内部服务的转发，这个时候通常的代理方式就会失效，无法进行本地跟线上的联调工作，项目的推进效率大大降低。
说明：对于有堡垒机的访问本身就比较麻烦，需要先通过浏览器代理软件进行设置
然后通过浏览器访问具体服务的域名，比如 aa.bb.cc (之前还有个登录的环节)。接下来浏览器会先把请求打到指定的堡垒机代理，由堡垒机进行内部分发传达到具体的服务。本地想要联调依然是绕不开响应的验证，当我们登录好之后，取上验证的cookie, 接下来就是 CloudTookit 继续发威了。
首先登入系统：
访问正式页面获取 cookie：
打开插件进行服务地址和堡垒机地址设定：
然后保存并激活代理，将本地的代理服务地址替换项目里的代理地址：
启动项目，见证惊喜：
使用感受
疫情期间，我们做一个专有云的项目（跟公网不直接相通），遇到的就是堡垒机这种复杂场景，我们最开始没办法。登录到标准环境后页面上去点击判断问题的根源，soureMap 只能帮我们快速定位问题，没法改动后再去验证。只能线上看到问题，然后代码里改好后打包扔给后端同学重新部署，一来一回往往要 3 个多小时，可想而知这效率多么低下。业务倒逼着我们去做这样代理能力的研究。后面直接可以连到专有云环境，本地代码调试，遇到问题秒修改秒验证，效率大大的提了上去，也完美保障了项目的正常交付。
有次我们一个同学跟我讲，我们的联调环境又变了，这个该怎么办？我直接把CT甩给他分分钟就帮他搞定了。
最后
CloudtTookit 一直致力于为开发者提供高效率的开发服务，本身产品的功能是来自于广大开发者的真实需求。真心推荐大家收藏 CloudTookit 这款小插件，不管你是做普通的项目联调，或是有其他的联调需求，它都可以帮你完美解决问题。如果大家有什么好的建议或者想法都可以提给我们，对好的建议我们一定会认真考虑，我们之前也享受到很多开发者社区的服务，现在也希望尽力回馈给开发者社区。一起丰富完善整个开发者生态的基础设施。
关注「Alibaba F2E」
把握阿里巴巴前端新动向