sub2api 里 Antigravity 账号 429 / 404 / 400 报错频发，同样的账号换个工具又正常？这个问题在 GitHub issue #5628 里已经被社区跑通了完整解法。这篇按实测验证过的组合整理——其中 429 的根治方案就是加一个环境变量（第一节），其余是配套条件，照抄就能修。
✅ 验证通过的完整组合（三件事缺一不可）
- 🔧 解决 429 → 加环境变量：
GATEWAY_ANTIGRAVITY_FORWARD_BASE_URL=daily（429 的根治方案就是它，加上即解决） - 🇺🇸 解决 400 地区报错 → 出口走美国（实测美国节点全模型通过）
- 🏷️ 解决 404 → 模型名用变体：
-high / -medium / -low / -tiered后缀（基础名直接 404）
一、429 怎么解决？——加 daily 环境变量（本方案的核心）
先把结论说死：429 的解法就是这一个环境变量。issue 里被点赞确认的原话是：「兄弟们，解决了。加环境变量 GATEWAY_ANTIGRAVITY_FORWARD_BASE_URL=daily 就可以解决」——原理是把 Antigravity 的转发端点切到 daily 通道，请求不再打到被限流的老端点上，429 随之消失。
按你的部署方式二选一：
Docker / Docker Compose 部署
# docker-compose.yml 的 service 里加环境变量
environment:
- GATEWAY_ANTIGRAVITY_FORWARD_BASE_URL=daily
# ⚠️ 必须重建容器（只 restart 不重读 compose）
docker compose up -d
# 验证真正生效（容器名按自己的改）
docker exec <容器名> env | grep GATEWAYsystemd 部署
# 编辑服务文件
vim /etc/systemd/system/sub2api.service
[Service]
...
Environment=GIN_MODE=release
Environment=SERVER_HOST=0.0.0.0
Environment=SERVER_PORT=8080
# 添加这一行
Environment=GATEWAY_ANTIGRAVITY_FORWARD_BASE_URL=daily
# 重启生效
sudo systemctl daemon-reload
sudo systemctl restart sub2api⚠️ 最常见的坑：以为加了变量就完事。compose 改动后必须
docker compose up -d重建容器，然后用docker exec env | grep GATEWAY确认变量真的进了容器——不然改了个寂寞，429 照旧。
二、出口节点：走美国
daily 端点有地区限制。实测美国节点全模型通过；如果你的代理有多个落地，给 sub2api 的出口固定到美国节点。报 400 User location is not supported 就是这一条没满足。
三、模型名必须用变体（404 的元凶）
Antigravity 上游只认变体名，基础名一律 404 Requested entity was not found：
| ❌ 错误写法（基础名） | ✅ 正确写法（变体名） |
|---|---|
gemini-3.6-flash | gemini-3.6-flash-high / -medium / -low / -tiered |
gemini-3.7-flash | gemini-3.7-flash-high / -medium / -low / -tiered |
3.6、3.7 都是这套命名体系，基础名直连上游也是 404（issue 里实测过）。如果你用的是官方版本 + 默认映射，基础名会被自动转成 medium 变体，一般不会踩坑；自己改过模型映射（基础名映射到基础名）的必踩。
四、按错误码排查（速查表）
| 错误码 | 原因 | 解法 |
|---|---|---|
404 Requested entity was not found | 模型名用了基础名 | 换变体名（high/medium/low/tiered） |
400 User location is not supported | 出口地区不支持 | 走美国节点 |
429 依旧 | daily 环境变量没真正生效 / token 旧 | 按第一节重做并 docker exec 验证变量，再重新授权 |
403 | token 无权限 | 重新 OAuth（scope 含 aicode/cloud-platform） |
五、特殊：3.7 Flash 报 "Upstream request failed"
映射方向正确（基础名 → -high 变体）但 3.7 还是报错 {"code":null,"message":"Upstream request failed"}？问题出在sub2api 版本的内置模型目录（如 0.1.176 还没有 3.7 变体）：
- 变体不只是名字不同——上游请求构造（thinking 档位等）依赖内置目录对变体的识别；目录里没有 3.7 → 请求没按变体处理 → 上游 404 → 包装成 upstream_error
- 3.6 能用就是因为目录里有 3.6 变体
解法二选一：
- 等官方更新：PR #5640 已提交（给 Antigravity 加 Gemini 3.7 Flash 全变体支持），合并后 pull 新镜像即可
- 着急就自编译：按 PR 里的 3 处改动（
constants.go/claude_types.go/account.go）改完重编镜像——issue 作者实测 4 个变体在 daily 端点全部 200 ✅
另外确认三点：账号是 AI Pro / Ultra 档位（3.7 目前只对这两个档位灰度开放）、出口美国、环境变量已生效（3.6 能用说明这条已过关）。
总结（照抄作业版）
- 解决 429：加
GATEWAY_ANTIGRAVITY_FORWARD_BASE_URL=daily→ 重建容器 →docker exec env | grep GATEWAY验证生效 - 出口固定美国节点
- 模型名用
-high/-medium/-low/-tiered变体 - 还报错 → 对照上面错误码表定位
3.7 的版本适配等 PR #5640 合并。需要已过验证的 Antigravity 账号（附赠 RT JSON）或 Gemini 开通的，看顶部卡片；排查遇阻进群：734763693。
© Ai拆解局Blue · 整理自 sub2api issue #5628 社区讨论 · 转载请注明出处：Antigravity 账号 429/404 修复指南
评论区