Gemini 无法访问或超时？Clash 排查与修复方法

前言：先判断是 Gemini 还是 Clash 出了问题

使用 Clash 访问 Gemini 时，常见现象包括网页完全打不开、页面长时间停留在加载状态、提示连接超时、登录后反复验证，或者对话页面可以打开但模型请求一直失败。很多人遇到问题后会直接更换订阅或反复点击刷新，但这并不一定有效。Gemini 的访问过程同时依赖域名解析、TLS 连接、代理节点出口、浏览器环境以及 Clash 的分流规则，其中任意一环异常，都可能表现为相似的“打不开”。

因此，排查时不要一开始就大幅修改配置。更高效的方法是先建立一个最小测试环境：确认 Clash 内核正在运行，选择一个明确可用的节点，临时使用全局模式测试，再逐步恢复规则模式、DNS 和 TUN 设置。这样可以快速判断问题来自本地客户端、配置文件、DNS，还是代理节点本身。

1先识别 Gemini 的具体故障类型

不同错误现象对应的排查方向并不相同。打开浏览器开发者工具或查看 Clash 的连接日志，可以帮助你判断请求究竟有没有进入代理。

• 网页完全无法打开：可能是系统代理没有生效、Clash 内核未启动、域名解析失败，或者当前网络直接阻断了目标域名。
• 页面加载缓慢或无限转圈：通常与节点丢包、出口拥堵、规则匹配错误或 DNS 响应延迟有关。
• 提示连接超时：如果 Clash 日志中出现 timeout、connection reset 或反复重连，优先测试其他节点，而不是先改浏览器设置。
• 能打开主页但无法发送消息：可能是 Gemini 的接口域名没有走同一个代理，或者 WebSocket、长连接被错误地分流到 DIRECT。
• 登录后反复验证或提示地区不可用：可能与出口 IP 的地区、信誉、账号区域或浏览器环境有关，单纯提高代理速度不一定能解决。

2检查 Clash 状态与代理基础设置

无论你使用的是 Clash Verge、Clash Verge Rev、Clash for Windows、ClashX 还是 Mihomo 客户端，第一步都应该确认内核和系统代理处于正常状态。客户端窗口打开并不代表内核一定已经启动，也不代表浏览器正在使用 Clash 提供的端口。

1. 确认配置已启用：进入配置页面，检查当前配置是否成功加载，订阅更新时间是否正常，代理列表中是否存在可用节点。如果配置为空、节点全部消失或更新时间失败，应先处理订阅问题。
2. 确认内核正在运行：查看客户端状态栏是否显示 Running、运行中或类似提示。Mihomo 客户端还可以观察日志是否持续监听本地端口。
3. 开启系统代理：在客户端中打开“系统代理”或“Set as system proxy”。关闭其他 VPN、代理软件和浏览器扩展，避免多个程序争抢相同端口。
4. 确认模式为 Rule 或 Global：排查期间可以临时切换到 Global 模式。如果全局模式能访问而规则模式不能访问，基本可以确定是规则或策略组问题。
5. 确认节点已选中：进入代理页面，在主要代理组中手动选择一个节点，不要一开始依赖自动选择、负载均衡或故障转移组。

3更换节点并验证出口质量

如果全局模式下 Gemini 仍然超时，节点质量就是最值得优先怀疑的因素。节点延迟低并不等于适合访问 Gemini。延迟测试通常只测量节点是否能快速响应测速地址，而 Gemini 实际访问还涉及出口 IP 信誉、目标地区、TLS 建连质量、带宽和丢包率。

建议按照这个顺序选择节点

• 优先选择稳定而不是单纯低延迟：在多个节点之间连续测试两到三次，观察是否每次都能完成页面加载和发送请求。
• 尽量保持出口地区一致：不要频繁在美国、日本、新加坡和欧洲之间切换。频繁改变登录位置可能触发额外验证，也会让故障判断变得困难。
• 避开高负载节点：如果节点名称带有倍率、拥挤、临时或晚高峰限制等标记，可能存在带宽不足和连接数过多的问题。
• 测试不同线路：同一地区的不同节点可能使用完全不同的 IP 段和上游线路。一个节点失败并不代表整个订阅都不可用。
• 谨慎使用自动测速组：url-test 测到的是指定测试网址的响应速度，不一定代表 Gemini 的实际可用性。排查阶段建议手动固定节点。

4检查规则匹配与 Gemini 域名分流

