8.0
热点
AI SCORE
技术实践2026-08-19 05:55
Gemini本地成功但生产失败：IP地址在作祟
dev.to · AI#Gemini#调试#API风控
Editor brief · 编辑速览
一个真实的调试案例：Gemini图像生成在Mac上正常，但在Hetzner服务器上返回IMAGE_OTHER，最终定位到服务器IP被风控。
一个生产环境调试案例研究：Gemini 图片生成在本地方可以正常工作，但从 Hetzner 服务器发送请求时却返回 IMAGE_OTHER，而将请求路由通过 Google Cloud 后问题迎刃而解。
我花了一整天调试一个人工智能图片生成管道，它在我的 Mac 上运行完美，但在生产环境中却静默失败了。
代码相同。API Key 相同。Prompt 相同。
本地：图片生成成功
生产环境：finishReason: IMAGE_OTHER
我在开发 ThumbAPI，这是一个 REST API，能够仅凭一个标题使用 Google 的 Gemini 图片 API 自动生成缩略图和图片。
然后我注意到一个奇怪的模式。
"The Man Who Refused to Quit After 5,126 Failures"
——指的是 James Dyson 和他的 5,126 次失败原型——在我的 Mac 上能成功生成，但在生产环境中却失败了。
于是我开始排除变量。
我的第一个假设是 Gemini 的图片安全系统阻止了请求。
我更改了措辞，移除了任何可能触发与名人/人物相关的安全过滤器的内容。
ThumbAPI 会发送一个由 6 张缩略图组成的网格给 Gemini 作为风格参考。
其中一些图片包含人脸。
于是我使用 @vladmandic/face-api 构建了一个人脸检测 + 模糊管道，在将图片发送给 Gemini 之前先对人脸进行模糊处理。
我移除了整个参考网格。
只发送纯文本 prompt。
本地 → 图片生成成功
生产环境 → IMAGE_OTHER
此时，prompt 和输入图片已经不再是好的解释了。
于是我开始检查环境差异。
剩余的差异：网络来源
我的后端运行在 Hetzner 上。
我的 Mac 使用的是住宅 ISP。
当后端调用 Gemini 时，请求是从服务器的 IP 发出的——而不是用户的 IP。
于是我尝试从不同的网络运行相同的脚本。
我测试了 Hetzner 的 IPv4 和 IPv6。
模式是一致的：
住宅 IP → 正常
数据中心 IP → IMAGE_OTHER
这是网络来源可能有关的第一个强烈信号。
确认问题的测试
我想完全隔离服务器。
于是我用 Google Cloud 创建了一个小型代理，并将 Gemini 请求通过它路由。
请求通过 Google Cloud 代理发送，而不是直接从 Hetzner 发出。
立刻就成功了。
这就是突破口。
我仍然不知道 Google 在这里具体评估什么。
我找不到公开的 Google 文档明确说明 Gemini 图片生成对数据中心 IP 范围和住宅 IP 的处理方式不同。
所以我并不是声称这是官方政策。
可能是 IP 信誉、滥用预防、网络级安全基础设施，或者是 Gemini 图片生成管道的特定内容。
但这种行为是可复现的。
在调试 AI API 时，很容易只关注明显的变量：
但在这些变量之下可能还藏着另一个变量：
请求来自哪里？
我现在把这些也视为 AI 管道的一部分：
有趣的是，这最初看起来完全像一个 prompt 安全问题。
至少在我的案例中，更改 prompt 和移除图片没有解决任何问题。
更改网络来源才解决了问题。
是的，这可能意味着我将把 ThumbAPI 的人工智能部分迁移到 Google Cloud。
如果你正在使用 Gemini 或其他 AI API 开发，有些东西在本地可以工作但在生产环境中神秘失败，在花另外六个小时重写 prompt 之前，先检查一下网络来源。