前端代理方案

最近看到公司的一个项目 README.md 写了开发时需要配置的代理方案,可能由于年代久远,随着新的开发同学的介入,又补充了一些内容导致并存两种代理方式,这对于后续加入的同学来说不是很友好,因此我结合之前的实践经历,快速整理了一个代理方案。

通常只要是项目在本地启动时绝大部分都会带有 8000、3000 这样的端口,而鉴于浏览器的同源策略,前端请求后端也必定会出现跨域的情况,因此这里所说的【代理】,在大部分场景下就是为了解决联调时出现的跨域情况,域名不同的问题。所以需要有一个软件来做转发的功能。

方案一

本地 Host 指向

通常我们会给一个前端项目指定一个本地访问的域名,接着在 Host 文件里写入下面这段代码

127.0.0.1 local.noxxxx.com

最后我们根据项目启动时给出的端口,在浏览器里这么访问:local.noxxxx.com:3000

其次我们需要在项目的构建工具里配置 devServer ,这里不过多赘述,像 Vite、Webpack、Rollup 都有对应的 Plugin 或者内置 API 来实现对请求的拦截转发。

优缺点

曾经我执着于该方式,优点在于不需要其他代理工具,通过构建工具提供的 devServer 转发能力就可以达到目的。但缺点也较明显,不同的构建工具体系下需要各自单独配置,好在它们之间的 API 大同小异,还算是能凑活。另一个缺点在于如果你想在浏览器里使用 HTTPS 方案的话,那么就要生成一个本地的证书,可以使用 mkcert 这个工具,但是这样反而增加了配置成本。

方案二

使用第三方代理工具:Whistle + SwitchOmega 插件

安装 Whistle npm i -g whistle 并启动 w2 start

1. 配置 Whistle 代理

浏览器打开 http://127.0.0.1:8899/#rules, 写入配置

# 写入代理配置
https://local.noxxxx.com/api/ https://test.noxxxx.com/api/
https://local.noxxxx.com http://localhost:4000
wss://local.noxxxx.com:4000/ws wss://localhost:4000/ws

2. 安装 SwitchyOmega 插件

3. 配置 SwitchyOmega 代理

新建代理 – 指向到 Whistle(实际转发使用 Whistle,因为支持 ws 等多种协议,功能更强大)

使用 auto switch 模式来进行关联上一步中新建的代理场景(无脑拦截浏览器中的匹配的某个域名)

流程简述

在 auto switch 模式下不影响系统代理,依旧可以 Google,当碰到匹配的域名时,使用单独的「情景模式」,此处为一个叫 「bi」的配置项。

「bi」配置项做了什么?将所有流量转发到 Whistle 监听的端口,也就是 8899。

所以可以理解为:SwitchOmage 简单拦截域名转发流量到 Whistle,Whistle 做实际转发:转发到端口,转发不同协议。

优缺点

配置流程同样不算便捷,也有上手成本的,尤其是引入了两个软件,但转发能力强于第一种方案,主要是 Whistle 提供了这块功能,同时我们享受到了抓包的功能,所以对于流量分析有需求的同学,这个方案还是有用武之地的。浏览器中访问也不需要带端口了,直接使用纯域名的方式,直觉上更符合线上或者测试环境的流程。至于上面说到的 HTTPS 证书,只要安装了 Whistle 证书,并在 Mac 下设置信任,就可以抓 HTTPS 的流量包了。

综上所属,这两种方案各有千秋,对于有洁癖的同学可以深挖一下第一种方案,利用好手头的现成工具来进行代理转发的配置,而第二种则忽略了项目的差异,一把梭通吃。