分享一个能够帮你作出艰难决定的网站，还有解决国内 Firebase 可用性问题的姿势

公司的产品，Rationale, 让 AI 帮你做利弊分析，啥事都能让他说出点利弊来，挺萌的。

这是一个 prompt programming 的产品，大致原理是使用一系列 prompt 模版和机器翻译，最终定向地让 text-davinci-003 生成反馈。

https://rationale.jina.ai

https://rationale.jinaai.cn

然而这并不是本帖的重点，重点是这是一个 Firebase 应用。 Firebase 在国内是和谷歌连坐封掉的，但我看网上中英文都没法搜到解决国内 Firebase 可用性问题的资料，所以这里分享一下。这次老夫踩坑的主要是浏览器，所以这里只谈浏览器。

大致包括以下几个要点，

源站地址需要既能访问 Google ，又能被国内访问
Service Worker 请求劫持
Nginx 反向代理
同域登录验证

Service Worker 是这个方案的基础，使用 SW 可以劫持页面上的所有请求，所以只要把谷歌的请求截取并通过代理访问，页面内就好像和谷歌直接通信一样，并且这种效果是跨标签页的。

既然是通过代理访问，那么必然需要一台代理服务器，并且因为客户端是浏览器，全程需要在 http 和域内完成。经过老夫的踩坑，发现 Nginx 是可用的，原本想使用 Node.js ，然而 FireStore 死活返回 400 ，即便 node.js 内使用 http2 连接上游也是一样，据我推测可能需要代理两侧都使用 http2 。

具体来讲，nginx 配置中 proxy_pass 给某个请求头的值，并删掉这个请求头，形成一个有通用性的代理，SW 中截取谷歌的请求，将原域名设置到请求头里，访问代理的域名。同时再搞定代理这个域名自己的 CORS 跨域，随手加上一个 Referrer 检查防止滥用。

另外还需要解决登录时的跳转问题。Firebase 的默认 authDomain 一般是 [app-id].firebaseapp.com, 这会跳出应用自己的域外，SW 代理会失去效果。所以需要把 authDomain 设成相同域。具体操作上把 /__/auth/ 反代到 [app-id].firebaseapp.com，这也是官方文档中提到并且推荐的方式。

至此在域内解决了 Google 服务的可访问性问题。目前就走出这一条可行的路，如果有其他姿势也欢迎交流。

值得注意的是，这个 SW 代理是项目无关的，理论上讲可以放在任何网站内解决域内任何被封服务的可用性问题。推广一下，服务的区域限制也可以用这种方式绕过甚至做区域的自由切换。

最后，因为是基于 SW 的代理，所以不支持 SW 的环境是没有这种效果的。iOS 上包括微信和 Chrome 在内，除 Safari 之外的任何网页，都在此列。安卓上的体验是可以的，微信内也有 SW 。