Gemini 用 Clash 仍然超时?一套排查与修复方法

使用 Clash 打开 Gemini 时遇到连接超时、页面空白或请求失败?本文从节点、代理模式、规则和 DNS 等环节开始排查,并给出适用于 Clash Verge Rev 与 Mihomo 的具体修复步骤。

先判断是哪一种超时

使用 Clash 打开 Gemini 时出现“连接超时”,不一定代表节点已经失效。页面空白、网页长时间转圈、输入内容后请求失败、偶尔能打开但无法生成回答,分别可能对应代理连接、规则分流、DNS 解析或长连接传输问题。先记录具体表现,再开始修改配置,避免一次改动太多导致无法定位。

最简单的判断方法是暂时把 Clash 切换到全局模式,选择一个延迟较低、近期成功率较高的节点,然后重新打开 Gemini。如果全局模式可以正常加载,而规则模式仍然超时,问题大多在规则匹配或策略组选择;如果全局模式也打不开,则优先检查节点、系统代理、TUN 和 DNS。

表现 优先怀疑环节 首个验证动作
页面完全打不开或连接超时 节点、系统代理、TUN 全局模式更换节点后重试
页面能打开,登录或资源加载失败 规则分流、DNS、浏览器缓存 检查请求是否命中代理策略
页面空白,刷新后偶尔恢复 DNS 污染、IPv6、浏览器连接复用 清理 DNS 缓存并临时关闭 IPv6
输入后一直转圈或请求失败 长连接、节点质量、协议兼容性 换节点并观察 Clash 日志
浏览器正常,桌面应用或命令行失败 仅开启系统代理,应用未遵循代理 开启 TUN 模式进行对照

先做最小化测试

测试时只保留一个 Clash 客户端,关闭其他 VPN、网络加速器和浏览器代理扩展。多个代理同时修改系统代理、路由或 DNS,会让日志中的现象相互覆盖,测试结果没有参考价值。

第一步:确认节点和代理通道

Gemini 对连接稳定性和 TLS 长连接的要求比普通网页更高。节点测速延迟低,只能说明一次短连接测试较快,并不能保证持续请求、流式输出和较大响应都稳定。因此不要只看测速排序,还要进行实际访问测试。

  1. 在 Clash Verge Rev 的“代理”页面选中一个明确可用的节点,先不要使用自动选择、负载均衡或复杂嵌套策略组。
  2. 把模式切换为“全局”,打开系统代理,完全退出浏览器后重新启动,再访问 Gemini。
  3. 先测试普通页面加载,再发送一条很短的请求,观察是否能稳定返回内容。
  4. 打开 Clash 日志,查看请求是否出现 timeoutconnection refusedhandshake failed 或连接被重置等信息。
  5. 使用同一节点测试其他需要代理的服务。如果所有服务都失败,问题在节点或本地代理;只有 Gemini 失败,继续排查规则和 DNS。

如果一个节点只能打开首页,发送请求时却超时,通常说明节点出口质量不足、传输链路丢包,或当前协议与网络环境不兼容。此时应更换同一地区的其他节点,再对比连续使用几分钟的稳定性。不要频繁在多个策略组之间自动切换,否则每次请求可能落到不同出口,登录状态和连接表现都会变得不稳定。

检查系统代理与端口

Clash 的“代理模式”和“系统代理”是两个不同开关。模式决定流量如何分流,系统代理决定浏览器是否把请求交给 Clash。常见混合端口可能是 78907897,实际端口以客户端设置页面显示的值为准。若浏览器手动配置代理,地址一般填写 127.0.0.1,端口填写 Clash 的 mixed-port。

在 Windows 上,如果系统设置里显示代理已开启,但 Clash 日志完全没有对应请求,说明浏览器可能使用了独立代理、扩展代理,或者系统代理指向了错误端口。先关闭浏览器扩展中的代理功能,恢复“使用系统代理”,然后重新启动浏览器。Clash Verge Rev 需要修改系统代理时,若弹出权限请求,应允许其完成设置。

第二步:排查规则分流和策略组

规则模式下,Gemini 相关请求可能不只包含一个域名。页面加载、静态资源、登录接口、接口请求和流式响应可能分别使用不同的主域或子域。只把一个域名加入代理规则,容易出现首页能打开、登录失败,或页面显示后发送请求超时的情况。

