ChatGPT、Claude 账号突然被封？先分清是平台故障还是风控判定

先说结论

1. 「被封」有两类，先分清再动手。 一类是平台自己的故障，一类是风控判定。两者的处置方式完全不同，而绝大多数中文教程直接跳过了第一类。
2. 2026 年 6 月 5 日那一轮大规模停号，是有官方记录的平台故障。 OpenAI 状态页的事故记录原文：「An issue caused some user accounts to be incorrectly suspended.」——一个故障导致部分账号被错误暂停。事故记录起于 6 月 5 日 13:26 的第一条「正在调查」，14:20 转为「已定位问题」，最后一条停在 6 月 6 日 06:16；官方说明已恢复访问、正在处理相关订阅与额度影响，并已向受影响用户发送邮件。
3. 所以那一轮流传的「共享 IP 导致」归因，和厂商自己的记录对不上。 我们能找到的中文教程与社区帖子普遍归因于共享出口 IP；OpenAI 把同一时间窗记成了自己的故障。两件事都可能真实存在，但不能把前者当成后者的解释。
4. 网上那些比例数字，我们查不到出处。 「影响了百分之多少的订阅用户」这类说法，在 2026 年 9 月 20 日的核对中，没有在任何可引用的来源里找到依据。本文不复述任何比例。 查不到就是查不到。
5. 风控这一类里，共享出口 IP 确实是结构性高风险项。 原因不是「IP 脏」这种说法，而是连坐：平台统计的对象是地址，不是人。
6. 今天就能做的两件事：用 IP 地址查询 看清自己的出口 IP 和 ASN；趁还能登录，把对话数据导出来。导出只能在被封之前做。

本文的范围：只解释平台能看到什么、为什么会成组出事、被封之后怎么办。不提供任何「怎么配置才不被发现」的做法，不涉及手机号、支付方式或身份信息的替代手段，不涉及买号或共享账号。地区名单与条款本身是另一篇：《挂香港节点，为什么 Claude 和 ChatGPT 反而更容易出问题》。

一、第一步：去查那天有没有官方事故

在改任何配置之前，先确认你不是在修一个别人已经修好的问题。

账号出现异常的当天，做三件事：

1. 打开厂商的状态页，找当天的事故记录。OpenAI 的在 status.openai.com，有完整的历史记录页。
2. 翻邮箱，包括垃圾邮件箱。 平台侧故障导致的错误停用，厂商通常会发邮件——6 月 5 日那次，官方记录里明确写了「All users impacted should have received an email with more information.」（所有受影响用户都应已收到一封说明邮件。）
3. 看社区里同一时间窗有没有成批的同类报告。 一个人被停是风控，成千上万人在同一小时里被停，更像故障。

这三步不花钱、不花时间，却能省掉一整轮无用的折腾。

二、2026 年 6 月 5 日那一轮，官方记录是怎么写的

这是本文最值得单独拎出来的一节，因为中文互联网上关于这件事的叙述，和厂商自己的记录不一致。

OpenAI 状态页的这条事故记录标题是「Some users may experience issues accessing OpenAI accounts」，时间线如下（时间为状态页显示的时间）：

关键词是 incorrectly suspended——错误地暂停。 这不是「你的 IP 被判定为高风险」，是平台侧出了问题。

与此同时，中文这边的记录是另一幅样子。新浪财经（转自云头条）2026 年 6 月 5 日的报道写的是：用户「自己的 OpenAI 账号在没有预警和解释的情况下突然被暂停」，并且在那篇报道发稿时，「OpenAI 尚未就所谓『ChatGPT / Codex 封号潮』发布统一公开声明」。随后出现的大量中文教程，则把这一轮归因于共享／超售出口 IP、短时间跨国跳转、邮箱与支付地区异常等风控因素。

把这两条线放在一起，结论有三层：

• 归因错了一次。 那一轮的官方解释是平台故障，不是出口 IP。
• 时间差解释了为什么会错。 报道发出时官方还没有结论，后来的教程沿用了最初的猜测，而没有回头核对状态页。
• 但风控这件事本身是真的。 出口 IP 相关的风控判定确实存在，只是不能拿 6 月 5 日当它的证据。下面几节讲的是风控那一类。

