Gemi2Api-Server：把 Gemini Web 玩成 OpenAI 兼容 API

最近在折腾 LLM API 代理方案的时候，刷到了 zhiyu1998 的这个项目——Gemi2Api-Server。说实话，第一眼看到 336 Star 和 103 Fork 的时候我就知道，这东西肯定解决了不少人的痛点。

这玩意儿是干嘛的？

简单讲：它基于 HanaokaYuzu 的 Gemini-API 库，把 Google Gemini 的 Web 端会话包装成了一个兼容 OpenAI 格式的 API 服务。对，你没看错，是 Web 端——也就是用浏览器 Cookie 去调 Gemini，然后把结果转成 /v1/chat/completions 这种我们都熟悉的格式。

这意味着什么？意味着你不需要官方 API Key，也不需要付费，只要有个能登录 Gemini 的 Google 账号，就能把 Gemini 当成 API 用。

核心机制

整个项目的核心逻辑其实不复杂：

Cookie 认证：从浏览器里抓 __Secure-1PSID 和 __Secure-1PSIDTS 这两个 Cookie，作为 Gemini Web 端的认证凭据
FastAPI 服务：起一个本地服务，暴露 OpenAI 兼容端点
协议转换：把 OpenAI 格式的请求转成 Gemini Web 的调用，再把结果转回来
图片代理：Gemini 生成的图片通过 /gemini-proxy/image 端点代理访问

部署方式

项目给了三种部署方式，够用了：

Docker（推荐）

最省心的方案。克隆仓库，配好 .env，docker-compose up -d 就完事了。容器化部署，环境隔离，升级也方便。

1
2
3
4
git clone https://github.com/zhiyu1998/Gemi2Api-Server.git
cp .env.example .env
# 编辑 .env 填入 Cookie
docker-compose up -d

直接运行

用 uv 或者 pip 装依赖（fastapi、uvicorn、gemini-webapi、httpx、h2），然后 uvicorn main:app --reload --host 127.0.0.1 --port 8000 启动。适合本地开发调试。

一键部署

Render 和 HuggingFace 都支持一键部署，点几下按钮就上线了。其中 HuggingFace 版本由社区贡献者@qqrr维护。

环境变量一览

变量名	说明	默认值
`SECURE_1PSID`	Gemini Cookie（必填）	-
`SECURE_1PSIDTS`	Gemini Cookie（必填）	-
`API_KEY`	API 访问密钥（可选）	无
`TEMPORARY_CHAT`	临时对话模式，禁用部分功能	`false`
`AUTO_DELETE_CHAT`	自动删除对话记录	`true`
`PUBLIC_BASE_URL`	外部 URL，反代时必填	无

几个要注意的点：

API_KEY 不填的话，API 就是裸的，任何人都能调用。生产环境别这么干。
TEMPORARY_CHAT 开了之后会禁用思考模式、图片生成等功能，相当于砍了一半的能力换隐私。
AUTO_DELETE_CHAT 默认开启，对话结束后自动从 Gemini Web 端清除记录。但 TEMPORARY_CHAT 为 true 时，这个选项无效（因为临时对话本身就不留痕）。
PUBLIC_BASE_URL 在用 Nginx/Caddy 做反代的时候必须填，否则图片链接会指向内部地址，外面访问不到。

API 端点

端点设计很简洁，完全对标 OpenAI：

GET / — 健康检查
GET /v1/models — 模型列表
POST /v1/chat/completions — 聊天补全（核心）
GET /gemini-proxy/image — 图片代理

基本上，任何支持 OpenAI API 的客户端（比如 ChatBox、Open WebUI、各种 SDK）配个 base_url 就能直接对接。

常见坑

500 错误

十有八九是两个原因：IP 被 Google 风控了，或者 Cookie 过期了。后者更常见——__Secure-1PSIDTS 这玩意儿过期频率相当高，基本隔几天就得重新抓一次。

解决方法：隐身标签登录 Gemini，F12 打开开发者工具，Application → Cookies → gemini.google.com，把 __Secure-1PSID 和 __Secure-1PSIDTS 的值复制出来，更新到 .env 里，重启服务。

这是所有基于 Web Cookie 方案的通病，不是这个项目的问题。

图片访问不了

大概率是 PUBLIC_BASE_URL 没配或者配错了。反代场景下，Gemini 生成的图片 URL 是服务端拼接的，如果 base_url 指向的是内网地址，外面当然看不到。

图片去水印

项目还集成了基于 gemini-watermark-remover 的去水印功能，这个算是锦上添花了。实现上直接用了 journey-ad 和 allenk 两个项目的 PNG 资源文件。

我的看法

这类项目本质上是"薅 Google 羊毛"，稳定性和合规性都不如官方 API。但话说回来，对于个人开发测试、临时验证需求，这东西确实好用。尤其是 Gemini 2.5 Pro 的推理能力放在那，免费能调到还是很有诱惑力的。

不过要注意几点风险：

Cookie 随时可能失效，需要维护
Google 随时可能封堵 Web 端的调用方式
频繁调用可能触发风控

拿来做实验、写脚本、跑 benchmark 挺合适，上生产环境就算了。

致谢

项目上游依赖了 HanaokaYuzu/Gemini-API，水印去除用了 journey-ad 和 allenk 的方案。社区贡献也很活跃，136 个 commit，12 个分支，自动更新上游版本的工作流也配好了——这些细节说明维护者在认真对待这个项目。