ChatGPT 网页能打开、历史记录也能看，却发不出新消息，是近期较常见的一类故障。它可能来自浏览器本地缓存、界面语言或插件冲突，也可能与前端灰度实验、网络抖动有关。文章按从本地到网络的顺序给出排查步骤，并说明各种做法的适用边界。
早上还能正常对话，下午突然发不出消息；页面能打开，历史记录也在，输入框能打字，点发送却没有反应。换到手机端、换浏览器，表现还可能不一样：有人一切正常，有人消息被吞，有人回复很慢甚至被截断。
这类现象很难用一句“账号被封”或“网络坏了”解释。能看历史说明页面和登录态至少部分可用，发送失败则可能卡在前端脚本、浏览器本地数据、插件冲突、网络链路或服务端实验分组上。下面按从本地到网络的顺序拆解，并给出可以逐项验证的做法。
先判断问题落在哪一层
| 现象 | 更可能的方向 | 快速验证 |
|---|---|---|
| 无痕窗口能发，普通窗口不能 | 本地缓存、Cookie 或插件 | 用无痕窗口登录同一账号 |
| 换一个浏览器就正常 | 当前浏览器数据或扩展冲突 | 对比 Chrome 和 Edge |
| 手机、电脑、不同网络都不行 | 账号状态、服务端或地区网络 | 换设备并查看官方状态 |
| 控制台里 ab.chatgpt.com 请求报错 | 前端实验或请求被拦截 | 看 Network 面板的失败请求 |
| 能发但很慢、回复被截断 | 网络链路或服务端负载 | 换网络后对比 |
先做三个对照：无痕窗口、另一个浏览器、另一台设备。如果只有当前浏览器失败，优先查本地；如果所有设备同时失败，优先看服务端状态和网络。
最常见的一类：本地缓存和会话状态异常
网页会把界面语言、用户标识、实验分组等信息写入 Cookie、localStorage 和 sessionStorage。版本更新后，旧值和新页面不匹配，就可能出现按钮无响应、登录循环、消息被吞。清理站点数据往往能恢复，但它不是万能药，服务端问题或插件冲突仍会导致同样症状。
可以按这个顺序做：
- 打开无痕窗口，禁用扩展后登录同一账号，发一条短消息测试。
- 如果无痕正常，回到普通窗口，在 Chrome 或 Edge 中按 F12 打开开发者工具，进入 Application 面板，在 Storage 中选择 Clear site data，清除 chatgpt.com 的站点数据。
- 也可以点击地址栏左侧的站点图标，进入站点设置后删除数据。只清理当前站点，不要清空所有网站。
- 重新登录后再测试。清理 Cookie 会退出登录，属于正常现象。
如果只想先处理界面语言相关的本地值，可以在确认当前页面是 chatgpt.com 时，打开控制台执行：
localStorage.removeItem('oai/apps/locale');
location.reload();
这条命令只删除界面语言相关的键，不会主动退出账号；如果无效，再做完整的站点数据清理。控制台能读取当前站点的登录态，不要从陌生网页复制脚本进去执行。
界面语言、翻译插件和用户脚本
部分案例在把界面语言改成 English、再做一次强制刷新后恢复。操作思路是：在设置中切换界面语言，保存后按 Ctrl+Shift+R，Mac 上按 Cmd+Shift+R，绕开本地缓存重新加载页面。如果切换后仍无效，不必反复改语言，继续排查其他方向。
扩展冲突也很常见。自动翻译、广告拦截、会话增强、脚本管理器这类扩展都会修改页面，可能让发送按钮失效，也可能暂时掩盖问题。测试时先全部禁用，或直接在无痕窗口中验证；确认是某个扩展导致后，再逐个启用定位。某些保活类脚本自带临时修复，但它同样可能和新版页面冲突，更新或停用后要重新测试。
前端实验请求与服务端问题
如果控制台 Network 面板里能看到 ab.chatgpt.com 相关请求失败、跨域报错，或者发送消息时后端接口持续异常，问题可能不在输入框。部分账号可能被分到有问题的前端实验组，表现为同一时间不同账号结果不同。从现象和请求特征看，这可能与灰度发布有关，但并非官方结论，遇到时以官方状态页和错误提示为准。
可以做的事：换一个浏览器配置文件或无痕窗口重试；清理站点数据；记录失败请求的域名、错误码和时间，向官方支持反馈。若请求是被本地广告拦截器或防火墙误拦，可在确认域名归属后临时放行再测试；不要通过修改实验参数、伪造请求或安装来路不明的补丁来强行绕过分组，这类做法既不稳定，也可能带来账号和脚本安全风险。
网络链路怎么排除
页面能打开，不代表发送消息所需的长连接和接口请求稳定。可以换 Wi-Fi、手机热点，或用另一台设备在同一网络下测试；也可以反过来，在同一设备上切换网络对比。如果只有某个网络失败，重点检查本地网络、DNS、代理和防火墙；如果所有网络都失败，再看账号状态和官方服务状态。
不建议购买、共享账号，也不建议尝试绕过地区限制。使用所在地可用的官方服务，遇到访问限制时以官方说明为准。如果只是本地跨境网络长期抖动，且你需要长时间运行 Claude Code 等在线工具，可以考虑把工作负载放到网络位置更稳定的远程 Mac（例如新加坡机房的独享实例），再用远程桌面连接；这改善的是网络稳定性与在线时长，不能修复 OpenAI 侧的前端故障。
建议的排查顺序
每做完一步都重新发一条短消息测试，避免同时改太多变量：
- 强制刷新页面，排除一次性的加载错误。
- 用无痕窗口登录，确认是否与本地数据或扩展有关。
- 禁用翻译、广告拦截、用户脚本等扩展。
- 清除 chatgpt.com 的站点数据并重新登录。
- 把界面语言改为 English，再强制刷新。
- 换浏览器、换设备对比。
- 打开开发者工具，查看失败请求和错误提示。
- 换网络测试，并查看官方状态页。
- 如果多人同时出现、多个网络都失败，优先等待官方修复并反馈。
第三方客户端和 API 的取舍
网页端反复出问题时，有人会改用搭配 API Key 的第三方客户端。它的优势是绕开网页前端状态，界面和响应通常更直接；代价是按量计费、功能与网页版不完全一致，还要自行管理密钥和选择可信客户端。不要把密钥写进公开仓库或发给他人，也不要在不明来源的客户端里输入账号密码。对一次性的页面故障来说，这属于替代方案，不是首选修复手段。
注意事项
清理站点数据前确认只作用于 chatgpt.com，避免把其他网站的登录状态一起清掉。不要安装声称能“永久修复”的未知脚本，也不要把 Cookie、令牌或账号信息发给他人。OpenAI 的页面结构和设置位置会变化，具体入口以当前官方界面为准；涉及服务状态和地区可用性的信息，也应查看官方最新说明。
小结
先无痕、再禁插件、再清站点数据，然后切换语言并强制刷新，最后才查网络和官方状态。清理缓存对本地状态错乱有效，但对服务端实验、账号状态或网络问题不一定有效；如果同一时间大量用户都发不出消息，更可能是平台侧故障，等待修复比反复折腾本地环境更稳妥。