“Too many concurrent requests”直译是“同时进行的请求太多”：ChatGPT 认为你的账号在同一时刻有太多请求还没处理完，于是拒绝了新的这一个。它和“一小时内发了太多条”“消息额度用完”不是一回事，只开着一个页面的人也会遇到，因为触发它的不一定是你自己的操作。
OpenAI 的帮助中心没有这条报错的条目，也没有公布任何套餐的并发上限。所以下面的顺序不是 OpenAI 给出的专门解法，而是按“先排除不归你管的原因，再处理你能动的部分”排出来的，每一步都有明确的停止条件。
| 顺序 | 做什么 | 出现这个结果就停 | 依据来自 |
|---|---|---|---|
| 1 | 打开 status.openai.com 看 ChatGPT 有没有进行中的事故 | 有事故：本地怎么操作都没用，等它恢复 | OpenAI 状态页；媒体对历次故障的报道 |
| 2 | 停止连续发送，关掉其他正在生成的标签页、桌面端和手机 App，等上传和后台任务结束 | 只留一个页面后能正常发消息 | 从报错字面作出的推断，OpenAI 没有写明 |
| 3 | 退出登录，清除 ChatGPT 的站点数据，再重新登录 | 重新登录后恢复 | 用户反馈；OpenAI 的通用排障步骤 |
| 4 | 换浏览器、换网络、换设备各试一次 | 换了以后正常：问题在原来的浏览器或网络 | OpenAI 的通用排障步骤 |
| 5 | 以上都试过仍然报错，带上 HAR 文件和出错时间联系 OpenAI | 交给官方处理，不再自己折腾 | OpenAI 的通用排障步骤 |
截至 2026 年 10 月 1 日，表里的办法都来自文档、报道和用户反馈，没有哪一步保证有效，也没有公开的成功率。
Too many concurrent requests 是什么意思：同一时刻请求太多
这句话里的关键词是 concurrent，意思是“同一时刻”。可以把它想成柜台前排队：不是你今天来的次数太多，而是你名下此刻有太多件事同时在办，柜台不再接新的。“Reached concurrency limit”是同一个意思的另一种写法，直译是“已达到并发上限”。
容易和它混在一起的有两类提示，处理方式不同：
- 按时间段计数的提示，比如“Too many requests in 1 hour. Try again later.”，说的是一段时间里发得太多。
- 套餐的消息额度用完，说的是这个套餐在一个周期里能发的消息已经发完。
并发类报错不涉及这两种计数。OpenAI 的排障文章 Troubleshooting ChatGPT Error Messages 列出了“Something went wrong.”“A network error occurred.”等十来条提示，其中没有“Too many concurrent requests”，也没有“Reached concurrency limit”；在帮助中心搜索这句话，得到的是 API 限流和通用排障的文章。Free、Go、Plus、Pro、Business 各套餐允许同时进行多少个请求、多少个对话或多少个标签页，公开文档里都没有数字。网上流传的“每小时若干条”“最多同时几个请求”之类的固定数字，在 OpenAI 的文档里找不到出处。
屏幕上是哪一句：按报错原文找第一步动作
并发类提示有好几种写法，出现的时机也不一样。有的在发送消息后出现，有的在加载订阅信息或打开某个 GPT 时出现，这时你甚至还没输入任何内容。OpenAI 的帮助文档一条都没有收录，下面的写法可能与你屏幕上的略有出入，按最接近的一行看。
| 屏幕上的原文 | 中文意思 | 第一步 |
|---|---|---|
| Too many concurrent requests | 同时进行的请求太多 | 查状态页；没有事故就停掉重叠操作 |
| Reached concurrency limit | 已达到并发上限 | 同上 |
| Your current concurrent conversation limit has been reached. Please try again later. | 你当前能同时进行的对话数已到上限，请稍后再试 | 停掉其他还在生成的对话和后台任务，等它们结束再发 |
| Failed to load subscription: too many concurrent requests. Contact support@openai.com if error persists. | 订阅信息加载失败：同时进行的请求太多；持续出现请联系 support@openai.com | 别反复刷新；查状态页，再重新登录；一直不好就按提示联系官方 |
| Unable to load GPT: too many concurrent requests | 无法加载这个 GPT：同时进行的请求太多 | 先在普通对话里发一条消息，确认是整个账号的问题还是只有这个 GPT |
| You are making requests too fast! Please wait ~10 seconds... | 你发请求太快了，请等大约 10 秒 | 按它写的时间等，期间不要点任何按钮 |
| You’re making requests too quickly. We’ve temporarily limited access to your conversations to protect your data. Please wait a few minutes before trying again. | 你发请求太快；为保护你的数据，已暂时限制访问你的对话，请等几分钟再试 | 停止操作等几分钟，不刷新、不重复点击 |
最后两条自己写了要等多久（约 10 秒、几分钟），其余几条都没有写等待时间。
如果你看到的是别的提示，处理方向不同：删除对话后出现 429、侧边栏的历史记录变成空白，看 ChatGPT 删除对话后提示 Too Many Requests，历史记录空白怎么办；回答生成到一半中断并提示 Error in message stream，看 ChatGPT 提示 Error in message stream？先保存内容，再按状态、会话、网络和附件分支排查。
先查 status.openai.com：有事故就停手等恢复
状态页显示 ChatGPT 有进行中的事故时，这条报错多半不是你造成的，清缓存、换浏览器、重新登录都解决不了，等事故结束即可。
这条报错在 OpenAI 自身出故障时大面积出现过，有据可查：
- 2025 年 6 月 10 日，西班牙《世界报》（El Mundo）报道称 ChatGPT 全球故障期间，用户从清晨起在页面上看到红色的“too many concurrent requests”提示，OpenAI 状态页同时确认了故障；部分用户在西班牙时间 19 点左右恢复正常。
- 日本博客 did2memo 的记录显示，同一条报错在 2025 年 6 月 10 日、2025 年 10 月 26 日和 2026 年 7 月 25 日都随故障集中出现过。这是单个作者的记录。
事故并不少见。OpenAI 状态页的历史记录里，2026 年 9 月标题点名 ChatGPT 或 ChatGPT Work 出错的事故至少有 20 起，分布在 15 个不同的日期，例如 9 月 10 日的“Increased Error Rate For Pro and Plus Plan Conversations”和 9 月 30 日的“Elevated errors across ChatGPT, Codex, and the API including the Agents API”。这个数是按标题数出来的，纳入哪些标题会影响结果；页面日期按浏览器所在时区显示，可能差一天。
看状态页时注意两点。第一，事故标题不会写用户屏幕上显示的是哪句话，没有一个标题带 concurrent 这个词，所以要看的是“ChatGPT 现在有没有事故”，而不是去找这句报错。第二，事故常常只影响某些套餐或地区，标题里会写明是 Free 和 Go、Plus 和 Pro，还是欧洲、亚太用户，对照自己的情况判断是否相关。
did2memo 的作者还观察到，2025 年 6 月那次故障中，没有登录就使用 ChatGPT 的人更容易遇到这条报错。这只是一个人在一次故障里的观察，但如果你正好没登录，登录后再试一次成本很低。
状态页正常时：停掉同一账号上重叠的操作
状态页没有事故，下一步是让你的账号上同一时刻只剩一个请求。哪些操作会被算作“同时进行”，OpenAI 没有写明；从报错的字面意思看，下面这些情况都可能占着名额：
- 上一条回答还在生成，你又发了一条，或者连点了几次“重新生成”。
- 几个标签页、桌面端和手机 App 同时在生成回答。
- 文件还在上传或处理。
- 深度研究、智能体（agent）这类运行时间长的任务还在后台执行。
- 浏览器扩展或自动化脚本在替你调用 ChatGPT。
- 另一个人正在用同一个账号。
处理方法是反过来做：先停止发送，等正在生成的回答结束或点停止按钮；关掉多余的 ChatGPT 标签页，退出暂时不用的桌面端和手机 App；等上传和后台任务跑完；然后只在一个页面里发一条简短的消息测试。能正常回复，说明刚才确实有操作重叠，之后一次只跑一个任务就行。
报错后立刻连续重试没有好处。等回答时可以参考 OpenAI 排障文章对“卡在生成中”的建议：先等 30 到 60 秒，再点停止，然后重新生成。这是它针对回答卡住给出的做法，不是这条报错需要等待的时长。
账号如果是和别人共用的，重叠可能发生在你看不到的地方。OpenAI 在另一条提醒“Suspicious Activity Alert”（可疑活动提醒）的说明里，把“同时登录的会话比平时多”列为触发因素之一，并写明共享账号可能触发提醒。那是另一条提示，OpenAI 没有说并发报错也由它引起，但它说明同一账号上的同时登录是被监测的。想排除这个因素，可以在设置里退出所有设备，再只在一台设备上登录。
只开一个页面也报错：退出登录并清除站点数据
如果你确认没有任何重叠操作，下一步处理登录状态和浏览器里保存的站点数据。有用户反馈只开着一个标签页、甚至几天没用 ChatGPT 也遇到这条报错，论坛帖子和教程视频里提到最多的办法，是退出账号、清除 ChatGPT 的 Cookie 和站点数据后重新登录。这是用户的说法，没有成功率可查，OpenAI 也没有确认过原因。
操作顺序：
- 在 ChatGPT 里退出账号。
- 清除 chatgpt.com 的站点数据。在 Chrome 里点地址栏左侧的图标，进入“网站设置”，选择删除数据；其他浏览器在隐私设置里按网站清除 Cookie。只清这一个网站即可，不必清空整个浏览器。
- 关闭所有 ChatGPT 标签页，重新打开并登录。
- 发一条简短的消息测试。
清除站点数据不会删除你的对话，对话保存在账号里；会丢的是这台设备上的登录状态和还没发出去的草稿，动手前把输入框里的内容复制出来。
想先试更省事的办法，可以用强制刷新（Windows 按 Ctrl + Shift + R，Mac 按 Cmd + Shift + R），或者开一个无痕窗口登录测试。无痕窗口不带原有的 Cookie，默认也不运行大多数扩展：在无痕窗口里正常，问题就在原来的站点数据或某个扩展上。桌面端和手机 App 对应的做法是完全退出应用再打开，仍不行就退出账号重新登录。
这些步骤出自 OpenAI 排障文章里针对“Something went wrong.”、回答卡住和白屏的建议，不是针对并发报错写的，用在这里属于合理借用。
换浏览器、换网络、换设备仍报错：带上 HAR 联系 OpenAI
前面三步都没用时，用对照的办法分清问题在浏览器、网络还是账号，一次只换一个条件：
| 换什么 | 换了以后正常，说明 | 换了以后仍报错，说明 |
|---|---|---|
| 同一台电脑换一个浏览器 | 原浏览器的扩展或站点数据有问题，逐个停用扩展排查，先停隐私和安全类 | 不是浏览器的问题 |
| 同一台设备换一个网络，比如手机热点 | 问题在原来的网络 | 不是这个网络的问题 |
| 同一个账号换一台设备 | 问题在原设备 | 更可能在账号这一侧 |
公司或学校网络另有一项检查。OpenAI 的网络建议让你先确认两件事：只有你这台机器出错，还是同一网络里的人都出错；换成手机热点后报错是否消失。如果是整个网络的问题，需要网络管理员放行 *.chatgpt.com、*.openai.com、*.oaistatic.com、*.oaiusercontent.com，以及通过 TCP 443 端口连接 wss://ws.chatgpt.com 的 WebSocket 流量。这份建议面向所有 ChatGPT 连接问题，不是专门针对并发报错的。
OpenAI 的通用步骤里还有一条是关闭 VPN、代理和安全 DNS 类工具。它的作用是排除中间环节对连接的干扰。你所在的网络如果做不到这一条，就跳过它，改用上表的对照来判断：换了设备和网络仍然报错，原因就不在本地网络上。
换过浏览器、网络和设备，状态页也没有事故，报错还在，问题就在账号一侧，自己能做的已经做完。联系 OpenAI 时按排障文章的要求准备材料：
- 出错时录下的 HAR 文件和浏览器控制台里的报错，带时间点。HAR 在浏览器开发者工具的“网络”面板里导出，里面可能包含登录凭据，只发给官方支持，不要贴到论坛或群里。
- 当时使用的模型。
- 出错对话的链接或 ID。
- 屏幕上报错的完整原文，以及你已经试过的步骤。
联系入口是 help.openai.com 页面上的聊天气泡；带“Failed to load subscription”的那条提示自己写了联系 support@openai.com。
升级 Plus 或 Pro 能解决吗：没有文档说可以
不能指望靠升级解决。OpenAI 没有公布任何套餐的并发上限，也就没有文档说明 Plus、Pro 或 Business 的上限更高。从状态页看，付费用户同样会遇到故障：2026 年 9 月 10 日、22 日、23 日和 30 日的事故标题点名的正是 Plus 和 Pro 用户。
如果报错来自故障，升级不会让故障提前结束；如果来自登录状态或站点数据，升级也不会改变它。为了更高的消息额度、更多模型或团队功能而升级是另一回事，按自己的用途决定，可以看 ChatGPT Plus、Pro 与 Business 怎么选：先分清个人订阅和团队工作区。只为消除这条报错去付费，没有依据。
换一个账号同样不是办法。新账号不会让故障消失；多个人共用一个账号，反而可能触发上面说的可疑活动提醒。
要等多久才能恢复：只有两条提示写了时间
没有统一的答案。只有两条提示自己写了等待时间：“You are making requests too fast! Please wait ~10 seconds...”写的是约 10 秒，“You’re making requests too quickly...”写的是几分钟。“Too many concurrent requests”“Reached concurrency limit”和其余几种写法都没有写，OpenAI 的文档里也没有。网上常见的“等 1 到 5 分钟”“等 5 到 10 秒”没有出处。
实际能用的判断是：
- 状态页有事故，恢复时间取决于 OpenAI，以状态页的更新为准。2025 年 6 月 10 日那次，从清晨开始到部分用户恢复用了大半天。
- 状态页正常，原因是操作重叠，那么占着名额的回答或任务结束后就可以再试。
- 清掉重叠操作后仍然报错，继续等不解决问题，直接做重新登录和清除站点数据那一步。
调用 OpenAI API 遇到 429：按 Retry-After 退避，和 ChatGPT 订阅无关
用代码调用 OpenAI API 收到 429，是另一套规则，上面针对 ChatGPT 网页和 App 的步骤不适用。OpenAI 的 API 限流与 429 排障文档有几点会直接影响处理方式：
- 429 不一定是限流。它也可能表示预付余额用完，或触及支出、用量上限，对应的错误码有
credit_balance_exhausted、organization_usage_limit_exceeded、organization_spend_limit_exceeded、project_spend_limit_exceeded。先看错误码，余额和支出上限的问题靠重试解决不了。 - 限额按组织和项目计算，不是按个人；同一个项目里的其他程序也在占用同一份限额。
- 限流可能在比显示的周期更短的窗口里执行。文档举的例子是，每分钟 60 次请求的限制，也可能按 1 秒的粒度执行，所以短时间内突发的并行请求会被拒绝，即使一分钟的总数没有超。
- 属于临时限流时，响应带
Retry-After头就按它等；没有就用带随机抖动的指数退避，并限制重试次数。官方 SDK 已经会自动重试符合条件的限流错误并遵守Retry-After。 - 失败的请求也计入每分钟限额，立刻重发同一个请求只会让限流持续更久。
具体限额因模型和用量等级而异，以组织的 Limits 页面显示为准。ChatGPT 的订阅不改变 API 的限额，两者分开计费、分开限流。在 Codex 里遇到 429 并停止重试，看 Codex 报 429 并停止重试：先找限流归属，再恢复任务。
