Google Gemini 通过 SOCKS5 代理排查失败记：为什么 OpenClaw 用不了，Cherry Studio 却可以

2026 年 6 月 8 日晚到 6 月 9 日上午，我在 OpenClaw 里使用 Google Gemini 模型时遭遇长时间无回应。原以为只是“网络问题”，但一整夜排查下来才发现：真正拦住 Gemini 的不是网络，而是 OpenClaw 的 SSRF 检查。

这篇文章把那段排查过程、失败方案、以及最后为什么彻底放弃 Google 模型，完整记录一遍。

症状：Gemini 模型长时间无回应

最初表现很简单：

• 在 OpenClaw 中选择 gemini-3.5-flash 或 gemini-3.1-flash-lite
• 会话长时间没有返回，最终报 502 / Connection error
• main agent 也出现同样的连接错误

直觉告诉我这不像“模型挂了”，因为同一台机器上的 Cherry Studio 访问 Gemini 完全正常。问题一定出在 OpenClaw 的请求链路上。

第一道门：SSRF 拦截

查看 Gateway 日志后，我发现第一道拦路虎是 SSRF（Server-Side Request Forgery）安全子系统：

{"subsystem":"security"}
blocked URL fetch (url-fetch)
targetOrigin=https://generativelanguage.googleapis.com
reason=Blocked hostname or private/internal/special-use IP address

关键信息：

• 耗时仅 1ms — 这是瞬间拒绝，不是网络超时
• 涉及 security 和 provider-transport-fetch 两个子系统
• 尝试 2 次，均在同一秒内被拦截
• 最终 fallback 决定为 surface_error

这意味着：OpenClaw 在发起请求前，就先检查目标域名；发现是 Google 域名后，直接拒绝。

代理方案试错：三次失败

既然直连被 SSRF 拦住，自然想到“走代理”。但三次尝试全部失败：

第一次：在 provider 配置里设 proxy

{
  "request": {
    "proxy": "http://127.0.0.1:8118",
    "allowPrivateNetwork": true
  }
}

结果：SSRF 先于代理执行。即使配了 proxy，OpenClaw 在检查目标域名时就直接拒绝。日志明确显示 name=SsrFBlockedError，耗时 1ms。

第二次：把 HTTPS_PROXY 指向 SOCKS5 端口

HTTPS_PROXY=http://127.0.0.1:10808

结果：HTTPS_PROXY 不支持 SOCKS5 协议，curl 测试同样超时。这里有个常见误区：SOCKS5 和 HTTP 代理是两套协议，不能混用。

第三次：HTTPS_PROXY 指向 socks2http 的 8118 端口

HTTPS_PROXY=http://127.0.0.1:8118

结果：NO_PROXY 配置里 *.alibaba.com 拼写错误（应为 *.alibaba-inc.com），导致漏配。而且过程中多次遇到 Tool exec not found，排查中断。

旁路方案：socks2http.py

经过讨论，最终决定手动搭建一个本地 HTTP 代理，把请求先送到本地，再通过 SOCKS5 转发到 Google：

OpenClaw Gateway → socks2http.py (127.0.0.1:8118) → SOCKS5 (127.0.0.1:10808) → Google API

这个方案的核心逻辑是：

1. OpenClaw 的 baseUrl 改成 http://127.0.0.1:8118/v1beta/openai
2. OpenClaw 看到目标是本地回环地址，SSRF 检查放行
3. socks2http.py 收到请求后，再通过 SOCKS5 转发给真正的 Google API

socks2http.py 的本质不是“SOCKS5 转 HTTP”，而是“SSRF 旁路”——用本地代理作为跳板，欺骗 SSRF 检查。

首次打通，但仍有问题

配置完成后，curl 通过 8118 返回了 Google 官方 404 页面。这说明：

• ✅ SSRF 已被绕过
• ✅ 请求确实到达了 Google
• ✅ socks2http.py 工作正常

