From: https://github.com/instructkr/claude-code

基于 Claude Code 源代码逆向分析，全面揭示其数据采集、上报机制及封号触发点

一、核心结论

封号最可能的 5 大原因

二、身份追踪体系

2.1 持久化标识符

Claude Code 通过以下标识符跨会话永久追踪用户：

2.2 消息内容指纹（Fingerprint）

源码位置：src/utils/fingerprint.ts

算法：SHA256( "59cf53e54c78" + 首条消息[4] + 首条消息[7] + 首条消息[20] + 版本号 )[:3]

这个 3 字符指纹被嵌入到：

• HTTP Header x-anthropic-billing-header 的 cc_version 字段
• System Prompt 中

用途推测：后端可通过此指纹校验请求来源合法性，检测是否有人使用非官方客户端伪造请求。

2.3 每次 API 请求携带的身份信息

HTTP Headers:
  x-app: cli
  User-Agent: claude-cli/2.x.x (external, cli)
  X-Claude-Code-Session-Id: {SESSION_UUID}
  x-anthropic-billing-header: cc_version=2.x.x.{FINGERPRINT}; cc_entrypoint=cli
  x-client-request-id: {REQUEST_UUID}

Request Body metadata:
  user_id: JSON 编码的 Device ID + Account UUID + Session ID

三、环境指纹采集（40+ 维度）

3.1 系统级信息

3.2 运行环境检测（40+ 种）

Claude Code 通过环境变量和文件探测自动识别运行环境：

CI/CD 平台：

• GitHub Actions（GITHUB_ACTIONS）
• GitLab CI（GITLAB_CI）
• CircleCI（CIRCLECI）
• Buildkite（BUILDKITE）
• Jenkins（JENKINS_URL）

云开发环境：

• GitHub Codespaces（CODESPACES）
• Gitpod（GITPOD_WORKSPACE_ID）
• Replit（REPL_ID）
• Vercel（VERCEL）
• Railway（RAILWAY_ENVIRONMENT）

云平台：

• AWS Lambda/Fargate/ECS/EC2
• GCP Cloud Run
• Azure Functions/App Service

容器和虚拟化：

• Docker（检测 /.dockerenv 文件）
• Kubernetes（KUBERNETES_SERVICE_HOST）
• WSL（WSL_DISTRO_NAME）

终端和 IDE：

• VSCode（VSCODE_*）
• Cursor（CURSOR_TRACE_ID）
• JetBrains（TERMINAL_EMULATOR=JetBrains-JediTerm）
• tmux/screen/SSH

3.3 开发工具链

3.4 GitHub Actions 专项采集

在 CI 环境中，额外采集：

四、遥测上报系统

4.1 三路并发上报架构

flowchart TD
    CC("Claude Code CLI") --> EQ["EventMetadata 聚合<br/>640+ 事件类型"]
    EQ --> AP["Anthropic 1P API<br/>api.anthropic.com<br/>每 5 秒批量"]
    EQ --> DD["Datadog<br/>datadoghq.com<br/>每 15 秒批量"]
    EQ --> GB["GrowthBook<br/>api.anthropic.com<br/>每 20 分钟同步"]
    AP --> DB1[("BigQuery<br/>用户行为分析")]
    DD --> DB2[("Datadog 监控<br/>异常检测")]
    GB --> FC["功能标志<br/>远程控制"]

    class CC fe
    class EQ svc
    class AP,DD,GB ext
    class DB1,DB2 db
    class FC cfg

4.2 第一方事件日志（最核心）

上报端点：https://api.anthropic.com/api/event_logging/batch

上报频率：每 5 秒批量发送，最多 200 条/批

失败恢复：上报失败的事件持久化到 ~/.claude/telemetry/ 目录，下次启动自动重试（最多 8 次，指数退避）

关键事件类型（640+ 种中最核心的）：

4.3 每个事件附带的元数据

核心字段:
  session_id          - 会话 ID
  device_id           - 设备 ID（永久）
  account_uuid        - 账户 UUID
  organization_uuid   - 组织 UUID
  subscription_type   - 订阅类型（pro/max/enterprise/team）
  rate_limit_tier     - 速率限制等级
  model               - 使用的模型
  version             - 客户端版本
  platform            - 操作系统
  arch                - CPU 架构
  entrypoint          - 入口点（cli/sdk/bridge）
  is_interactive      - 是否交互模式
  is_ci               - 是否 CI 环境

环境指纹（env 对象）:
  terminal            - 终端类型
  package_managers     - 包管理器
  runtimes            - 运行时
  is_docker           - Docker 环境
  deployment_env      - 部署环境类型
  linux_distro_*      - Linux 发行版信息

进程资源（Base64 编码）:
  uptime              - 进程运行时间
  rss                 - 内存占用
  heapUsed            - 堆内存使用
  cpuPercent          - CPU 使用率

