OpenAI 网页无痕能打开、正常窗口报 ERR_EMPTY_RESPONSE 的排查思路
访问 platform.openai.com 时正常窗口白屏并提示 ERR_EMPTY_RESPONSE，无痕模式却一切正常。这种「同一台机器、同一网络、只差一个窗口」的现象，基本可以把网络链路排除在外，问题多半藏在浏览器配置文件的站点数据、Service Worker 或扩展作用域里。本文给出从清数据到对照实验、再到命令行验证的分步排查顺序，并说明 HTTP/3 相关说法为何对不上这个现象。
打开 https://platform.openai.com/docs/introduction 时页面白屏，地址栏下方只留下一行 platform.openai.com 未发送任何数据。ERR_EMPTY_RESPONSE，但同一台机器上开一个无痕窗口、或者换 Safari，页面却能正常加载——这类「只差一个窗口」的故障很常见，也很容易被误判成网络问题，导致排查方向跑偏。
ERR_EMPTY_RESPONSE 的含义是：浏览器已经建立了连接（TCP 或 QUIC，通常连 TLS 握手都走完了），但对端在返回任何 HTTP 响应之前就把连接关掉了。它既可能是网络中间设备干的，也可能是浏览器本地状态触发的。而「无痕模式正常」这条线索非常关键，它把范围大幅收窄了。
先想清楚：无痕窗口到底哪里不一样
无痕窗口和普通窗口共用同一块网卡、同一套系统代理、同一份根证书、同一个 QUIC 开关，真正不同的只有以下几点：
- 默认不加载任何扩展（除非手动允许）；
- 不读取已有的 Cookie、localStorage、IndexedDB、Cache Storage；
- 不共享 HTTP 缓存和已注册的 Service Worker；
- 使用独立的会话存储，退出即清空。
所以「无痕能开、正常窗口不能开」几乎可以断定：差异出在配置文件的本地状态，而非链路质量。这同时也解释了一个常见分歧——有人认为是 HTTP/3（QUIC over UDP）被网络屏蔽导致打不开，但这个说法对不上本案例：QUIC 是浏览器级开关，无痕窗口并不会禁用 HTTP/3，如果真是 UDP 被封，两个窗口应该一起失败。
分步排查：从站点数据到浏览器配置
第一步：清除该站点的全部存储，而不只是 Cookie
只清 Cookie 往往不够，因为 Service Worker 和 Cache Storage 里的旧响应会继续被使用。
- 打开出问题的页面，按 F12 打开开发者工具；
- 切到 Application（应用） 面板 → 左侧 Storage（存储）；
- 点击 Clear site data，确保 Cookie、Local/Session Storage、IndexedDB、Cache Storage、Service Workers 全部勾选；
- 关闭该站点的所有标签页后重新打开。
也可以走设置页：chrome://settings/content/all，搜索 openai.com，把 platform.openai.com、auth.openai.com 等条目逐个删除。注意登录态会被一并清除，之后需要重新登录。
第二步：手动注销 Service Worker
如果页面曾经注册过后台脚本，它可能在网络层之前就拦截了请求：
- 访问
chrome://serviceworker-internals，搜索openai，对相关条目点击 Unregister； - 或在开发者工具的 Application → Service Workers 里勾选 Update on reload 后注销。
第三步：新建一个配置文件做对照实验
这是最省时间的一步，能直接判断「是不是这个配置文件坏了」。
- 打开
chrome://settings/manageProfile，添加一个新用户（不要用无痕，要用独立配置文件）； - 在新窗口里打开同一个链接。
| 结果 | 结论 | 下一步 |
|---|---|---|
| 新配置文件正常 | 旧配置文件的状态损坏 | 迁移书签与密码后弃用旧配置文件，或继续做第一、二步的深度清理 |
| 新配置文件同样失败 | 与配置文件无关，怀疑扩展策略或系统级软件 | 进入第四步 |
第四步：检查扩展、代理与 DNS 的作用域
「已经把所有扩展都关掉了还是不行」这种情况，通常漏掉了三类东西：
- 企业策略强制安装的扩展：访问
chrome://policy查看是否有被下发的扩展或代理配置； - 带代理能力的扩展：其代理设置保存在扩展自身，普通窗口生效、无痕窗口失效，这正好能解释现象；
- 安全软件注入浏览器的模块：部分上网行为管理、杀毒软件的 HTTPS 扫描会挂钩浏览器进程，临时完全退出再试。
另外检查两处浏览器设置：chrome://settings/system 里的系统代理是否被改过；chrome://settings/security 里的「使用安全 DNS」是否开启，可以尝试关闭或换一个服务商对比。
第五步：考虑网关对「带登录态请求」的干扰
如果所在网络有统一的出口网关或 TLS 检查设备，它可能对包含特定 Cookie 或头部的请求直接重置连接，而匿名请求则放行。验证方法很简单：在无痕窗口里先登录，再刷新同一个页面。如果此时无痕窗口也开始报 ERR_EMPTY_RESPONSE，说明触发条件与登录态有关，这已经不是浏览器能解决的问题，需要联系网络管理员或换一条网络。
用命令行把浏览器问题和网络问题彻底分开
在终端里执行下面的命令，判断链路本身是否正常：
# 只看响应头，不发请求体
curl -sSI https://platform.openai.com/docs/introduction
# 强制降级到 HTTP/1.1 对比
curl -sSI --http1.1 https://platform.openai.com/docs
# 查看握手细节
curl -v --http2 https://platform.openai.com/docs/introduction 2>&1 | head -40
- 终端能拿到
200或3xx：链路没问题，接着在浏览器侧排查； - 终端同样返回空响应：问题在网络出口，浏览器怎么调都没用；
- 若公司电脑走全局代理，记得给 curl 加
-x参数，否则它默认不读系统代理设置。
关于关闭 QUIC 的建议
关闭 HTTP/3 是一个值得一试但优先级不高的动作：在 chrome://flags/#enable-quic 里把状态改为 Disabled，重启浏览器。之所以说优先级不高，是因为它无法解释「无痕正常」这个核心现象；但它成本极低，在部分对 UDP 不友好的网络里确实能改善加载失败。需要提醒的是，Chrome 的 flags 项会随版本调整甚至移除，具体入口请以当前版本的官方说明为准。
兜底方案与注意事项
- 重置浏览器设置：
chrome://settings/reset恢复默认，再在chrome://flags点击 Reset all； - 重建配置文件：备份书签、密码后删除旧的用户数据目录，是最彻底也最笨的办法；
- 换一个干净的访问环境：如果排查成本已经超过收益，而你又需要长期稳定地访问文档、跑命令行工具，可以考虑把这类工作放到一台独立的远程机器上，例如整机放在机房、按月租用的远程 Mac，本地浏览器状态再怎么乱都不会影响它。这属于绕开问题的做法，不是修复；
- 全程不要为了「能打开」去安装来历不明的代理插件或修改系统根证书，那会带来更大的账号与数据风险。
小结
遇到「无痕能开、正常窗口打不开」的情况，排查顺序应该是：先清站点全部存储并注销 Service Worker，再用新建配置文件做对照，然后检查扩展与代理的作用域，最后才怀疑网络与 HTTP/3。每做一步都记录结果，比反复重装浏览器有效得多；命令行 curl 的输出则是最省事的「网络是否无辜」的判据。
