最近不少人发现,自己的 ChatGPT/Codex 订阅“变笨了”:回答越来越短,推理没几步就交卷,前一天还能做对的题今天做错;更有甚者,隔三岔五弹出一句 “Selected model is at capacity. Please try a different model.”
中文社区给这种现象起了个名字:降智。
很多人的第一反应是:是不是 IP 不干净?于是换节点、换家宽、换国家,把网络折腾了一圈。结果往往是——IP 换了好几个,表现并没有改善。
我们把过去几个月的社区测试、GitHub 讨论、OpenAI 服务条款与官方人员的公开发言都翻了一遍,重点看 Codex。结论先放在前面:
- 现有公开资料不支持把降智归因于 IP。 同一个 IP 下,有的账号正常,有的账号降智;人在海外、不挂任何 VPN,也同样有人降智。
- 问题更多跟着账号、客户端和服务端状态走。 账号状态、请求从哪个客户端发出、模型本身的表现和服务器容量,都可能起作用,各自占多大比例,目前没人说得清。
- 有一种用法被 OpenAI 明确点名: 把个人订阅转换成 API、再分发或转售给许多人使用的“订阅转 API”反代,OpenAI 表示这类用法会被反欺诈系统标记。
换 IP,不是一个经过验证的修复办法。

示意图:订阅被复制、共享的风险落在账号上,网络本身并没有变。
一、先把三件事分开
“用不了”“变笨了”“报容量不足”,看起来都是“AI 出问题了”,其实是三种不同的问题,排查方向也不同。
| 你看到的现象 | 主要该往哪查 | 和 IP 的关系 |
|---|---|---|
| 打不开、被拦截、“Sorry, you have been blocked”、提示地区不支持 | 网络与地区准入 | 有关系。 IP 所在地区、是否被 Cloudflare 拦截,会直接影响能否访问 |
| 能用,但回答变短、推理变浅、模型像换了一个(降智) | 账号状态、客户端与请求方式、模型表现 | 没有证据表明换 IP 能改善。 公开测试中,同一 IP 下不同账号表现不同 |
| “Selected model is at capacity” | OpenAI 服务端容量 | 这是服务器过载的提示。 官方客户端用户同样大量遇到 |
把这三件事混在一起,就容易出现“换了十个 IP,降智还在”的白费力气。
二、案例一:同一个账号、同一个 IP,只换客户端
2026 年 6 月,一位开发者在 CLIProxyAPI 项目的 GitHub 讨论区发布了一组对比测试。据作者自述,他身在新加坡,没有使用任何代理工具,并认为自己的账号和 IP 都没有异常(这些状态外界无法独立核验)。
他用一道固定的逻辑题(正确答案是 21)反复测试,只改变“谁来发请求”:

