前端代理方案

By Noxxxx from https://www.noxxxx.com/?post_type=post&p=2456 欢迎分享与聚合，尊重版权，可以联系授权

最近看到公司的一个项目 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 的流量包了。

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