最近 OpenAI 升级了风控策略，大砍了部分用户的限额。
作为网页版 Pro 从未被"降智"、挂魔改版 sub2api 三个月未报 401 的幸运儿，今天我们就来探讨下 OpenAI 当前的风控技术。
从风控系统的角度来看，OpenAI 的检测策略可以归纳为两大维度：环境与行为。
环境检测
在我看来，环境 = IP + 客户端特征。
1. IP 质量与滥用标记
先说说最基础的 IP。很多 IP 在 Google 上显示的地理位置会漂移到国内，这是因为部分用户在开启了 GPS 定位系统的设备（如手机）上，使用了该 IP 访问 Google 服务。
权重差异： IP 本身的物理属性（例如是否为家宽原生 IP）的权重，其实是低于 IP 历史使用者行为特征的，不要过分迷信家宽。
机场 IP 的原罪： 账号被 OpenAI 风控，很大一部分原因是 IP 被识别为"存在滥用历史"。一些节点因为使用者鱼龙混杂，且高频并发，往往是 OpenAI 重点"照顾"的对象。
这里顺带 cue 一下隔壁 A÷ 的策略：他们似乎采用了连坐 + 追溯机制。即使你当时使用的 IP 是干净的，只要该 IP 后续因为其他人的滥用被标记，之前用过该 IP 的账号会被全部连坐封禁 😅。这也是为什么有人几个月没登，某天上线突然发现被封号的原因。
2. 客户端特征
客户端特征的检测可以分为被动检测与主动检测两套方案。
被动检测方案：主要包括请求Headers、请求体特征以及 TLS 指纹。像 sub2api 等开源项目在模拟 Agent 发起请求时，由于代码底层实现的问题，是无法做到 1:1 完美复刻官方客户端的。 在建立 HTTPS 连接时，客户端会发送 Client Hello 握手包，里面包含了决定加密方式的参数组合，这就是 TLS 指纹。
不同客户端（如 Chrome、Firefox、Python、Go）的底层代码实现不同，指纹也大相径庭。这在业内反爬领域已有成熟的解决方案。
主动检测方案：这类方案主要针对浏览器端，包括 WebRTC、DNS 泄露和 JS 探针检测等。 WebRTC 和 DNS 可以直接绕过代理泄露使用者的真实 IP。而通过注入 JS 探针，风控系统能静默采集极其详尽的浏览器环境指纹（包括 WebGL 供应商与渲染器信息、屏幕色彩与像素深度、硬件并发线程数、设备内存、最大触摸点等）。即使切换 IP，风控系统也能通过这套指纹定位到屏幕背后的唯一使用者。
除此之外，OpenAI 还会使用工作量证明（PoW）等高级机制验证请求真实性。篇幅有限就不展开细讲了。
Web端Pro 模型对环境的要求极其敏感。部分师傅发现账号被静默路由到了 Mini 模型，本质上就是因为你的客户端环境（IP 或指纹）没过关，触发了降级风控。
行为检测
什么是行为？主要指账号在调用系统时的会话特征与并发模式。
众所周知，OpenAI 用户协议中是严禁多人共享账号的。共享识别机制我猜测至少包含如下：
设备标识符 (installation_id) 异常： 在4月6日的commit中，codex引入了
installation_id作为设备的唯一硬件标识符。如果一个账号在短时间内关联了海量的不同设备，这显然违背了正常单人使用的逻辑。
会话漂移 (session_id / thread_id)： 这些 ID 用于标识唯一会话上下文。如果这些 ID 在多个不同账号之间频繁"漂移"或交叉调用，风控系统基本可以直接判定你在做 API 分发。正常用户是绝不可能多个账号共享同一个Session 的。
高并发与脉冲式用量： 异常的短期超高并发数，以及不符合人类作息的 24 小时高额调用，同样会遭到系统的重点关注与标记。
总结
OpenAI 这次全面更新风控系统，向我们传递了两个明确的信号：
地主家也没余粮了： 部分中转站占用的算力资源把oai薅疼了，决定下场制裁。
"限额降智"作为额外缓冲带引入： OpenAI 聪明地在"正常用户"与"直接封号"之间，加入了一套"降智/限额"策略作为缓冲。这显然是精准针对中转站的钝刀子割肉。
可以预见，OpenAI 这套识别系统后续还会引入更多维度，逐步迭代收紧。随便买台服务器，再在卡网搞几个号就想躺着收钱的时代，已经一去不复返了。
对于做 API 分发的自建中转而言，未来想要在保证"不掺水"的情况下做到"不降智、不降额"，与 OpenAI 风控团队进行底层技术对抗，将成为唯一的生存法则。
声明：本文来自玄月调查小组，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