给读者的实际含义：如果你的账号是在 2026 年 6 月 5 日前后被停的，先去翻那封邮件，而不是先去换节点。

三、平台连接时看得到什么

这一节回答「它到底凭什么判断我」。下面每一项都是结构上必然可见的，不是某个可以关掉的开关。

注意这里没有玄学。 不存在「某个隐藏参数暴露了你」，只有上面这些常规字段以及它们互相之间是否自洽。一个显示在 A 国的 IP、B 国的时区、C 国的发卡行，每一项单看都合法，合起来是一个天然要被多看两眼的组合。

本文把这张表列出来，是为了让你判断自己的处境有多脆弱，不是为了让你去调整其中某一项。 试图让这些字段「看起来一致」的做法，会把一个条款层面的问题变成一个主动提供不实信息的问题——后者在任何平台的规则里都更严重，也更没有申诉余地。

四、共享出口 IP：为什么会「一批一批」地出事

先把一个流行说法拆掉：「这个 IP 脏了」。这句话描述了现象，没有解释机制。机制是这样的：

平台统计的最小单位是地址，不是人。 它能看到某个 IP 上有多少个不同账号在登录、登录的时间分布、这些账号的行为特征。它看不到的是——这些账号属于毫不相干的几百个人。

于是：

• 一个地址上账号数量异常，本身就是信号。 正常家庭宽带不会有几十上百个不同账号轮流登录同一个服务。

• 连坐是结构性的，不是运气问题。 同一地址上只要有人触发了风控，整段地址上的其他账号都会被重新审视。你没做错任何事，但你和他共用一个地址。

• 机房（数据中心）地址还有额外一层。 消费级服务的正常用户不会从云主机地址登录，这个特征本身就显眼。哪些地址段属于云厂商是公开信息，平台读得到——IP 地址查询 会告诉你自己的出口属于哪个 ASN。

• 这套「按地址归类」的逻辑不只用在 AI 平台上，验证码、风控评分背后是同一件事，拆解见为什么到处都要你「证明你是人」：IP 风险分入门。

价格本身就是提示。 一个月十几块钱的套餐能成立，靠的是高度复用；复用意味着共享，共享意味着连坐。这不是某家服务商的道德问题，是这门生意的算术。

免费和超低价节点还有另外几层与账号无关的风险——运营者能看到全部流量元数据，配置文件还能改写你的 DNS 与分流规则——拆解见《免费机场节点的风险与安全替代方案》。

五、查清自己的出口：三步，五分钟

这三步的目的不是「优化」，是让你知道平台现在看到的你是什么样。

第一步，出口 IP 与 ASN。 打开 IP 地址查询，记下 IP、显示的国家／地区、ASN。

• 地区和你以为的节点对不上 → 分流规则没把这个域名送进代理。
• ASN 显示为知名云厂商 → 这是机房地址。

第二步，DNS 有没有走到别处。 打开 DNS 泄露检测。

• 出现国内运营商的 DNS，或与出口完全不同国家的服务器 → 你的解析和流量走的是两条路。

第三步，浏览器有没有漏真实地址。 打开 WebRTC 泄露测试。

• 多出一个国内地址 → 这是浏览器层的问题，代理修不了，处理办法见《把 Firefox 配成一台安全的跨境浏览器》。

做完这三步，你至少不会再把「配置错误」误当成「被风控了」。 这两者的现象很像，处理方式完全不同。

六、如果已经被封了：先保数据，再谈申诉

顺序很重要，因为第一步一旦错过就没有第二次机会。

第一件事：数据导出只能在还能登录的时候做。 账号一旦被停，登录入口就没了，里面的对话历史也就取不出来了。所以正确的做法是把导出变成日常习惯，而不是出事后的补救。

• Claude：Anthropic 官方帮助页写明，个人用户可在网页版或 Claude 桌面版的 Settings > Privacy 里导出账号信息与聊天记录；iOS 与 Android 上无法发起导出。
• ChatGPT：OpenAI 的对应帮助页在我们核对当天（2026-09-20）对自动抓取返回 HTTP 403，我们无法引用其原文，请在产品内的设置里自行查找数据导出入口。这里如实说明，不替它编一个路径。

