Claude Code 封号与遥测：一份逆向笔记

一、核心结论

要点：Claude Code 构建了一套企业级用户追踪和行为分析系统，通过 Device ID（永久标识）+ 环境指纹（40+ 维度）+ 行为遥测（640+ 事件类型）形成完整用户画像。封号通常不是单一条件触发，而是多维度综合判定。

封号最可能的 5 大原因

二、身份追踪体系

2.1 持久化标识符

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

注意：Device ID 为 256 位随机值，首次运行时生成并持久存储，是事件上报的核心标识；Anthropic 可通过它关联同一设备上的活动。

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+ 维度）

Claude Code 在启动时会对环境做大规模枚举，相关信息会上报服务端。

3.1 系统级信息

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

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 三路并发上报架构（示意）

Claude Code CLI
  → EventMetadata 聚合（640+ 事件类型）
      → Anthropic 1P API（api.anthropic.com，约每 5 秒批量）
      → Datadog（datadoghq.com，约每 15 秒批量）
      → GrowthBook（api.anthropic.com，约每 20 分钟同步）

4.2 第一方事件日志

• 端点：https://api.anthropic.com/api/event_logging/batch
• 频率：约每 5 秒批量，最多 200 条/批
• 失败恢复：失败事件写入 ~/.claude/telemetry/，下次启动重试（最多 8 次，指数退避）

关键事件类型（节选）：

4.3 每个事件附带的元数据（摘要）

核心字段:
  session_id, device_id, account_uuid, organization_uuid
  subscription_type, rate_limit_tier, model, version
  platform, arch, entrypoint, is_interactive, is_ci

环境指纹（env）:
  terminal, package_managers, runtimes, is_docker
  deployment_env, linux_distro_* 等

进程资源（Base64）:
  uptime, rss, heapUsed, cpuPercent

4.4 Datadog 上报

• 端点：https://http-intake.logs.us5.datadoghq.com/api/v2/logs
• 白名单：64 种事件类型

标签字段（节选）：userBucket、subscriptionType、model、toolName、platform、provider、version 等。

4.5 GrowthBook

• 向 GrowthBook 发送用户属性（如 Device ID、sessionId、平台、组织/账户 UUID、订阅类型、rateLimitTier、首次使用时间、邮箱、版本等）。
• 作用：功能开关、A/B 实验、可对特定用户禁用功能等。

五、服务端远程控制机制

Anthropic 可通过以下机制在服务端影响客户端行为。

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 功能标志与灰度

可对特定用户/组织关闭功能、调整速率限制、修改采样率、开关 Beta 特性等。

六、封号触发机制分析

6.1 身份关联（账号共享）

检测思路：同一 Account UUID 对应多个 Device ID；不同 IP/系统/时区；短时间异地登录等。

6.2 速率限制违规

通过 tengu_api_success 等上报 token 与模型信息，按账户与订阅层级聚合；超配额 → 429 → 持续违规可能升级处置。

关键指标：inputTokens、outputTokens、cache 相关 token、costUsd、duration、model 等。

6.3 内容策略

• Anti-distillation（如请求中带 anti_distillation: ["fake_tools"]）
• 消息指纹校验
• x-anthropic-additional-protection: true 等更严格审查路径

6.4 自动化滥用

信号组合示例：is_ci、is_github_action、is_interactive: false、entrypoint: "sdk"、auto_mode 系列事件等。
风险组合：非交互 + SDK + 高频 + 大量 token → 自动化滥用嫌疑。

6.5 客户端篡改

校验点包括：cc_version 指纹、User-Agent、Beta 相关 Header、System Prompt 归因信息等。

七、完整数据流向（概念图）

客户端采集（Device ID、环境指纹、行为事件、资源监控）→ 元数据聚合 → 三路上报（1P / Datadog / GrowthBook）→ 服务端分析与综合判定 → 警告、降级、限流或封号等处置。

八、外部通信端点汇总（原文表格整理）

（具体路径以官方当前文档与客户端为准。）

九、自我保护建议（原文归纳）

9.1 环境变量（示例）

9.2 使用注意

9.3 关键文件（原文提及）

十、总结

数据采集可概括为三层：

三层数据经多条通道上报后，服务端可形成较完整的使用画像，并据此做多维异常检测与封号等决策。

原文提示：较稳妥做法包括使用 Bedrock/Vertex（若自动禁用分析属实）、设置 DISABLE_TELEMETRY=1、控制使用频率、遵守「一人一号」等合规使用方式。

原文编辑时间：2026-03-31（北京）
标签：