Codex 突然“降智”,先别急着怪 IP

43次阅读
一条评论
Spread the love

最近不少人发现,自己的 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,不是一个经过验证的修复办法。

Codex 突然“降智”,先别急着怪 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)反复测试,只改变“谁来发请求”:

Codex 突然“降智”,先别急着怪 IP

据该讨论帖整理:一位用户在 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 或地点有关的情况:

  1. 地区准入。 OpenAI 公布了支持的国家和地区名单(目前不包括中国大陆),并说明在名单之外访问或提供访问,可能导致账号被封禁或暂停。更换网络出口,并不改变你是否具备使用资格。
  2. Cloudflare 拦截。 出现 “Sorry, you have been blocked” 时,官方说明提到 IP 被拦截、部分 VPN 使用和高风险地理位置都可能是原因。
  3. 异常活动提示。 系统检测到疑似自动化或异常的流量时,会出现 “Unusual activity” 提示。
  4. 安全信号之一。 从陌生地点登录、多地同时登录等情况,可能触发可疑活动提醒,甚至影响部分功能或模型访问权限。

也就是说,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 产品博客,包含产品介绍。

正文完
 0
评论(一条评论)
验证码