第二件事：申诉。 条款里有明确通道。OpenAI 使用条款（标注 Effective: January 1, 2026）的原文是：

Appeals. If you believe we have suspended or terminated your account in error, you can file an appeal with us by contacting our Support team.

怎么写： 说清楚你是谁、账号邮箱、被停的大致时间、你的实际用途；如果那天有官方事故，把事故时间也写上。照实写。 编造用途或身份会把唯一一条通道也堵死。

第三件事：知道申诉能做什么、不能做什么。 在 OpenAI 自己的开发者社区里，有用户贴出了这样一段经过：账号在 2026 年 6 月 22 日被停，官方承认有误并补偿了一个月；7 月 13 日再次被停，Trust & Safety 书面回复「We have determined that we incorrectly deactivated your account access.」（我们确认错误地停用了你的账号访问权限）——而在该用户的叙述中，支持团队随后拒绝恢复订阅或退款。这是单个用户的自述，不是统计，但它说明了一件重要的事：官方书面承认「停错了」，和拿回你付过的钱，是两件事。

所以前面那句话要再说一遍：不愿意承担余额与订阅一起损失的人，就不该往这类账号里放钱。

七、不该做的事

• 不要买号、租号、用共享账号。 账号所有权不在你手里，对方的任何操作都会落到你头上，而你没有申诉位置。
• 不要把 API Key 交给第三方「中转」服务。 Key 等同于账单权限；泄漏与处置办法见《API Key 是怎么泄漏的》。
• 不要改用镜像站「先用着」。 那是把账号风险换成了数据风险，你的每一条提问都会明文经过别人的服务器，识别方法见《「ChatGPT 中文版」和镜像站》。
• 不要在申诉里编造用途。 见上一节。

最后一句：如果读完这页你的结论是「那我先不往这个账号里充钱了」，那是一个完全正当的结论，也是本文认为最稳妥的那个。地区名单与条款原文见《挂香港节点，为什么 Claude 和 ChatGPT 反而更容易出问题》；整体的注册、支付与网络方案分级见《中国使用 ChatGPT、Claude、Gemini 完整指南》。

参考资料

以下页面均于 2026 年 9 月 20 日核对。

• OpenAI 状态页 — Some users may experience issues accessing OpenAI accounts（2026 年 6 月 5–6 日事故记录，含「An issue caused some user accounts to be incorrectly suspended.」原文），核对日期 2026-09-20
• OpenAI — Terms of Use（标注 Effective: January 1, 2026；Termination and suspension、Appeals 两节）。原站对自动抓取返回 403，本文通过 Wayback Machine 2026-09-20 的快照读取：https://web.archive.org/web/20260920011501/https://openai.com/policies/row-terms-of-use/，核对日期 2026-09-20
• OpenAI Developer Community — Incorrectly deactivated TWICE in 3 weeks (error admitted in writing)（用户自述，2026 年 7 月 16 日发帖；含 Trust & Safety 的书面回复原文），核对日期 2026-09-20
• Anthropic 帮助中心 — Export your Claude data（Settings > Privacy 导出路径），核对日期 2026-09-20
• 新浪财经（转自云头条）—《突发！大量 ChatGPT、Codex 账号被封！》，2026 年 6 月 5 日。该文记述用户「在没有预警和解释的情况下突然被暂停」，并称发稿时 OpenAI「尚未就所谓『ChatGPT / Codex 封号潮』发布统一公开声明」。核对日期 2026-09-20
• 腾讯云开发者社区 —《ChatGPT 与 Codex 封号常见六大原因及自查排查指南（2026 版）》，作者 cczzcode，2026 年 6 月 13 日。属于中文教程一类，未引用任何官方来源。核对日期 2026-09-20

关于比例数字的说明：网上流传的「影响了百分之多少订阅用户」等说法，我们在上述核对中没有找到可追溯的出处；知乎上的相关长文对自动抓取返回 HTTP 403，无法引用。因此本文不复述任何比例。