想体验 Google AI Studio，却遇到页面打不开、Google 账号登录异常、工作区一直加载，或模型请求频繁超时？这类问题不一定来自账号本身，很多时候是浏览器访问链路、DNS 解析、Clash 分流规则与登录鉴权请求没有保持一致。尤其是在国内网络环境中，Google AI Studio 的主页面、账号登录、项目管理和模型请求可能分别访问不同的 Google 域名，只代理其中一部分，最终就会出现「首页能打开、模型不能用」或「能登录、运行按钮一直转圈」的情况。本文以 Clash Verge Rev 为例，说明如何选择客户端、导入订阅、开启代理、检查规则命中，并根据实际连接日志逐步完成 Google AI Studio 的访问配置。

本文讨论的是客户端配置与网络排障，不提供绕过平台限制、批量注册账号或规避服务条款的方法。使用 Google AI Studio 前，请确认你的账号、模型服务和所在地区符合 Google 的使用政策，也要遵守所在地法律法规。配置过程中不要把 API Key、OAuth 凭据或浏览器 Cookie 粘贴到不可信的调试网站；如果使用公共电脑，完成测试后还应及时退出账号并清理本地凭据。

Google AI Studio 访问链路：为什么只打开主页还不够

Google AI Studio 是一个面向开发者的浏览器端 AI 实验与 API 调试平台。用户通常会在网页中登录 Google 账号，进入工作区后选择模型、填写提示词、调整生成参数，再运行请求并查看结果。如果只是访问首页，浏览器可能只完成了静态页面加载；真正进入工作区后，还会继续发起账号鉴权、配置读取、项目状态同步、模型请求以及流式响应等多组 HTTPS 连接。因此，首页能显示并不能证明整条链路已经可用。

从 Clash 的角度看，排查时应关注实际出现的主机名，而不是凭印象只添加一个域名。常见请求可能涉及 aistudio.google.com、ai.google.dev、accounts.google.com、accounts.googleusercontent.com、www.googleapis.com、generativelanguage.googleapis.com 以及 Google 静态资源相关域名。不同账号状态、浏览器版本和页面功能可能触发不同请求，域名集合也会随平台更新而变化。

这里有一个很容易被忽略的细节：登录页面与 AI Studio 工作区必须使用相对一致的出口。如果登录跳转走了代理，回到工作区后某些 API 请求却被规则判定为 DIRECT，浏览器可能表现为反复跳转、权限校验失败或页面空白。反过来，如果静态资源走代理而账号鉴权被错误拦截，也可能只看到一个没有完整按钮的半加载页面。遇到异常时，应优先查看 Clash 连接面板中的域名和策略，而不是马上清除所有浏览器数据。

客户端与订阅准备：先让 Clash 本身稳定工作

Windows 和 macOS 用户可以优先考虑 Clash Verge Rev 或其他基于 Mihomo 内核的图形客户端；如果你已经在使用 Clash Verge、Mihomo Party 或系统中已有稳定的 Clash 客户端，也不必为了 Google AI Studio 重新安装多个软件。真正重要的是客户端能够正常加载配置，能够显示策略组与连接日志，并且支持系统代理或 TUN 等你需要的工作模式。

打开客户端后，先进入配置或订阅页面，使用服务提供方给出的订阅链接导入配置。导入完成后检查以下几项：

  • 配置状态正常：YAML 配置能够成功解析，没有缩进错误、字段错误或代理组缺失。
  • 节点可以测速：至少有一组节点能够完成延迟测试；延迟数字不是绝对标准，但全部超时通常说明订阅、网络或节点本身存在问题。
  • 策略组可切换：Google AI 相关请求应有明确的代理策略组，不要只留下一个无法确认实际出口的自动选择组。
  • 混合端口已确认：记下客户端显示的 mixed-port，例如 7890，后续浏览器、命令行或脚本测试可能会用到。
  • 配置更新时间可靠：如果订阅长期不更新、节点已经失效，继续调整规则也无法改善实际连接。