先在 Clash 的连接或日志页面搜索 Gemini 请求使用的域名,确认它们最终命中了哪个策略组。重点看三件事:是否命中 DIRECT,是否落入了错误的地区策略组,以及策略组当前是否真的选中了可用节点。日志中显示请求经过代理,不代表代理节点可用;还要结合连接结果和响应时间判断。

rules:
  - DOMAIN-SUFFIX,example.invalid,Gemini
  - DOMAIN-KEYWORD,gemini,Gemini
  - MATCH,PROXY

上面的配置仅用于说明规则结构,example.invalid 是保留的示例域名,不能直接当作真实目标规则。实际配置时,应使用客户端日志中观察到的目标域名,并优先采用准确的 DOMAIN-SUFFIX 规则,不要用过于宽泛的关键词规则。关键词规则可能误匹配无关站点,扩大代理范围,也可能把不该走代理的请求送入同一个策略组。

如果配置由订阅自动生成,不建议直接大段改动订阅原文。可以在 Clash Verge Rev 的覆写、扩展规则或本地配置中增加少量规则,并把它们放在订阅规则之前。修改后重新加载配置,再通过日志确认第一条命中的规则。规则列表中的 MATCH 必须放在末尾,否则后面的 Gemini 规则永远不会执行。

不要只看测速结果

策略组测速通常测试的是短时间 TCP 或 HTTP 请求,不能完全代表 Gemini 的持续连接质量。实际排查应同时观察页面加载、登录、发送请求和流式输出四个环节。

第三步:修复 DNS 与 TUN 接管

DNS 解析异常会让 Clash 连接到错误地址,表现为连接超时、证书握手失败或页面部分资源加载失败。尤其在规则模式下,如果浏览器或操作系统绕过 Clash 使用本地 DNS,域名解析结果可能与代理出口不匹配。此时节点看起来在线,目标服务仍然无法建立稳定连接。

在 mihomo 配置中,可以先使用较保守的 DNS 方案进行验证。下面的地址使用文档保留网段,仅用于展示字段结构,请根据所在网络和服务商提供的可靠解析器替换:

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "+.lan"
    - "+.local"
  default-nameserver:
    - 192.0.2.53
  nameserver:
    - https://192.0.2.53/dns-query
  proxy-server-nameserver:
    - https://192.0.2.53/dns-query
  • enable 开启 Clash DNS 模块;enhanced-mode 使用 fake-ip 时,域名规则通常更容易在连接阶段生效。
  • fake-ip-filter 用于排除局域网域名。局域网设备、路由器管理地址和部分本地服务不适合返回假地址。
  • default-nameserver 负责引导解析,通常应填写可直接访问的纯 IP,不要把 DoH URL 填入这里。
  • proxy-server-nameserver 用于解析节点服务器域名。节点域名解析失败时,这一项尤其值得检查。
  • 如果开启 fake-ip 后只有某些应用异常,可以临时切换为 redir-host 对照测试,不要同时大范围修改规则和 DNS。

用 TUN 判断是否存在应用绕过

浏览器通常遵循系统代理,但部分应用、扩展、更新程序和网络组件并不遵循。TUN 模式通过虚拟网卡接管更多系统流量,适合用来判断“请求是否根本没有进入 Clash”。mihomo 的基础示例如下:

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

Windows 开启 TUN 往往需要安装服务模式并授予管理员权限,macOS 可能需要允许网络扩展,移动端则由系统 VPN 权限负责接管。启用后重新测试 Gemini,如果问题消失,说明原先的应用流量或 DNS 查询绕过了系统代理。若 TUN 开启后所有网络都变慢或无法访问,先关闭第三方防火墙、检查虚拟网卡冲突,再确认 auto-detect-interface 选中了当前正在使用的网卡。

第四步:处理浏览器、IPv6 与缓存

浏览器自身也可能造成“Clash 已连接但页面异常”。首先检查浏览器的安全 DNS 或加密 DNS 设置。若它固定使用独立的 DoH 服务,查询可能绕过 Clash;在排查期间可暂时改为“使用系统设置”或关闭该功能,让 DNS 统一交给 Clash 验证。确认问题解决后,再根据 TUN 和 DNS 配置决定是否重新开启。