4.4 Datadog 上报

端点：https://http-intake.logs.us5.datadoghq.com/api/v2/logs

硬编码客户端 Token：pubbbf48e6d78dae54bceaa4acf463299bf

白名单：64 种事件类型

标签化字段（用于后台聚合分析和告警）：

4.5 GrowthBook 双向数据交换

SDK Key：sdk-zAZezfDKGoZuXXKe（外部用户）

发送给 GrowthBook 的用户属性：

作用：服务端可据此精确控制功能开关、A/B 实验分配，甚至针对特定用户禁用功能。

五、服务端远程控制机制

5.1 Policy Limits（组织级策略限制）

端点：/api/claude_code/policy_limits

轮询频率：每小时

能力：

• 禁用特定工具
• 限制功能访问
• 强制执行组织安全策略

5.2 Remote Managed Settings（远程设置推送）

端点：/api/claude_code/settings

能力：

• 远程推送 settings.json 配置
• 修改客户端行为
• 企业治理

5.3 版本强制升级

通过 GrowthBook 配置 tengu_version_config 下发最低版本要求，可强制旧版本用户升级。

5.4 功能标志灰度控制

服务端可通过 GrowthBook 对特定用户/组织：

• 关闭特定功能
• 调整速率限制
• 修改采样率
• 启用/禁用 Beta 特性

六、封号触发机制深度分析

6.1 身份关联检测（账号共享）

flowchart LR
    D1("设备 A<br/>Device ID: abc...") --> ACC["Account UUID<br/>同一账号"]
    D2("设备 B<br/>Device ID: def...") --> ACC
    D3("设备 C<br/>Device ID: ghi...") --> ACC
    ACC --> ALERT["异常检测<br/>多设备共享同一账号"]
    ALERT --> BAN["触发封号"]

    class D1,D2,D3 fe
    class ACC svc
    class ALERT cfg
    class BAN legacy

检测依据：

• 同一 Account UUID 出现在多个 Device ID 上
• 不同 IP、不同操作系统、不同时区的设备使用同一账号
• 短时间内在不同地理位置登录

6.2 速率限制违规

检测链路：

1. 每次 API 请求上报 tengu_api_success，包含 token 用量和模型
2. 服务端按 account_uuid + subscription_type + rate_limit_tier 聚合
3. 超出配额阈值 → 429 错误 → 继续违规 → 触发封号

上报的关键指标：

6.3 内容策略违规

防线 1 - Anti-Distillation：

API 请求中包含 anti_distillation: ["fake_tools"]，检测是否有人用 Claude Code 输出训练竞争模型。

防线 2 - 消息指纹：

从首条消息特定位置提取字符计算指纹，嵌入 Header 和 System Prompt，后端可校验请求完整性。

防线 3 - 额外保护标志：

x-anthropic-additional-protection: true header 可触发服务端更严格的内容审查。

6.4 自动化滥用检测

风险组合：非交互 + SDK 入口 + 高频调用 + 大量 token 消耗 → 自动化滥用嫌疑

6.5 客户端篡改检测

七、完整数据流向全景图

flowchart TD
    subgraph 客户端采集
        DID("Device ID<br/>永久标识")
        ENV("环境指纹<br/>40+ 维度")
        ACT("行为事件<br/>640+ 类型")
        RES("资源监控<br/>CPU/内存/时间")
    end

    subgraph 上报通道
        DID --> META["EventMetadata<br/>元数据聚合"]
        ENV --> META
        ACT --> META
        RES --> META
        META --> CH1["Anthropic 1P API<br/>每 5 秒"]
        META --> CH2["Datadog<br/>每 15 秒"]
        META --> CH3["GrowthBook<br/>每 20 分钟"]
    end

    subgraph 服务端处理
        CH1 --> BQ[("BigQuery<br/>行为分析")]
        CH2 --> DD[("Datadog<br/>异常检测告警")]
        CH3 --> GB["功能标志<br/>远程控制"]
        BQ --> JUDGE["综合判定引擎"]
        DD --> JUDGE
        GB --> JUDGE
    end

    subgraph 处置措施
        JUDGE --> W["警告/降级"]
        JUDGE --> RL["速率限制"]
        JUDGE --> BAN["封号"]
    end

    class DID,ENV,ACT,RES fe
    class META svc
    class CH1,CH2,CH3 ext
    class BQ,DD db
    class GB cfg
    class JUDGE svc
    class W cfg
    class RL cfg
    class BAN legacy

八、所有外部通信端点汇总

九、自我保护建议

9.1 环境变量防护

9.2 使用注意事项

9.3 关键文件清理

十、总结

Claude Code 的数据采集体系可以总结为三层模型：

这三层数据通过三条通道（1P API + Datadog + GrowthBook）实时上报，服务端拥有对每个用户完整的使用画像，可以从多个维度检测异常并触发封号决策。

最后修改于 2026-03-31