在浏览器中打开 Gemini 时，最让人困惑的情况往往不是完全打不开，而是页面转圈、对话提交后一直等待，或者偶尔能加载、刷新后又超时。很多用户看到这类现象，第一反应是重新安装 Clash、反复刷新浏览器，甚至马上更换订阅。实际上，Gemini 在 Clash 下无法访问，通常涉及节点质量、代理模式、规则命中、DNS 解析和浏览器缓存等多个环节。只要按照由易到难的顺序逐项确认，就能较快判断到底是出口线路不稳定，还是本地配置没有让 Gemini 请求真正进入代理。
本文默认你已经在电脑上安装了 Clash Verge Rev、Mihomo Party 或其他兼容 Clash 配置的客户端，并且手里有一份可以正常使用的订阅配置。排查过程中不建议同时修改多个选项，否则即使问题暂时消失，也很难知道究竟是哪一步生效。更稳妥的做法是先记录当前节点、模式和 DNS 状态，再一次只改一个变量。需要注意的是，请遵守所在国家或地区的法律法规、服务条款及所在组织的网络政策；本文仅讨论代理客户端的网络诊断和配置思路。
先判断症状：打不开、超时与账号错误不是一回事
“Gemini 用不了”包含几种完全不同的故障。若浏览器显示 ERR_CONNECTION_TIMED_OUT、连接被重置、TLS 握手失败，或者页面长时间停留在加载动画，优先怀疑代理链路、DNS 或节点质量。若页面可以打开，但发送消息后返回 403、地区不可用或账号验证提示，则可能与账号区域、服务政策、登录状态或浏览器 Cookie 有关，单纯换 Clash 节点不一定能解决。若只是在生成长答案时中断，则还要考虑节点带宽、WebSocket 或长连接稳定性。
- 页面完全打不开：先看 Clash 是否运行、系统代理是否开启，以及浏览器请求是否出现在连接日志中。
- 页面能开但发送超时：重点检查 Gemini API、流式连接和当前节点的持续稳定性。
- 偶尔成功、偶尔失败：常见原因是策略组自动选择了负载过高或出口不稳定的节点。
- 只有一个浏览器失败：检查扩展、代理设置、缓存、Cookie 和浏览器自身的安全策略。
- 浏览器正常、桌面应用或脚本失败：说明不同进程可能没有使用同一套系统代理或环境变量。
排查时可以打开 Clash 的连接面板，在 Gemini 页面刷新一次，然后搜索 gemini.google.com、accounts.google.com、googleapis.com 或相关 Google 主机名。如果完全看不到新连接，问题可能发生在浏览器代理没有生效、DNS 被其他软件接管，或者请求使用了 QUIC 等 Clash 当前没有接管的协议。如果能看到连接，但策略显示为 DIRECT，则不要急着换节点，应先处理规则分流。
先换节点测试：确认是不是出口线路的问题
节点质量是最常见、也最容易被忽略的因素。Gemini 页面能否打开，不只取决于节点的延迟，还取决于节点到 Google 服务的跨境链路、TLS 握手成功率、持续带宽和对长连接的支持情况。有些节点测速时延迟很低，但访问 Gemini 时会在登录跳转或提交消息阶段卡住；也有些节点网页加载很快，却无法稳定维持较长的生成连接。因此，不能只看客户端里显示的延迟数字。
在 Clash 的策略组中，先从自动选择切换到一个明确的节点，建议优先测试地理位置不同、线路类型不同的两到三个节点。每次切换后完全关闭 Gemini 标签页，再新建标签页访问，避免旧连接继续复用。可以分别记录以下结果：主页是否打开、登录跳转是否完成、普通短问题是否能返回、较长回答是否会中断。若某个节点四项都稳定，而自动选择组经常失败，说明健康检查指标可能只检测了基础 URL，并没有反映 Gemini 的真实可用性。
如果所有节点都表现相同，则不要继续无规律地更换节点，而应回到规则、DNS 或客户端模式检查。相反，如果只有某一地区的节点失败，其他地区可以正常使用，那么问题更可能是该出口的 IP 信誉、线路拥塞或区域调度。节点切换后建议观察几分钟，不要只凭首次打开速度下结论；Gemini 的登录页、静态资源和对话接口可能分别连接到不同的 Google 主机。
怎样判断节点是“快”还是“稳”
稳定性可以从三个维度观察。第一是连接建立时间：页面是否在几秒内完成 TLS 握手。第二是持续传输：回答生成过程中是否频繁停顿、重连或突然回到首页。第三是重复成功率：连续发送几次短消息后，是否每次都能正常返回。若节点只在首次访问时表现良好，随后频繁超时，往往是带宽、并发限制或出口线路不适合长连接，而不是 Gemini 页面本身损坏。
检查 Clash 模式与规则：不要让 Gemini 被误判为直连
Clash 常见的运行模式包括 Rule、Global 和 Direct。其中 Direct 会让流量直接连接，适合本地网络或明确不需要代理的站点；Global 会把大多数流量交给选定的代理组，适合快速验证是否为规则问题；Rule 则按照配置文件中的规则顺序决定策略，是日常使用最推荐的方式，但也最容易因为规则集过旧或顺序不正确而出现误判。
排查时可以短暂切换到 Global 模式，并选择一个已知稳定的节点，然后重新访问 Gemini。如果 Global 下可以打开，而 Rule 下失败，基本可以确认是规则分流问题。此时不必长期使用全局模式，因为它会让国内网站、局域网服务、公司内网和不需要代理的流量也绕路。更合理的做法是在自定义规则或配置覆写中，把 Gemini 相关域名放到较靠前的位置，指向稳定的代理策略组。
常见的排查条目包括 gemini.google.com、DOMAIN-SUFFIX,googleapis.com、accounts.google.com 以及登录过程中实际出现的 Google 鉴权主机。不要机械地把所有 Google 域名都加入代理，也不要只添加主页域名就认为配置完成。最准确的方式是打开连接日志，观察访问、登录和发送消息时实际出现了哪些主机，再针对必要的域名补规则。
# Example rules; place them before broad DIRECT rules
- DOMAIN,gemini.google.com,PROXY
- DOMAIN-SUFFIX,googleapis.com,PROXY
- DOMAIN,accounts.google.com,PROXY
上面的 PROXY 只是示例策略组名称，实际配置中可能叫“代理”“节点选择”或其他名称。若你的订阅使用了远程规则集，手写规则必须放在能够覆盖远程规则的位置，否则后面的规则可能重新把请求改为 DIRECT。修改后记得重新加载配置，并在连接面板确认最终策略确实发生变化。若面板显示命中了代理，但 Gemini 仍然超时，再进入 DNS 和节点稳定性排查，不要继续堆叠重复规则。
处理 DNS、浏览器与 QUIC：解决“看似代理、实际绕路”
DNS 配置不正确时，Gemini 可能出现页面加载缓慢、证书异常、不同请求走向不一致等问题。尤其是在系统使用运营商 DNS、浏览器启用了独立的安全 DNS，或网络中存在另一个 VPN 客户端时，域名解析路径可能与 Clash 的代理路径分离。结果是浏览器拿到一个不可达或质量较差的地址，Clash 日志里却看不到符合预期的域名连接。
在 Clash 的 DNS 设置中，首先确认当前配置没有明显冲突，例如同一时间启用了多个 DNS 接管组件，或者 fake-ip、redir-host 与其他网络工具的模式互相覆盖。若使用 fake-ip，检查局域网地址、系统保留域名和需要真实 IP 的服务是否加入例外；若使用 redir-host，则要确认 DNS 请求没有被浏览器或系统直接发往本地解析器。不要因为某个公共 DNS 在测速中排名靠前就盲目替换，重点是让解析结果、代理策略和 TLS 的目标主机保持一致。
浏览器方面，可以暂时关闭第三方代理扩展、独立 VPN 扩展和“安全 DNS”选项，再使用无痕窗口测试。扩展可能覆盖系统代理，甚至只代理网页请求而不代理 WebSocket；独立 VPN 则可能与 Clash 同时修改路由表，造成请求随机选择不同出口。清除 Gemini 相关站点的 Cookie 和缓存也有帮助，但应放在确认网络路径之后，因为缓存无法修复一个被错误分流的连接。
部分浏览器会优先使用 QUIC 或 HTTP/3。若当前 Clash 客户端或网络环境对 UDP 代理支持不完整，Gemini 可能表现为网页偶尔能开、资源加载失败或连接频繁重建。可以暂时关闭浏览器的 QUIC 实验选项，或者在 Clash 中确认 TUN、UDP 转发和相关内核能力均正常，再进行对比测试。这个步骤只用于定位问题，不建议在不了解影响的情况下长期修改浏览器底层实验参数。
Rule 不够时再启用 TUN：处理系统代理覆盖不到的请求
系统代理主要影响遵循系统代理设置的应用，但并不是每个浏览器进程、桌面客户端或后台服务都会完整遵循它。某些程序会直接建立 TCP 连接，某些程序使用自带 DNS，另一些程序则通过 UDP 或 QUIC 访问网络。此时，即使 Clash 的系统代理开关已经打开，Gemini 相关请求仍可能绕过规则，表现为浏览器正常而桌面应用失败，或者同一台电脑上的不同浏览器结果不一致。
TUN 模式通过虚拟网卡在更低的网络层接管流量，适合需要覆盖更多进程、应用不读取系统代理，或 DNS 与路由经常分裂的场景。开启前应先关闭其他 VPN、网络加速器和旧版代理客户端，避免多个虚拟网卡争夺默认路由。还要检查 Clash 是否获得系统要求的网络扩展权限，并确认 TUN 的 DNS 设置与当前配置匹配。开启后，重新查看连接面板；如果 Gemini 的请求终于出现，说明此前确实存在系统代理覆盖不足的问题。
TUN 并不是万能修复方案。它可能影响局域网打印机、公司内网、虚拟机、Docker 网络和游戏连接，也可能因为规则范围过大而让所有流量都经过代理。建议先使用 Rule 模式加正确的浏览器代理完成定位，只有在确认某个程序无法遵循系统代理时，再启用 TUN。启用后若出现新问题，应先测试局域网、内网域名和本地开发服务，必要时把私有网段、回环地址及公司域名加入直连或排除列表。
按固定流程复测：避免“改好了但不知道为什么”
完成修改后，建议按照固定顺序复测，而不是立刻打开多个页面同时判断。第一步，退出 Gemini 标签页并重新启动浏览器；第二步，确认 Clash 当前模式、策略组和节点名称；第三步，在连接面板清空旧记录；第四步，依次访问主页、完成登录、发送短消息，再测试较长回答。每一步都记录最终策略是代理还是直连，以及连接是否在 TLS 阶段失败。
如果主页失败，优先回到节点、规则和 DNS；如果主页成功但登录失败，检查鉴权域名是否被单独分流；如果登录成功但发送消息失败，关注 API 相关主机、长连接和节点持续带宽；如果只有长回答中断，则降低并发、换更稳定的节点，并观察是否为服务端限流或临时错误。遇到 401、403、配额不足或地区限制时，不要把它们当作网络超时处理，应按账号和服务状态方向核对。
为了方便以后定位，可以保留一份简化记录：使用的 Clash 客户端和内核版本、配置模式、测试节点、连接日志中的主机名、最终策略以及浏览器环境。下次订阅更新后若 Gemini 再次异常，就能快速比较是规则集改变、节点更换还是 DNS 行为发生变化。对于经常使用 Gemini 的开发者，还可以准备一个专用的 Gemini 代理策略组，避免自动选择组在高峰时段频繁切换节点导致登录状态或长连接被打断。
与一些只提供单一全局开关的代理工具相比，Clash 的优势在于可以通过连接日志看到 Gemini 请求究竟命中了哪个域名、哪条规则和哪个节点；它也能在 Rule、Global 与 TUN 之间按场景切换，既保留国内站点的直连效率，又能针对 Google 鉴权、API 和长连接进行精细分流。若你正在寻找一种能够把“节点不稳、规则误判、DNS 绕路和应用不认代理”分开处理的方案，Clash 的可观测性与策略控制会比反复重装或盲目换节点更实用。