在 Rule 模式下，Clash 会按照规则从上到下匹配。只要更靠前的规则把 Gemini 相关请求送到了 DIRECT、错误的策略组或拒绝策略，后面的正确规则就不会再生效。对于“主页能开、对话不能用”的情况，尤其要关注接口域名和长连接请求。

可以在配置的 rules 列表靠前位置加入针对性的规则。策略组名称需要替换成你配置中真实存在的名称，例如 Gemini 或 PROXY：

以上规则不是所有配置都必须完整照搬。订阅服务可能已经内置了 Google、AI 或 Proxy 规则组，重复添加前应先查看当前配置。更重要的是确认策略组名称拼写正确：如果配置中没有名为 Gemini 的组，Clash 可能无法正常加载该规则。

如何确认规则真的生效？

1. 打开 Clash 的连接记录或网络日志。
2. 在浏览器重新加载 Gemini 页面，并尝试发送一条简短消息。
3. 搜索日志中的 gemini.google.com、generativelanguage.googleapis.com 等域名。
4. 确认它们匹配到预期规则，并且使用的是刚才选定的节点。

5修复 DNS、TUN 与浏览器绕过问题

当 Clash 日志显示请求已经匹配代理，但浏览器仍然超时，接下来应检查 DNS 和透明代理设置。域名解析失败、DNS 被劫持、IPv6 走直连，都会造成“看起来像节点失效”的结果。

DNS 配置排查方向

在 Mihomo 或支持 Clash DNS 的客户端中，建议开启内置 DNS，并根据网络情况选择 fake-ip 或 redir-host。如果启用 fake-ip 后某些本地应用异常，可以使用 fake-ip 过滤列表排除局域网域名，而不是直接关闭整个 DNS 模块。

这是排查思路示例，不同内核版本支持的字段可能存在差异。修改后必须重新加载配置，并清理浏览器 DNS 缓存。Windows 可以执行 ipconfig /flushdns；Chrome 等浏览器还可能维护独立的安全 DNS 缓存，需要完全退出后重新打开。

TUN 模式何时值得开启？

系统代理主要接管遵循 HTTP 或 SOCKS 代理设置的应用，而部分浏览器请求、系统服务、插件、WebSocket 或 IPv6 流量可能绕过它。开启 TUN 模式后，Clash 可以通过虚拟网卡接管更多系统流量，适合系统代理已经开启但 Gemini 仍然无法连接的情况。

• 在 Clash Verge Rev 或 Mihomo 客户端中打开 TUN，并允许系统授权。
• 排查期间优先使用规则模式，确保代理组和规则已经准备好。
• 如果开启 TUN 后网络整体中断，检查服务权限、虚拟网卡驱动、DNS 劫持设置和防火墙。
• 暂时关闭浏览器内置 VPN、代理扩展以及其他网络加速器，避免重复接管。
• 有 IPv6 网络时，确认 IPv6 流量没有绕过代理；必要时可暂时关闭 IPv6 进行对比测试。

6最终验证与问题定位清单

完成修改后，不要一次打开多个浏览器窗口或连续刷新几十次。建议先完全退出浏览器，再重启 Clash 内核，固定一个节点，按照以下顺序进行验证：

1. 确认 Clash 内核运行正常，系统代理或 TUN 已启用。
2. 确认当前配置没有报错，策略组中存在可用节点。
3. 在全局模式下测试 Gemini，记录页面是否能打开。
4. 如果全局模式成功，切回 Rule 模式并检查具体域名的规则命中情况。
5. 如果主页成功但发送失败，重点检查 API 域名、WebSocket 连接和浏览器缓存。
6. 如果所有节点都失败，测试其他国际网站，并检查订阅是否过期、流量是否用尽或服务商是否调整了线路。
7. 如果只有某个账号失败，而其他账号或无痕窗口正常，问题可能与账号区域、Cookie 或登录状态有关。

需要注意的是，Clash 只能负责网络转发和规则调度，不能保证每个代理出口都能长期访问 Gemini。节点 IP 信誉、服务地区、账号状态和 Google 的风控策略都可能发生变化。最稳妥的做法是保留多个质量不同但地区稳定的节点，建立一套可回滚的配置，并在每次修改后只验证一个变量。这样即使未来 Gemini 的域名或访问策略变化，也能更快找到新的故障点。

立即免费下载 Clash，开启流畅上网新体验 →