1. 两套凭证，不要混用

VVCMS 有两套完全不同的凭证，用途和传输方式都不一样：

常见错误：拿后台登录态的 VToken 去调外部接口，或者反过来。两者不通用。

另外说明一个历史变更：早期的 XToken 已彻底废弃，现在只认标准 Bearer 头。如果你在旧脚本里还写着 XToken，会一直 401。

2. Token 泄露后的处置步骤

按顺序做，不要只做第一步：

1. 轮换 Token。让用户重新生成 token（后台有重置 token 的能力），旧 token 立即失效。这是唯一能真正止血的动作。
2. 查事件日志。后台「系统管理 → 系统日志 → 事件日志」可以看到该时间段内的操作记录，model 字段区分来源：admin（后台）、api（外部接口）、mcp（MCP 调用）。重点看有没有非预期的增删改。
3. 看失败记录。审计会记录失败的操作（state 为 2）。反复失败的删除或上传尝试往往比成功更有排查价值。
4. 检查授权与用户。确认没有被新建的管理员账号，确认授权状态正常。
5. 清理泄露点。代码仓库、日志、聊天记录里的明文 token 都要清掉；已经进 Git 历史的，轮换比删除历史更实际。

3. 日常防护建议

• 不要把真实 Token 写进代码仓库、文档或聊天记录。用环境变量或配置注入。
• 生产环境通过 HTTPS 访问。Bearer Token 在网络上明文传输，HTTP 等于把凭证裸奔。
• 配合网关白名单或网络隔离。外部 API 和 MCP 接口建议只在内网或白名单内开放。
• 开启认证失败锁定。它能挡住暴力尝试，但注意反向代理场景下要打开 trust_proxy 才生效。
• 定期轮换。尤其是给第三方系统用的 token。
• 不要用管理员 token 做日常接口调用。MCP 要求管理员权限，这意味着 token 一旦泄露就是全量权限，务必单独创建专用账号。

4. 几个容易忽略的点

• 未带凭证的请求不会被锁定机制计数，这是为了避免误伤正常访问；反过来说，扫接口但不带 token 的行为不会触发锁定。
• 文章访问密码不会通过 MCP 返回。get_article 会把 password 字段置空，这是刻意的安全处理。
• 审计 IP 可能不准。限流用的是不信任代理头的客户端 IP，审计记录用的是信任 X-Forwarded-For 的 IP，两者口径不一致——代理环境下审计里的 IP 有被伪造的可能，排查时要结合其他信息交叉验证。