据该讨论帖整理:一位用户在 2026 年 6 月的单人重复测试结果,不是大样本研究,也不是 VilaVPN 实测;不能据此认定哪个客户端会被惩罚。
在他的测试里,官方 Codex CLI 直接登录时答对了;通过 SDK、反代工具或第三方客户端发出的请求,却答错了,而且推理 token 数都卡在 516 附近。后来这个“516”也成了社区判断降智的常用信号之一。
网络一模一样,结果却随客户端变化。 这组结果至少说明,表现并不只由 IP 决定;至于差别来自客户端配置、请求内容还是服务端处理,单凭这一组测试还分不清。
还要补充一点:OpenAI 后来公开表示,用自己的账号登录 OpenCode 等开源客户端“完全没问题”(见第五节)。官方允许使用某个客户端,和它在某次测试中答错,两件事并不矛盾: 前者是使用许可,后者只是当时的测试表现。
三、案例二:人在海外、不挂 VPN,也一样降智
如果降智是“中国用户翻墙、IP 不纯净”造成的,那么身在海外、直接用本地网络的人应该不受影响。事实并非如此。
- 上面那组测试本身就是作者在新加坡本地网络完成的,没有使用任何代理工具,依然测出了降智。
- 在 OpenAI 官方的 Codex 仓库里,有月付 200 美元的 Pro 用户反映:用的是官方客户端,额度也没用完,却不时收到容量错误和明显“缩水”的回复。仓库里还有其他使用官方客户端的用户报告了类似问题。
- 在 sub2api 项目的讨论中,也有用户反馈:换成家庭宽带 IP 后,依然降智。
身在海外、本地直连、不挂任何 VPN,也照样有人降智。 把原因归到“IP 不干净”上,解释不了这些情况。
四、案例三:同一个 IP,有的账号正常,有的账号降智
更直接的对比,是在同一个 IP 上换账号。
2026 年 9 月 13 日,LINUX DO 论坛一位用户发帖,标题就是《确定了,是 GPT 账号降智跟 IP 没啥关系》。他的主账号长期通过 sub2api 反代使用,出现了降智;为了弄清是设备还是 IP 的问题,他给另一个老账号重新开通 Plus,用同样的 IP、同样的客户端登录,结果不降智。他的结论是:降智是“账号维度”的,“各位不用努力去换啥家宽 IP 了”。
他还描述了自己那个降智账号的规律:第一次请求正常,第二次开始降智,之后要经过一两个小时冷却,如此循环。
同一论坛 9 月初的另一份长篇测试也观察到同样的现象:在同一个家庭宽带 IP 下,作者自己的 Pro 账号依旧降智,刚买的 Plus 账号却没有降智,其他网友测试也是如此。作者因此认为,降智“跟 IP 大概率没有任何关系”。值得一提的是,这位作者没有在 sub2api 拼车与降智之间找到必然联系,认为降智何时出现带有很强的随机性。
IP 相同,结果不同——问题跟着账号走,而不是跟着 IP 走。 至于账号为什么会进入这种状态,外界只能推测;这些测试也不能证明账号一定被打了风控标签。
当然,社区里也有不同声音。有人认为 IP 在风控中“有一定权重”,也有人说换到大厂或家宽 IP 后情况有所缓解。这些同样是个人观察;IP 作为众多信号之一参与判断,这种可能不能排除。但“同 IP、不同账号”的对比说明,光靠换 IP,解释不了、也解决不了这里的差别。
五、OpenAI 官方到底说了什么
社区测试终究是个人实验。更有分量的,是 OpenAI 自己的条款和公开表态。
服务条款写得很明确。 OpenAI 现行使用条款规定,用户不得共享账号凭证,也不得“让其他任何人使用你的账号”;不得出租、出售或分发其服务;不得规避速率限制或其他保护措施。账号共享政策也说:账号只属于创建它的个人,别人要用,应该自己注册。
Codex 负责人亲自点名 sub2api。 2026 年 8 月 21 日,OpenAI Codex 负责人 Tibo Sottiaux 在 X 上发文说,他们调查用户反映的额度异常时发现,受影响的用户中很多人在用 sub2api;把订阅转换成 API 流量,再转售或分享给许多人使用,不是 OpenAI 支持的用法,这类用法会被他们的反欺诈系统标记。两天后他又简短回复了一句:“我们不支持 sub2api。”
同一篇发文里,他也说得很清楚:用自己的订阅、通过“使用 ChatGPT 登录”在官方客户端或 Pi、OpenCode 等开源客户端里使用,完全没问题。
被标记后会怎样? OpenAI 帮助中心有一篇模型访问问题的说明:账号若被判定可能违反服务条款(例子包括与未授权方共享账号凭证),或出现可疑的安全信号(例如多次登录失败、从陌生地点访问),模型访问或能力可能被临时限制。
把这几点放在一起:OpenAI 明确点名的,是把个人订阅转供多人使用、转售的行为,而不是你用了哪条网络。 反欺诈系统标记的对象是账号。
需要说明的边界:OpenAI 没有公开风控用了哪些信号、标记后具体如何处置,也没有正式承认 Codex 会“悄悄”把账号切到弱模型。“降智”与“账号被标记”之间的对应关系,目前来自帮助中心的限制说明加上大量用户报告,而不是 OpenAI 对 Codex 的专门声明。
作为对照,Anthropic 的做法更严格:Claude 的法律与合规说明直接禁止第三方开发者在自己的应用里接入 Claude 订阅登录,或代替用户用订阅凭证转发请求。两家尺度不同,但方向一致:订阅是给个人用的,不是拿来改造成 API 批发的。
六、“Selected model is at capacity” 不等于你被标记了
很多人把这句提示当作“账号被风控”的证据。其实不然。
在 OpenAI 开源的 Codex 客户端代码里,这句话对应的是服务端返回的 server_is_overloaded 错误码,意思就是“服务器过载”。客户端并没有一个专门表示“你被标记了”的版本。
2026 年 9 月 8 日新模型发布后,OpenAI 的 Codex 仓库里涌现了大量这类报告,其中一个汇总帖提到,命令行、IDE 插件和网页版同时出现问题,很多是用官方客户端的 Pro 付费用户。OpenAI 的状态页同期也记录了多起错误率升高的事件。
也有反代项目的开发者在代码提交说明里推测,服务端会按请求所声称的客户端类型分配容量,落在“降载”分组的请求更容易收到这个错误。这是开发者的观察,OpenAI 没有确认。
所以,看到 “at capacity”,先当作服务器忙;它本身证明不了你被标记,更证明不了 IP 有问题。 换 IP 解决不了服务器过载。
七、IP 真正会影响什么
说没有证据表明 IP 导致降智,不代表 IP 什么都不影响。实事求是地讲,OpenAI 的帮助中心明确写到了这几类与 IP 或地点有关的情况:
- 地区准入。 OpenAI 公布了支持的国家和地区名单(目前不包括中国大陆),并说明在名单之外访问或提供访问,可能导致账号被封禁或暂停。更换网络出口,并不改变你是否具备使用资格。
- Cloudflare 拦截。 出现 “Sorry, you have been blocked” 时,官方说明提到 IP 被拦截、部分 VPN 使用和高风险地理位置都可能是原因。
- 异常活动提示。 系统检测到疑似自动化或异常的流量时,会出现 “Unusual activity” 提示。
- 安全信号之一。 从陌生地点登录、多地同时登录等情况,可能触发可疑活动提醒,甚至影响部分功能或模型访问权限。
也就是说,IP 和登录地点不只影响“能不能打开”,也可能作为安全信号之一,影响账号的部分功能。 但这和“VPN 会让模型变笨”不是一回事:OpenAI 的公开文档里找不到“VPN 或机房 IP 会降低模型回答质量”的说法,现有资料也没有证明换一个所谓“纯净 IP”能恢复模型能力或解除账号限制。
八、遇到降智,可以怎么办(参考)
下面这些做法整理自 OpenAI 官方文档、GitHub 讨论和社区经验。OpenAI 没有公布降智的官方修复方法,以下内容仅供参考,都不保证有效。
第一步:先判断是哪一种问题
- 看官方状态页。 打开 status.openai.com,如果有与你症状相符的事故,先保存进度、等待恢复;恢复后仍异常,再继续排查。
- 查额度。 在 Codex CLI 会话中使用
/status查看当前套餐和用量(官方说明),排除“只是额度用完了”。其他客户端按各自界面查看。 - 提交反馈。 在 Codex CLI 里用
/feedback提交问题,会生成一个反馈 ID,方便 OpenAI 对照后台日志排查。不少 GitHub 报告都附上了这个 ID。
遇到 “at capacity”:先续上,再换模型
- 不要急着丢掉当前对话。 有开发者分享经验:在原会话里发一句“从中断的地方继续”,有时就能接着跑。可以一试,但不保证成功。
- 继续不行,再用
/model切换模型。 高峰期不同模型的拥挤程度不同,但因为问题出在服务端,换模型也可能撞上同一堵墙。 - 长任务记得存档。 把阶段性成果随时保存到文件或 Git 里,这样即使一轮对话被中断,也不会丢掉进度。
遇到降智:减少变量,回到正常用法
- 用官方客户端和自己的账号建立基线。 用同一道题,在官方 Codex CLI、自己的账号下测几次,作为对照。第二节那位作者在当时的测试中,直接登录的表现更好;但这不是通用的修复保证,官方客户端也有类似异常的报告。
- 停止共享账号,退出各种“拼车”和号池。 这既是 OpenAI 条款的要求,也是 Codex 负责人点名会被标记的用法。
- 尝试换一个模型。 有用户在 OpenAI 的 Codex 仓库提交了一份统计报告,发现推理 token 卡在 516 的现象集中出现在特定模型上,同期部分其他模型几乎没有出现。遇到明显“卡 516”时,可以试着换一个模型完成任务。
- 单纯调高推理强度,未必有用。 同一讨论中有人反馈,调到最高档依然会卡在同一个边界。
- 在 AGENTS.md 里减少“汇报进度”。 有用户在项目的 AGENTS.md 中加入类似“不需要通过 commentary 频道汇报进度,把时间花在思考上”的指令,自称有所改善;也有人说效果有限。这会减少进度提示,只能算有限的社区经验,不是修复;如果尝试,建议保留遇到错误、阻塞和需要确认时的提示。
- 给账号一点时间。 有用户报告,闲置或等待一两天后表现恢复了,也有人之后再次出现异常。恢复的原因和时间都不确定,不能把等待当作已验证的办法。
进阶:自己测一测,而不是凭感觉
- 糖果题测试。 开源项目 codex-candy-eval 把第二节那道正确答案为 21 的题做成了脚本,可以按模型和推理强度批量测试。
- 检查模型标识与响应特征。 is-gpt-nerfed 等社区工具会分析响应中返回的模型标识或统计特征,具体方法随版本变化。标识不一致可以作为排查线索,但不能单独证明账号被风控,或者实际运行的是哪个模型。
- 注意测试的局限。 这些都是社区工具,不是官方基准;据用户转述,OpenAI 客服也曾表示社区流行的某些测试题并非官方基准。多测几次、对照着看,比一次结果更可靠。
不建议的做法
- 频繁换 IP、换国家“洗号”。 前面的案例说明,换 IP 并不保证改善回答质量;而频繁更换登录地点,反倒可能触发可疑活动提醒。
- 伪装客户端身份来绕过限制。 已经有反代项目在伪造官方客户端的身份信息。不要用这种方式绕过服务方的访问限制或保护措施。
- 购买或参与共享账号、号池。 把个人订阅共享、转售给多人使用,违反 OpenAI 条款,也有账号受限的风险。需要把几种情况分开看:个人订阅被转售、自己用第三方客户端登录自己的账号、正规应用调用官方 API,是三回事,不能只凭“反代”“中转”这类名字判断。
九、VilaVPN 能帮你做什么,不能做什么
写这篇文章,一个直接的原因是:常有用户在账号降智后,第一时间怀疑是线路或 IP 出了问题。我们理解这种直觉,但希望把责任边界说清楚。
VilaVPN 能负责的,是网络这一层。 我们建设 IPLC/IEPL 专线架构并针对晚高峰进行线路优化,目标是减少网络侧的延迟、抖动和断流。实际体验仍受本地网络、设备和目标服务影响;服务端的生成速度、容量和会话限制,不由 VilaVPN 控制。如果你遇到异常的长时间停顿或连接中断,可以联系我们,一起排查网络因素。
VilaVPN 管不了的,是账号这一层。 账号层面的限制由服务方判定,VilaVPN 无法判定,也无法解除;我们也不承诺通过换线路改善模型能力。任何声称“换个纯净 IP 就能治好降智”的说法,都值得打个问号。
还要提醒一句:使用任何海外服务前,请先确认你所在的地区在该服务的支持范围内,使用方式也符合其条款和当地规定。更换网络出口不等于获得使用资格,本文也不建议通过更换出口地区绕过地区限制。
我们在上一篇文章里说过:What you see is what you get——所见即所得。 网络的问题,我们认;不是网络的问题,我们也直说。
如果你想评估一条网络在晚高峰的真实表现,可以来了解并尝试 VilaVPN,在自己的设备和实际使用时段里检验它是否适合你。
网络的归网络,账号的归账号。分清楚了,才不会在错误的地方白费力气。
资料核对日期:2026 年 9 月 27 日。文中社区测试均为个人或小样本实验,引用时已注明;OpenAI 官方表态以原文链接为准。本文为 VilaVPN 产品博客,包含产品介绍。