但实际测试时返回的是 HTTP 429：

HTTP 429: You exceeded your current quota
Quota exceeded for metric: generate_content_free_tier_requests, limit: 20

Google 免费 API 限额每天只有 20 次，额度耗尽。等额度恢复后，新的问题又出现了：即使能通，国际链路仍然间歇性超时。前一天 curl 测试成功，第二天实际使用仍然没有回应。

彻底放弃

经过一整夜的折腾，最终决定：彻底放弃在 OpenClaw 中使用 Google 模型。

原因不是“不能用”，而是“不够稳定”。对于生产环境来说，一个需要绕三层代理、链路不稳定、每天只有 20 次免费额度的模型，不值得继续投入。

清理操作

放弃后做了四步清理：

1. 停用 socks2http.py（重命名为 .bak）
2. 从 openclaw.json 删除 Google provider 配置
3. 从 fallback 链移除 google/gemini-3.5-flash 和 google/gemini-3.1-flash-lite
4. 清理 gateway.systemd.env 中的 HTTP_PROXY / HTTPS_PROXY / NO_PROXY 三行

清理后 fallback 链剩余 16 个模型，全部是国内可直连模型，不再依赖国际线路。

核心教训：Cherry Studio 能用，OpenClaw 为什么不行？

这是整个排查中最核心的认知。

Cherry Studio 的链路：

Cherry Studio → 直接 HTTPS → 系统代理 → Google API

Cherry Studio 是桌面应用，没有 SSRF 检查，想请求哪个域名都可以。系统代理开着就自动转发，没开也能直连。

OpenClaw 的链路：

OpenClaw → socks2http.py (SSRF 旁路) → SOCKS5 → 机场 → Google API

OpenClaw 有 SSRF 检查，外部域名被拦。必须搭一个本地代理作为跳板。

关键区别：

结论：Cherry Studio 能用 ≠ OpenClaw 能用。 两者架构完全不同，不能简单套用同一套网络配置。

经验总结

1. SSRF 是第一道不可逾越的门：OpenClaw 的 SSRF 检查会阻止外部不可信域名，代理方案、超时问题都是后面的问题
2. socks2http.py 的本质是 SSRF 旁路，不是 SOCKS5 转 HTTP 工具
3. SOCKS5 和 HTTP 代理协议不同：HTTPS_PROXY 不能直接指向 SOCKS5 端口
4. curl 单次测试不能代表稳定性：国际链路可能一次成功一次超时
5. 代理链路每多一跳，就多一个故障点：OpenClaw 需要绕三层，Cherry Studio 只需要一层
6. 清理要彻底：停用脚本 → 移除 provider → 移除 fallback → 清理环境变量

后续建议

• 如果将来需要再次尝试 Google 模型，优先考虑更稳定的代理方案（如机场直连而非本地 SOCKS5 转 HTTP）
• 或者直接使用国内可直连的模型替代（当前 fallback 链已有 16 个模型可选）
• 当前主模型 LongCat-2.0-Preview 和 fallback 链中的其他模型均可正常使用，无需再折腾国际线路

关联阅读

• [[代理网络配置与全球访问]]
• [[OpenClaw配置]]

参考来源

• OpenClaw 官方文档
• OpenClaw GitHub 源码

–全文完–

若你有故事想讲、有困惑想聊、或是想找个人说说心里话，甚至只是吐槽发泄一下情绪，都欢迎来找我聊聊：　　　《内容已折叠，点击展开》

希望我写的每一个字，成为我自己和某个人活下去、拼下去的力量。　　　　　　　　　　　　　　　　　　　　　《内容已折叠，点击展开》

“技术终归是工具，而我们一次次认真把问题理顺，守住的其实不只是页面样式和代码输出，还有那一点不愿被混乱打败的心气，是每一个深夜仍愿点灯前行的人。”

转载请注明来自https://oklife.me。