有用户在 Linux.do 论坛反映，使用新加坡节点访问时，网页版 Gemini 可以正常对话，但谷歌的 AI 编程工具 Antigravity 始终报错，错误信息为 HTTP 400 Bad Request FAILED_PRECONDITION: User location is not supported for the API use，即用户所在地区不支持该 API 使用。这一现象表明 Antigravity 对接入地区的校验比 Gemini 网页版更为严格。发帖人希望找到一种无需开启 TUN 模式或全局代理的解决方案，使两类服务同时正常工作。该话题引发论坛成员讨论，共产生 7 个帖子、7 位参与者。类似情况在开发者社区并不罕见：同一厂商的不同产品线往往使用不同的 API 端点和风控策略，网页版服务与桌面端 IDE 内嵌 API 调用的地区判定机制可能存在差异，导致部分用户即便节点本身可用，仍无法通过 Antigravity 的前置校验。对国内开发者而言，地区限制已成为使用海外 AI 编程工具时最常见的门槛之一，代理方式的选择（规则分流、TUN 虚拟网卡、全局模式）直接影响各项服务的可用性，也推高了普通用户的使用成本。
事件分析
从技术细节看，FAILED_PRECONDITION 属于 gRPC 标准状态码，说明请求已抵达服务端但在前置条件校验环节被拒绝，地区判定大概率发生在 API 网关侧的 IP 风控层，而非网页端的登录会话环境。Antigravity 作为桌面端智能体 IDE，后台调用的是独立的 API 端点与配额体系，其地区白名单与 Gemini 网页版并不同步；对使用规则分流的用户而言，IDE 后台请求所涉及的域名若未被代理规则覆盖，就会直连触发拦截，这正是用户被迫考虑 TUN 或全局模式的原因。产业层面，这种差异反映出谷歌对新推出的智能体编程工具采取了更谨慎的合规与灰度策略，API 能力开放节奏落后于产品宣传。后续可关注两点：谷歌是否逐步扩大 Antigravity 的支持地区列表，以及社区能否沉淀出覆盖其全部后端域名的精细化分流规则，降低部署门槛。
核心观点：同一家公司两条产品线的地区策略割裂，暴露出 AI 编程工具全球分发野心与合规风控现实之间的结构性矛盾。
原文链接：Linux.do