导入订阅后不要马上开启全局模式并进行复杂测试。更建议先选择一个延迟与稳定性都较好的节点，在 Clash 中打开系统代理，再用浏览器访问普通的 HTTPS 网站确认代理开关确实生效。系统代理只影响遵循系统设置的应用；如果你在 VS Code、终端或其他独立运行时中调用 Google API，还需要额外确认这些进程是否读取了代理环境变量。

配置建议：第一次排障时只保留一个正在运行的代理客户端。若 Clash、其他 VPN、浏览器代理扩展同时修改系统代理，连接日志和实际出口可能互相矛盾，容易把「规则问题」误判成「节点问题」。

导入后怎么选模式：规则分流优先，TUN 用于补漏

Google AI Studio 的日常浏览通常优先使用规则模式。规则模式可以让国内网站、企业内网和本地服务保持直连，只把 Google 账号、AI Studio 与模型请求送进代理策略组。这样做的好处是路径更容易观察，也不会让所有软件流量都经过同一节点。选择规则模式后，应在 Clash 的策略组中指定一个稳定节点，避免自动选择频繁切换出口导致账号会话被重新验证。

如果你的配置文件已经包含 Google、Google AI 或开发者服务相关规则，可以先观察连接日志是否命中预期策略。若没有覆盖，可以在配置的自定义规则或覆写区域中补充规则。不同客户端的覆写入口名称可能不同，规则格式也取决于内核版本，下面只展示常见思路，策略组名称请替换成你自己的名称：

rules:
  - DOMAIN-SUFFIX,aistudio.google.com,PROXY
  - DOMAIN-SUFFIX,ai.google.dev,PROXY
  - DOMAIN-SUFFIX,accounts.google.com,PROXY
  - DOMAIN-SUFFIX,googleusercontent.com,PROXY
  - DOMAIN-SUFFIX,googleapis.com,PROXY
  - MATCH,DIRECT

不要机械地把所有 Google 域名都写成代理，也不要在没有检查原配置的情况下直接复制整段规则。过宽的规则可能影响 Google Drive、企业账号、学校系统或内部服务；过窄的规则则会留下鉴权和 API 请求的漏网域名。更稳妥的做法是先打开 AI Studio，再根据连接面板里实际出现的主机名逐条补充。规则顺序同样重要：自定义规则必须位于过宽的 GEOIP,CN,DIRECT、通用 Google 直连规则或最终 MATCH 规则之前。

TUN 模式适合浏览器代理设置不生效、某些应用不读取系统代理，或你需要让更多网络进程统一经过 Mihomo 的情况。开启 TUN 后，客户端会通过虚拟网卡接管更底层的流量，通常不需要单独给每个程序设置 HTTP 代理。但 TUN 也更容易与系统 VPN、企业安全软件、虚拟机网卡和 Docker 网络发生冲突。建议先用规则模式完成验证，只有确认浏览器或相关程序确实绕过了系统代理时，再启用 TUN，并逐项检查 DNS、网卡权限和路由表。

浏览器登录与 DNS：处理打不开、循环跳转和空白页

Google AI Studio 的登录问题经常被误认为是 Clash 节点不稳定，实际上浏览器缓存、第三方 Cookie、账号安全校验和 DNS 解析都可能参与其中。首次测试时建议使用一个干净的浏览器配置文件或无痕窗口，但要注意无痕模式并不等于完全没有限制；部分浏览器会默认阻止第三方 Cookie，导致 Google 登录完成后无法把会话正确交还给 AI Studio。

如果页面不断跳回登录页，先检查浏览器是否允许 Google 相关站点保存必要的登录状态，再确认系统时间准确。系统时间偏差较大时，HTTPS 证书校验和登录令牌有效期判断都可能异常。若你使用了多个 Google 账号，也可以先退出其他账号，仅用目标账号重新测试，以排除账号切换时的会话冲突。不要连续快速刷新或反复登录，短时间内大量失败操作可能触发额外的安全验证。

DNS 也会影响规则命中。浏览器通过本地 DNS 解析出结果后，Clash 可能只能看到 IP，无法按照域名规则进行准确分流；在 fake-ip、redir-host 或增强模式之间切换时，表现也可能不同。你可以在 Clash 的 DNS 设置中选择与当前配置兼容的模式，并在连接日志里确认是否能看到完整域名。若改完 DNS 后出现所有网站都变慢、局域网设备无法访问，先恢复原设置，再逐步调整，不要一次修改多个开关。