其次检查 IPv6。部分网络对 IPv6 的连通性并不完整,系统优先拿到 AAAA 记录后,浏览器会尝试通过不可用的 IPv6 路径连接,等待超时后才回落到 IPv4。可以在 Clash DNS 中临时设置 ipv6: false,同时关闭系统或浏览器的相关 IPv6 优先选项进行对照。如果关闭后恢复正常,说明应继续检查 TUN 是否完整接管 IPv6,而不是永久忽略网络配置。

缓存和旧连接也会保留错误结果。修改节点、规则或 DNS 后,完全退出浏览器,确认后台进程也已结束,再重新打开。必要时清理该站点的缓存、Cookie 和连接状态;如果只想测试网络,不必立即删除登录数据,可以先使用隐私窗口验证页面加载和请求是否恢复。

  1. 关闭浏览器内置的独立代理和加密 DNS,恢复系统代理设置。
  2. 暂时关闭 IPv6 或在 Clash DNS 中关闭 AAAA 返回,重新测试。
  3. 完全退出浏览器,再启动 Clash 并确认系统代理已经打开。
  4. 用隐私窗口发送一条简短请求,排除扩展和旧 Cookie 干扰。
  5. 如果仍然失败,回到全局模式更换节点,观察日志中是否有新的错误类型。

推荐的最短修复流程

为了避免反复试错,可以按下面的顺序执行。每完成一步都重新测试一次,记录“是否能打开页面、是否能发送请求、是否能持续返回”三个结果。

  1. 固定单节点。不要使用自动测速或负载均衡,选择一个稳定节点,切换到全局模式。
  2. 确认代理入口。开启系统代理,确认浏览器请求出现在 Clash 日志中,检查 mixed-port 是否一致。
  3. 检查规则命中。切换回规则模式,确认 Gemini 相关请求没有命中 DIRECT 或错误策略组。
  4. 统一 DNS。开启 mihomo DNS,暂时关闭 IPv6,必要时开启 TUN 和 dns-hijack
  5. 清理连接状态。完全重启浏览器,使用隐私窗口测试,再恢复正常浏览配置。
  6. 最后再调整参数。如果只有某个节点超时,更换节点或协议;不要在节点质量未确认前反复修改 fake-ip、规则集和浏览器设置。
最终结果 说明 后续处理
全局可用,规则不可用 规则或策略组判断错误 根据日志补充准确规则并检查顺序
开启 TUN 后恢复 应用或 DNS 原先绕过系统代理 保留 TUN,检查权限与虚拟网卡
关闭 IPv6 后恢复 IPv6 路径或接管不完整 检查 IPv6 路由,或暂时保持关闭
换节点后恢复 原节点出口或链路质量不足 更换节点,不必继续修改本地配置
所有节点都失败 本地网络、订阅、客户端或服务状态仍需确认 检查订阅更新、系统时间与客户端日志

常见问题

为什么能打开 Gemini 页面,却无法发送请求?

页面资源与请求接口可能使用不同域名或不同连接方式。先看 Clash 日志中发送请求的目标是否命中代理,确认没有被规则送入 DIRECT。如果命中代理仍超时,再更换节点并检查 DNS、IPv6 与长连接稳定性。

一定要开启 TUN 模式吗?

不一定。浏览器遵循系统代理且规则配置正确时,系统代理模式通常已经足够。TUN 更适合处理应用绕过系统代理、DNS 泄漏或需要接管更多协议的场景。开启 TUN 前要确认客户端权限、服务模式和虚拟网卡没有冲突。

fake-ip 会导致 Gemini 超时吗?

正常配置下不会,但 fake-ip 与错误的过滤列表、应用兼容性或 DNS 劫持冲突时可能造成异常。可以临时切换到 redir-host 对照测试;如果 redir-host 能用,应检查 fake-ip 过滤项和 TUN 的 DNS 接管,而不是盲目更换全部节点。

Clash 日志没有 Gemini 请求,应该先改什么?

先检查浏览器是否使用独立代理或扩展代理,再确认系统代理开关和端口指向 Clash。若仍没有日志,开启 TUN 做对照;这通常说明请求没有进入 Clash,而不是规则本身写错。

准备好可用的 Clash 环境

先获取适合当前平台的客户端,再按照规则、DNS 与 TUN 的顺序逐项验证。排查时保留日志和测试结果,后续更换节点或配置也更容易定位。

下载Clash