ChatGPT 报 500/502/503：是官方宕机还是本地网络问题
网页端突然报 500、502 Bad Gateway 或提示 under heavy load，很多人第一反应是节点被封，于是换代理、清 Cookie、买新服务，折腾半天才发现是官方故障。本文整理一套先判断、再处理的排查流程：如何看状态页、不同错误码分别指向什么、五分钟自查清单，以及确认宕机后更省事的应对方式。
工作日的下午，网页端忽然打不开，页面只剩一行 500，或者干脆是 Bad Gateway、"ChatGPT is under heavy load"；桌面客户端转圈，手机上也一样。这时候多数人的第一反应是「是不是我的节点被封了」，接着换节点、清 Cookie、换浏览器、重装客户端，甚至临时下单买了新的代理服务——折腾一两个小时，才发现是官方整体故障。
这类混乱的根源在于：服务端故障、账号与会话异常、本地网络问题，在浏览器里的表现高度相似，都是白屏、转圈或一句语焉不详的报错。下面按「先判断、再处理」的顺序，整理一套可复用的排查流程。
现象归类：三种问题长什么样
| 现象 | 更可能的原因 | 快速判断 |
|---|---|---|
| 500 / 502 Bad Gateway / 503、提示 under heavy load | 服务端过载或故障 | 换设备、换网络同样报错；状态页有 incident |
| 连接被重置、一直转圈、页面空白 | 本地网络、代理或 DNS 链路 | 同一网络访问其他海外站点是否正常 |
| 登录后卡在验证环节、反复跳回登录页 | 会话、Cookie 或账号风控 | 无痕窗口、另一账号是否同样卡住 |
先给现象归个类，能省掉大部分无用操作。5xx 是服务器返回的状态码，意思是「请求到了，但后端没接住」，这类错误基本不是你能在本地修好的。
第一步：先看官方状态页
OpenAI 有公开的状态页（status.openai.com），会列出当前 incident、影响范围和更新时间。故障刚开始时状态页往往有几分钟到几十分钟的延迟，显示正常并不代表没问题；反过来，恢复后也可能还挂着旧记录。以时间点和 incident 描述为准，而不是只看那个绿色图标。
还要注意：ChatGPT（网页与 App）和 API 是分开的组件，经常出现网页端大面积 5xx、API 却仍可调用的情况。看到「网页挂了」就推断「全都不能用」，容易做出错误决策。
第二步：五分钟自查清单
不用开一堆工具，按顺序做几件事就够：
- 无痕窗口打开：排除浏览器扩展、缓存和旧会话的干扰。
- 换设备或切手机流量：如果手机流量下正常，问题就在原来的网络链路上。
- 同一网络访问其他海外站点：其他站点也打不开，说明是本地链路或代理问题；只有目标站点异常，则更像服务端故障。
- 核对系统时间：时间偏差过大会导致 TLS 握手失败，报错却常常看起来像「网络不通」。
- 直接看返回码：
# 网页入口
curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://chat.openai.com
# API 入口（不带 key 也会返回 401，关键在于能否拿到响应）
curl -sS -o /dev/null -w "%{http_code}\n" https://api.openai.com/v1/models
返回 5xx，基本可以判定是服务端问题；返回 000、长时间无响应或连接被重置，则更可能是本地链路。API 返回 401 恰恰说明链路是通的。
第三步：确认是官方故障之后
确认是服务端故障，剩下能做的事情不多，但可以做得更聪明：
- 停止无意义的重试与改配置。反复刷新、频繁切换出口 IP，除了浪费时间，还可能让账号触发额外的安全校验。
- 换入口而不是换网络。网页端不可用时，检查 API 是否仍可用；通过 API 调用的第三方客户端有时还能继续工作，因为它走的是另一个组件。也可以临时用其它模型顶上，把非核心任务挪到之后。
- 别在故障期冲动消费。为「修网络」临时购买服务、随后又退款，是这类事件里最常见的无效支出。
- 把依赖拆开。真正影响工作的往往不是「没有 ChatGPT」，而是「所有任务都压在一个入口上」。日常准备一个 API 侧的备用通道，或者至少准备一个可替代的模型，成本远低于一次手忙脚乱。
- 长时间在线的任务要考虑运行环境。如果工作流依赖脚本、自动化或长时间运行的 AI 编码工具，本地网络抖动和代理切换是常态干扰，把这类任务放到网络环境稳定的远程机器上会更省心——例如整台放在新加坡机房的独享 Mac mini，按月租用、远程连接，可以长期在线运行 Claude Code 之类的工具。这只是可选项之一，和本次故障本身无关。
几个容易被忽略的细节
别人说「我这边正常」不等于你没问题
大型服务故障期间，部分用户正常、部分用户持续 5xx 是常态，通常与接入节点、账号分片或负载均衡有关。同样，别人的报错截图也不能证明你遇到的是同一件事，回到状态页和返回码上判断。
清 Cookie 后短暂可用，多半是巧合
有用户反馈清理浏览器数据后能短暂打开，很快又空白。这更像是请求被分到了不同后端实例，而不是本地缓存问题。把偶发的成功当成「找到原因」，会让排查绕远路。
登录卡在验证环节，不一定是网络
如果页面能打开但登录后反复卡在验证，先排除会话与账号侧因素：换无痕窗口、换账号对比。仍不通再考虑链路问题。
关于会员补偿
服务中断是否补偿、如何补偿，取决于官方的服务条款和当时的公告，没有统一的默认答案。有疑问应以官方帮助中心的最新说明为准，不要根据他人的经验推断。
账号与网络访问的合规边界
网上流传的共享账号、买卖账号、代充值、频繁更换出口以规避限制等做法，风险由使用者承担：可能触发风控导致账号受限、支付信息暴露，出问题也基本没有申诉渠道。更稳妥的做法是使用官方支持的注册与付费方式、官方 API，或适合团队的企业方案；涉及地区与支付政策的部分，请以官方最新说明为准。
小结
遇到打不开，先问三个问题：返回码是多少？换个网络还一样吗？状态页有没有记录？绝大部分「疑似被封节点」的折腾，都能在这三步内被排除。真正需要长期稳定运行的任务，则应该在平时就把运行环境和备用入口准备好，而不是等故障发生后再补救。
