免责声明

本文仅记录一次个人网络故障排查过程，用于说明浏览器开发者工具、HAR（HTTP Archive，HTTP 网络请求归档）和单变量对照测试的使用方法。文中关于代理节点、HTTP 状态码和服务端风控的判断只适用于本次观察，不能推导为 Google 或 Gemini 的官方结论。请遵守所在地区的法律法规、服务条款和网络使用规则，不要利用本文规避平台安全措施、滥用服务或进行未经授权的访问。HAR 文件可能包含 Cookie、认证令牌、请求正文和个人会话信息，公开前必须完成脱敏。因不当使用或误判造成的损失与责任，由使用者自行承担。

Gemini 网页正常打开，但发送消息提示“出了点问题 (1)”？一次网络故障排查记录

记录时间：2026 年 10 月 15 日
环境：Windows、Microsoft Edge、通过代理访问 Gemini
关键词：Gemini、出了点问题 (1)、HAR、HTTP 429、RotateCookies、代理节点

一、故障现象

访问 Gemini 时，页面能够正常打开，界面和输入框也能显示，但发送消息后无法获得回复，页面提示：

出了点问题 (1)

这个现象很容易让人误以为是 Gemini 服务端故障、Google 账号异常，或者浏览器扩展造成的问题。但能打开网页，不代表消息生成链路也正常。

二、第一轮排查：查看 HAR 网络日志

通过 Edge 开发者工具（F12）中的 Network（网络） 面板记录请求，并导出 HAR（HTTP Archive，HTTP 网络请求归档）文件。

在本次记录的初步统计中：

其中，geminiweb-pa.clients6.google.com/v1/processSession 相关请求多次返回 HTTP 200；另有 manifest.json 请求未取得有效 HTTP 响应。

重要提醒：HTTP 200 只说明请求获得了成功的 HTTP 响应，不等于 Gemini 已成功生成内容。 生成结果可能通过额外的会话或流式通信传递，应用层也可能返回错误。

日志中还能看到会话建立、读取及终止等行为。但 TYPE=terminate 本身可能属于正常的会话结束，不能仅凭它断言代理切断了连接。

因此，第一轮 HAR 并没有直接证明是哪一个接口导致消息失败。

三、第二轮排查：检查浏览器 Console

打开 F12 → Console（控制台），观察发送消息前后出现的错误。

1. 最值得关注：RotateCookies 返回 HTTP 429

1
2

accounts.google.com/RotateCookies
Failed to load resource: the server responded with a status of 429

HTTP 429 的含义是 Too Many Requests（请求过多），通常表示服务端对请求进行了限流。

RotateCookies 与 Google 账号登录态 Cookie 的轮换有关。可能涉及请求频率、代理出口 IP 的共享使用情况、账号认证请求重试等因素。

不过必须明确：429 出现在 Google 账号相关接口，而不是已经确认的 Gemini 消息生成接口。 它是值得追踪的线索，但不足以证明 Google 已经对代理 IP 实施 Gemini 专项封禁。

2. manifest.json 的 CSP 错误

1
2

Loading a manifest ... violates the following Content Security Policy directive:
"manifest-src 'none'". The action has been blocked.

CSP 是 Content Security Policy（内容安全策略）。这条错误说明网页 Manifest 加载被策略阻止，但没有证据表明它直接导致聊天消息发送失败。

3. script-src 警告

1
2

The policy is report-only, so the violation has been logged
but no further action has been taken.

这类 CSP 记录明确属于 report-only（仅报告），不会因为该策略本身阻止脚本执行，不应直接认定为根因。

4. 其他提示

• ad.doubleclick.net 出现 ERR_CONNECTION_CLOSED：广告或统计请求连接关闭，通常不是 Gemini 核心聊天故障的直接证据。
• powerPreference option is currently ignored：Windows 图形适配器相关提示，与本次消息失败没有明确关联。
• No ID or name found in config：前端配置相关日志，单独出现不足以确定原因。

四、关键实验：只更换代理节点

这次最有效的排查动作，并不是清理浏览器缓存，也不是重装浏览器，而是进行单变量对照测试：

1. 保持 Edge 浏览器不变。
2. 保持同一个 Google 账号不变。
3. 保持 Gemini 页面和操作方式不变。
4. 仅切换代理节点，重新发送消息。

实测结果：切换代理节点后，Gemini 恢复正常，可以发送消息并获得回复。

这是本次排查最有力的证据。

五、原因分析：为什么网页能打开，消息却发不出去？

页面加载和模型生成涉及的请求路径、接口和通信行为并不完全相同。静态资源能够正常加载，并不意味着账号认证、会话建立和消息生成也一定正常。

结合本次现象，有三种合理解释：

已证实的是：在此次测试条件下，问题与原代理节点或其网络路径高度相关。

尚未证实的是：究竟是 Google 对旧 IP 限流、节点传输异常，还是代理实现或线路问题。 仅凭一次切换成功，无法在这几种解释之间作出唯一判断。

六、遇到相同问题，推荐这样排查

第一步：先做最小成本的对照实验

保持账号、浏览器和输入内容不变，仅切换一个不同的代理节点，再发送简单消息，例如“你好”。

• 如果新节点正常、旧节点失败：优先调查旧节点、出口 IP 和路由。
• 如果所有节点均失败：再考虑账号、浏览器环境、Google 服务端或更普遍的网络问题。

第二步：在 Console 查看异常

打开 Edge 开发者工具：

1. 按 F12。
2. 选择 Console。
3. 勾选 Preserve log（保留日志）。
4. 清空旧日志，重新发送一条消息。
5. 重点关注 429、403、Failed to fetch、ERR_CONNECTION_RESET 等信息。

注意：某条错误出现的时间接近消息发送，不代表它必然是故障原因。

第三步：用 Network 找到实际失败的请求

在 Network 面板中启用 Preserve log，选择 Fetch/XHR，发送消息后检查新出现的请求。可关注 StreamGenerate、BardFrontendService、processSession 等名称（实际接口可能随版本变化）。

重点看：

• 请求是否真正发出；
• HTTP 状态码；
• 请求耗时及是否中断；
• Response / Preview 中是否有业务错误；
• 同一请求在正常节点与异常节点上的差异。

第四步：排除浏览器因素

如果切换节点没有改善，再使用无痕窗口对比，确认扩展没有在无痕模式运行。如果无痕正常、普通窗口异常，再逐个排查扩展和站点数据。

不建议一开始就清除全部 Google Cookie，这可能导致重新登录，增加排查变量。

七、最终结论

本次故障的表现是：Gemini 页面正常加载，但发送消息提示“出了点问题 (1)”。

HAR 显示大部分 HTTP 请求成功；Console 则记录了 accounts.google.com/RotateCookies 的 HTTP 429。最后通过仅更换代理节点，Gemini 消息发送恢复正常。

因此，最可靠的结论是：旧代理节点或其网络路径是此次故障的关键影响因素。 至于是不是 Google 对该出口 IP 进行了风控，目前证据还不足以确认。

排查经验：当一个 AI 网站“能打开，但不能对话”时，别只看页面能否加载，也别急着重装浏览器。优先通过切换代理节点做单变量测试，再结合 HAR 与 Console 定位具体请求，通常能更快缩小问题范围。

安全提醒：HAR 文件可能包含 Cookie、认证令牌、请求正文及个人会话信息。公开博客时应对这些内容脱敏，不要直接上传未经处理的完整 HAR。