用反向代理将网页版大模型转为 API：我的实践与踩坑记录

如果你平时关注人工智能领域，大概率会刷到不少“白嫖 Gemini / ChatGPT”的教程视频。我自己也幸运地拥有一个 Gemini Pro 的学生免费一年权益，外加一年 ChatGPT Plus 订阅。但说实话，直接使用这些服务并不方便。

众所周知，国内无法直接访问 Gemini 或 ChatGPT 的网页版，必须借助科学上网工具。而对我个人而言，还有一个更实际的需求：我经常需要将同一个问题提交给多个 AI 模型，综合它们的回答。如果每次都手动切换网页端，效率实在太低。

使用官方 API 似乎是更优解——调用方便、可集成到本地工具（比如 Cherry Studio 或 RikkaHub）。但问题来了：这两家的 API 计费体系和网页版是完全分开的。即使我有付费的网页版账号，也无法直接使用 API。Google 的 API 虽然提供免费额度，但一旦用完，就必须绑定支付方式才能继续使用，这对只想轻量使用的我来说并不友好。

于是我一直有个想法：能不能把网页版的大模型“转换”成 API 接口？ 这个念头在我心里搁置了很久，直到昨天心血来潮去搜了一下，才发现——原来社区早就有人做了！

我找到了一个叫 CLI Proxy API 的开源项目（GitHub 地址：https://github.com/router-for-me/CLIProxyAPI），它正是通过反向代理的方式，将网页版的交互“包装”成标准 API，完美契合我的需求。

初次部署：顺利搞定 Gemini
我第一时间尝试在自己的服务器上部署。按照官方文档操作非常简单，几分钟就跑起来了。更惊喜的是，项目还自带 Web 可视化管理后台，界面清爽、功能直观。

我在后台登录 Google 账号后，Gemini 支持的所有模型立刻就列出来了。将其 API 接入 Cherry Studio 和 RikkaHub 后，调用一切正常——这一步简直丝滑！

遇到瓶颈：OpenAI 登录失败
但当我尝试接入 ChatGPT（准确说是 OpenAI 的模型）时，问题出现了。通过 OAuth 登录后，在回调 URL 提交阶段一直报 403 错误。反复尝试多次无果，我在百度上搜索相关解决方案，可惜没有找到适用于我场景的。

无奈之下，我转而求助 ChatGPT 本身。经过几轮对话和排查，它帮我定位到根本原因：我的服务器 IP 被 OpenAI 风控了，根本无法正常访问其服务。而我本地电脑通过代理是可以正常访问的。

于是 ChatGPT 建议我：在本地开一个代理隧道，让 CLI Proxy API 在登录时走这个隧道。我照做之后，果然成功完成了 OpenAI 账号的授权验证！

新的问题：运行时仍走原 IP
然而，刚把 API 导入 Cherry Studio，就立刻失效了。我这才意识到：隧道只在登录阶段生效，服务真正运行时仍然使用服务器的原始 IP。而这个 IP 依然被 OpenAI 拒绝。

这就陷入了一个矛盾：如果全程依赖本地代理，那我何必部署在服务器上？不如直接在本地运行 CLI Proxy API 岂不更省事？

我又问了 ChatGPT 有没有其他绕过方案，但始终没找到可行办法。唯一靠谱的解法似乎是——换一个干净的 IP。

可买一台新服务器成本太高，而且除了这个项目，我并没有其他用途，实在不划算。

灵光一现：用云应用服务替代独立服务器
第二天我仍不甘心：为什么 Gemini 能用，OpenAI 就不行？归根结底，还是 IP 被拉黑了。既然如此，有没有不用购买整台服务器就能换个 IP 的办法？

还真有！我注意到自己常用的云服务商「雨云」提供一种叫 “云应用” 的服务——可以单独部署某个应用，并选择不同地区的节点。

我立刻创建了一个 CLI Proxy API 应用，选了 日本东京 的区域。经过一番配置，服务成功启动。这次再尝试 OpenAI 登录，一次性通过！

最终验证：确实是原服务器的 IP 被 OpenAI 拒绝了。而通过云应用服务，不仅解决了 IP 问题，成本也大幅降低——我用了最低配的 0.5 核 CPU + 0.25GB 内存，运行 CLI Proxy API 完全无压力，费用远低于购入新的服务器。

小结
这次折腾让我深刻体会到：

大模型的网页版和 API 是两套体系，权益不互通；
社区工具（如 CLI Proxy API）能有效弥合这一鸿沟；
但部署时需特别注意 IP 信誉问题，尤其对 OpenAI 这类风控严格的平台；
云应用服务（Serverless 或轻量容器）可能是低成本试错的绝佳选择。
如果你也有类似需求，不妨试试这个方案。虽然过程有点曲折，但结果值得！