严格CSP规则下不修改配置调用localhost服务的替代方案咨询

以下方案均不需要改动现有线上站点的CSP配置，适配多站点调用本地服务的场景：

• 本地系统代理转发（最推荐，适配性最高）
  在同事的工作站上部署轻量本地代理工具（可选用Nginx、Fiddler、Whistle，或用Node.js/Python自研简单代理脚本），配置转发规则：将所有需要调用本地服务的线上站点（如mysite.com、a.com、b.com）的指定路径（如/api/verify）的请求，直接代理转发到127.0.0.1的对应服务端口。
  该方案下页面发起的请求属于同源请求，完全符合connect-src 'self'的CSP规则，不会触发任何拦截。多站点场景下仅需要在代理中新增对应站点的转发规则即可，无额外开发成本。

• 浏览器扩展代理请求
  开发极简浏览器扩展，在扩展清单中申请本地地址访问权限、目标站点的内容脚本注入权限。页面需要调用本地接口时，先通过自定义事件通知页面内注入的扩展内容脚本，由扩展后台进程发起对127.0.0.1的请求，再将结果通过事件传回页面上下文。
  扩展发起的网络请求不受当前页面CSP规则限制，不需要修改任何站点配置，仅需要同事在自用浏览器安装该扩展即可使用。

• 本地域名解析+反向代理（适合有域名管控权限的场景）
  申请公开域名（如local-service.yourdomain.com），将其DNS解析固定指向127.0.0.1，同时为本地服务配置对应HTTPS证书（可使用Let's Encrypt免费证书）。如果所有调用站点都属于同一一级域名，配置跨域资源共享规则后即可直接调用，无需修改站点CSP；如果站点跨域，可以结合本地代理方案将该域名的请求转发到本地服务端口。

• iframe跨上下文通信（有前置限制）
  如果现有站点的CSP没有限制frame-src规则，可以在页面嵌入隐藏的127.0.0.1源iframe，通过postMessage机制在父页面和iframe之间传递请求参数和响应结果，由iframe内部发起本地服务调用。该方案不需要修改connect-src规则，但要求站点允许嵌入127.0.0.1的iframe，否则会被CSP拦截。

内容的提问来源于stack exchange，提问作者Jam