CPA 认证文件被盗？千万级 Token 消耗下的紧急止损指南

这几天折腾服务器的经历，真给我上了一课：在公网上裸奔，代价可能是你想象不到的“天价账单”。

事情是这样的，我有个 Codex Pro 的号，因为大家都懂的“网络问题”，我把 CPA（Codex Proxy/API 之类的代理转发服务）架在了 AWS 的 EC2 上，然后让国内的机器直接去连国外的这个节点。

问题出在哪？ 我为了图省事，给 CPA 管理后台设置的密码过于简单了。

起初没太注意，直到这两天发现额度掉的飞快。一开始我还天真地以为是不是官方搞限制，触发了什么“降额度”的 Bug。结果今天早上起来一看后台，整个人瞬间清醒了——昨天的 Token 消耗记录竟然高达 11 亿！

一夜之间 Token 消耗量飙升到 11 亿，显然不是正常使用轨迹。

这显然不是正常使用，绝对是认证文件或者服务接口被别人盗用了。这 11 亿 Token 如果是按高阶模型算，那一夜的流量费估计能让人肉疼好几天。

第一时间：切断止血

发现问题后，我立刻去 AWS 后台做了几件事，如果你也遇到类似情况，这几步是必须的优先级：

1. 修改 EC2 安全组（Security Group）： 这是最关键的一步。我以前图方便，可能开放了全网段或者配置过于宽泛。现在直接改成 只允许国内特定机器的 IP 访问 EC2 的 CPA 端口。彻底封堵其他人扫描和连接的路径。
2. 修改 CPA 服务密码与端口： 原来的弱密码肯定是不能用了，直接换成了复杂的强密码。顺手把服务端口也改了，防止有人还在扫之前的旧端口。

做完这些，血算是止住了，但心里的石头还没落地。最核心的问题来了：如果认证文件已经泄露，光改服务器的配置够吗？

核心疑问：改账号密码有用吗？

我去搜了不少大佬的经验，大家普遍给出的方案是：修改绑定的 GPT 账号密码，并重新进行认证。

这个方案逻辑上是通顺的，也是目前最彻底的办法。为什么？

因为 CPA 这类工具在运行时，本质上是通过一个认证文件（auths.json 或类似的配置）来向官方 API 验证身份的。如果这个文件被黑客拖库了，他们手里就有了合法的“通行证”。即便你改了自己代理服务的密码，只要他们手头的认证文件还有效，他们完全可以绕过你的代理，或者利用你泄露的信息去消耗你的额度。

具体的操作流程建议如下：

1. 源头止损： 登录你购买 Codex Pro 或相关服务的官网，把绑定的邮箱或账户密码直接改掉。如果支持设备管理，强制下线所有设备。
2. 吊销旧凭证： 在官方后台查看是否有“API Keys”或“Sessions”管理页面，把之前生成的旧密钥全部删除或失效。
3. 重新认证： 回到你的 CPA 服务器，删除旧的不安全的认证文件。重新运行认证流程，生成新的 auths 文件。
4. 环境隔离： 这一步是痛定思痛后的优化。尽量不要让承载 API 转发的服务器直接暴露在公网。如果条件允许，可以考虑使用 VPC 对等连接，或者加一层 Nginx 做反向代理并开启 Basic Auth，增加一道防线。

痛定思痛：几个保命的小建议

这次教训虽然惨痛，但也让我对服务器安全有了新的认识。给同样喜欢折腾 VPS 和 API 中转的朋友提个醒：

• 弱密码是大忌： 永远不要以为“没人会扫我这个 IP”。公网上的恶意扫描是无时无刻不在进行的，SSH 端口、Web 服务端口，只要有缝隙就会有人钻。密码一定要包含大小写、数字和特殊符号。
• IP 白名单是王道： 对于这种只给自己用的代理服务，严格限制访问 IP 是最有效的安全手段。只允许你的家庭宽带 IP 或国内服务器 IP 访问，其他所有流量全部拒绝。
• 定期检查账单： 不要等到月底才看账单。对于按照 Token 计费的服务，最好每天或者每两天看一眼控制台的消耗曲线。异常的突增往往说明问题。
• 不要相信“默认配置”： 很多一键脚本为了省事，默认配置的安全性都不高。跑起来之后，第一件事就是把默认端口和默认密码改掉。

写到最后

看到那 11 亿 Token 的消耗记录时，确实慌了一下。好在及时补救，没有造成更大的损失。如果你也在用类似的架构配置服务，不妨现在就去检查一下你的安全组设置和密码强度。安全这东西，真不出事还好，一出事就是真金白银的代价。

希望大家的服务器都稳如老狗，别再踩我这种坑了！