乐闻世界logo
5月27日 21:34

whistle 如何解决跨域问题，有哪些常见的跨域场景？

答案

Whistle 通过 resCors 协议一行规则即可解决跨域，无需手写脚本或配置 JSON 文件。

最常用的三种写法：

shell
# 允许所有源（开发环境推荐）
api.example.com resCors://*

# 仅允许指定源
api.example.com resCors://https://www.myapp.com

# 启用 CORS 并自动回显请求中的 Origin
api.example.com resCors://enable

resCors://enable 会把响应头 Access-Control-Allow-Origin 设为请求携带的 Origin 值，适合需要携带 Cookie 的场景。resCors://* 直接设置 Access-Control-Allow-Origin: *，浏览器不会发送凭证但足够覆盖大多数调试需求。

如果需要额外控制允许的方法或头部，用 resHeaders 补充：

shell
api.example.com resCors://* resHeaders://{cors-extra.json}

另一种思路是代理到同源：通过 whistle 将前端和 API 映射到同一域名下，从根源消除跨域：

shell
my.app.com/api api.example.com
my.app.com 127.0.0.1:3000

常见跨域场景

本地调试： 前端跑在 localhost:3000，后端在 api.example.com，加一条 resCors://* 即可。

多子域名： www.example.com 访问 api.example.com，用 resCors://https://www.example.com 限定来源。

携带凭证： 需要带 Cookie 时必须指定具体源，用 resCors://enable 或 resCors://https://www.myapp.com，不能使用 *。

线上排查： 结合 SwitchyOmega 将流量导到 whistle，用 resCors://enable 临时放开，抓完即关。

追问

  • resCors 和 resHeaders 手动加 CORS 头有什么区别？ resCors 是 whistle 内置协议，会同时处理预检请求（OPTIONS）的响应；手动加头容易遗漏 Access-Control-Max-Age 等字段，导致频繁预检。
  • 生产环境能用 whistle 解决跨域吗？ 不能。whistle 是开发调试工具，生产环境应由 Nginx 或后端服务配置 CORS 策略。
  • Cookie 跨域为什么不能用 *？ 浏览器规范要求 Access-Control-Allow-Credentials: true 时 Origin 不能为 *，否则请求直接失败。
标签：Whistle