别只盯着 sub2api 了！这些方案也能把 Gemini Pro 变成 API 接口
最近玩 AI 的朋友越来越多， Gemini Pro 既然好用，大家自然是想方设法把它接入到自己的各种应用里。很多朋友手里有的是 Google One 会员或者 Gemini Advanced 订阅，但官方 API 需要付美元、还得绑卡，这门槛就把不少人劝退了。
于是，把“网页版订阅”转换成“API 接口”的需求就出来了。大家最熟悉的可能就是 sub2api，但这玩意儿有时候维护不及时，或者配置起来不符合某些人的胃口。今天就来聊聊，除了 sub2api，我们还有哪些路子能低成本地把 Gemini Pro 变成好用 API。
一、 为什么我们需要这种转换？
说白了，就是一种套利或者桥接。
- 成本考量：官方 API 是按 Token 收费，而网页版订阅通常是套餐制（比如 Google One 附赠的 Gemini Advanced），对于高并发或者长文本需求，吃套餐往往比按量付费划算。
- 支付便捷：直接充值 Google Cloud Platform 需要海外信用卡，续也是个麻烦事；但买个兑换码或者上某宝续费订阅就容易多了。
- 统一调度：自己写的 Web 项目或者第三方客户端，大多只支持 OpenAI 格式的 API。我们需要一个中间层，把 Gemini 的私有协议“翻译”成通用的 HTTP 请求。
Cloudflare Workers 边缘网络架构示意，展示其无需服务器即可部署的优势
二、 强力替代方案：Cat's Tail (或其他衍生项目)
除了 sub2api，目前圈内比较活跃且受到好评的还有一类基于 Cloudflare Workers 或者 Vercel 部署的项目。这里不得不提一个在 GitHub 上热度很高、逻辑很清晰的项目（社区常称之为“Cat's Tail”类项目，具体仓库名可能变动，建议搜 gemini-api-free 或 gemini-pro-proxy 关键词）。
Nginx 反向代理核心配置代码示例
它的优势在于：
- 轻量化部署：直接利用 Cloudflare 的免费额度，不需要自己买 VPS，省去了维护服务器的成本。
- 兼容 OpenAI 格式：这是它的杀手锏。它能让你的 Gemini 模拟成 GPT-3.5/4 的接口，这意味着你根本不需要修改现有的客户端代码（如 NextChat、LobeChat 等），只需要把 Base URL 换一下，Key 换成你生成的 Cookie 即可。
- 高并发支持：得益于 Cloudflare 的边缘网络，响应速度通常比那种跑在廉价 VPS 上的 Python 脚本要快得多。
三、 硬核技术流：Nginx 反向代理 + Cookie 转发
如果你不想依赖别人的开源项目，或者担心 Worker 被风控，那么“手搓”一条 Nginx 反向代理链是最稳妥的。这听起来很高大上，其实就是你自己写一个简单的转发规则。
核心逻辑如下：
- 准备目标：你需要抓取 Gemini 网页版的 Cookie（主要是
__Secure-1PSID和__Secure-1PSIDCC等字段）。 - 配置 Nginx：在你的云服务器上配置一个
location，让它接收客户端发来的请求，然后带上 Cookie 转发给 Google 的官方生成接口。
location /v1beta/messages {
# 转发给 Google 的生成接口地址
proxy_pass https://generativelanguage.googleapis.com/;
# 添加关键 Header
proxy_set_header Authorization "Bearer 你的Googletoken或者通过Cookie处理";
proxy_set_header Content-Type "application/json";
# 处理跨域（可选）
add_header Access-Control-Allow-Origin *;
}
注：这只是一个示意，实际 Google 的新版接口（如 generativelanguage.googleapis.com）验证机制比较复杂，通常需要你用代码（如 Node.js 或 Python）在中间层做一个 Session 保持，而不是单纯靠 Nginx 转发 Cookie。建议配合一个轻量级的后端服务（如 Express.js）来做这个中转。
四、 值得关注的新风向：LocalAI 搭配 Adapter
如果你的主要场景是在本地或者局域网调用，比如部署了一个 Ollama 或者 LocalAI，你其实可以通过 Adapter（适配器） 的方式接入。
有些开发者编写了专门针对 Gemini 的适配器脚本，把它们放入 LocalAI 的 backend-assets 文件夹中。这种方式的好处是：
- 它把你本地的工具和云端的能力解耦了。
- 你可以在本地用 API 的形式调用，而不用关心具体的转发逻辑，因为适配器已经帮你处理好了身份验证和格式转换。
五、 避坑指南与注意事项
不管你用哪种方案，有几个坑是肯定要踩的，提前说一声：
- 验证码触发率：直接拿账号 Cookie 转发，高并发下极易触发 Google 的风控，这时候需要你手动去网页版点我是机器人。如果是为了服务生产环境，这显然是不行的，建议配合 IP 轮换或者控制请求频率。
- Cookie 有效期：网页版 Cookie 是会过期的，或者你换了 IP 登录导致 Cookie 失效。你的转换脚本必须要有自动检测错误并重试/通知的机制，不然半夜服务挂了你都不知道。
- 隐私安全：千万不要把含有你个人 Cookie 的 API Key 开放到公网上。如果必须用，务必加上一道Referer 限制或者 IP 白名单。
总结
除了 sub2api，其实世界很大。
- 如果你想省心、免费、求速度：去 GitHub 找基于 Cloudflare Workers 的 OpenAI 兼容代理项目，这是目前最优雅的“薅羊毛”姿势。
- 如果你是技术大牛、求稳定：自己写一套 Python/Node.js 脚本，配合 Nginx 反代，把控认证细节，虽然麻烦点，但胜在自主可控。
工具只是手段，把 Gemini 的能力榨干才是目的。大家还有啥好用的私有项目或者骚操作，欢迎在评论区交流！
评论已关闭