对于浏览器缓存导致的旧页面，可以只清理 Google AI Studio 和 Google 登录相关站点的数据，而不是删除整个浏览器的所有密码和历史记录。清理后完全退出浏览器，再重新打开 Clash、选择固定节点并访问页面。这样可以把「旧会话失效」与「代理链路不通」分开验证。

判断方法：在页面加载异常时打开 Clash 连接列表，搜索 aistudio、accounts、googleapis 和 generativelanguage。如果请求显示 DIRECT 或完全没有记录，优先检查规则和代理接管；如果请求已经命中代理但返回明确的 401、403 或配额提示，则应转向账号权限、地区支持和服务额度排查。

验证配置是否成功：从页面加载到模型请求逐层确认

完成配置后，不要只用「能不能打开网页」作为判断标准。建议按由浅入深的顺序验证，这样每一步出现问题时都能缩小范围。

  1. 确认客户端运行：Clash 状态为运行中，系统代理开关或 TUN 状态与预期一致，当前策略组已经选择可用节点。
  2. 确认静态页面：打开 AI Studio，观察页面是否完整显示工作区、模型列表和输入区域，而不是只有标题或空白骨架。
  3. 确认账号会话：登录、退出和重新进入工作区时没有反复跳转；连接列表中能看到账号相关请求，并且策略一致。
  4. 确认最小请求：选择一个可用模型，输入简短提示词，先测试普通文本生成，不要一开始上传大文件、长上下文或启动高并发任务。
  5. 确认流式返回：观察响应是否能够持续输出。如果首字节很快但中途断开，应重点检查节点稳定性、长连接处理和浏览器扩展，而不是只看 DNS。
  6. 确认错误类型：超时、连接重置、TLS 失败属于链路方向问题；401、403、配额不足或模型不可用则属于账号、权限、地区或服务状态问题。

如果连接日志显示请求命中代理，却仍然频繁超时，可以固定一个节点进行对比，不要同时启用自动测速、负载均衡和多重故障转移。连续测试三到五次，记录响应时间、是否完整返回以及连接是否中途断开，再换另一节点比较。若只有某一个节点失败，问题更可能是线路质量或出口策略；若所有节点都出现同样的账号错误，则应检查 Google 账号状态和 AI Studio 的服务权限。

如果浏览器正常而本地代码请求失败，说明网页与开发环境并没有共享完全相同的代理设置。命令行工具可能需要显式使用 Clash 的 HTTP 代理端口：

export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890

Windows PowerShell 可以在当前会话中设置对应环境变量。端口必须以 Clash 客户端实际显示的 mixed-port 为准，不能直接照抄示例。对于 SDK、Node.js 或 Python 程序，还要查看其文档是否支持系统代理变量；有些程序只接受自身配置文件中的代理地址。若代码运行在 Docker、虚拟机、远程服务器或 WSL 中，127.0.0.1 指向的可能不是宿主机上的 Clash，需要改用能够从该运行环境访问到的代理地址，并同时确认防火墙没有拦截端口。

排障结束后，建议把规则、节点选择和 DNS 修改记录下来，保留一份能正常工作的配置备份。以后遇到 Google AI Studio 更新页面、登录方式变化或节点更换时，可以先与这份基线对比，而不是重新删除所有设置。不要把代理日志、完整请求头或包含密钥的配置文件直接发到公开论坛；分享问题时应打码账号标识、订阅链接和 API Key。

与只依赖浏览器代理扩展的方式相比，Clash 的优势在于可以在客户端连接面板中看到实际域名、策略与连接状态，也能通过规则模式把 AI Studio、Google 鉴权和 API 请求放到同一条可控链路中；而某些轻量工具往往只能切换全局开关，遇到「主页能开、模型请求失败」时很难定位。相比单纯使用全局 VPN，Clash 还能保留国内站点和本地服务的直连，减少不必要的延迟与冲突。如果你希望按照本文的思路统一管理订阅、规则和不同平台的代理接管，可以前往下载页选择适合自己设备的 Clash 客户端。

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