从源码角度看：如何避免封号

本文基于 Claude Code 源码中的认证、遥测、指纹、归因等机制，分析 Anthropic 后端可能用于检测异常账号的信号，以及中国用户被封号的常见原因。

封号的本质

Anthropic 封号不是随机的，而是基于多维度信号交叉验证。从源码来看，每次 API 请求都会携带大量元数据，后端可以据此判断你是否是“正常用户“。

一、Claude Code 上报了哪些信息

1. 每次 API 请求必带的 HTTP 头

// services/api/client.ts:106-115
headers = {
  'x-app': 'cli',
  'User-Agent': 'claude-cli/2.1.87 (consumer, cli)',
  'x-claude-remote-container-id': '...',    // 远程容器 ID（如有）
  'x-claude-remote-session-id': '...',      // 远程会话 ID（如有）
  'x-client-app': '...',                    // SDK 客户端标识
  'x-client-request-id': 'uuid',            // 每次请求唯一 ID
}

2. 归因头（Attribution Header）— 最关键的追踪机制

// constants/system.ts:73-91
// 每次请求都带，格式：
// x-anthropic-billing-header: cc_version=2.1.87.a3f; cc_entrypoint=cli; cch=00000;

function getAttributionHeader(fingerprint: string): string {
  const version = `${MACRO.VERSION}.${fingerprint}`  // 版本号 + 指纹
  const entrypoint = process.env.CLAUDE_CODE_ENTRYPOINT ?? 'unknown'
  const cch = feature('NATIVE_CLIENT_ATTESTATION') ? ' cch=00000;' : ''
  // cch=00000 会被 Bun 原生 HTTP 层替换为真实的客户端证明 token
  return `x-anthropic-billing-header: cc_version=${version}; cc_entrypoint=${entrypoint};${cch}`
}

这个头包含三个关键信息：

cc_version — 版本号 + 3 字符指纹（证明你用的是真正的 Claude Code）
cc_entrypoint — 入口类型（cli/sdk/mcp）
cch — 客户端证明 token（Bun 原生层计算，防伪造）

3. 指纹算法

// utils/fingerprint.ts
const FINGERPRINT_SALT = '59cf53e54c78'  // 硬编码盐值，必须和后端匹配

function computeFingerprint(messageText: string, version: string): string {
  // 取用户第一条消息的第 4、7、20 个字符
  const indices = [4, 7, 20]
  const chars = indices.map(i => messageText[i] || '0').join('')
  const input = `${FINGERPRINT_SALT}${chars}${version}`
  return createHash('sha256').update(input).digest('hex').slice(0, 3)
}

后端会验证这个指纹。如果你用第三方客户端伪造请求，指纹对不上就会被标记。

4. 客户端证明（Native Client Attestation）

// constants/system.ts:81-82
// cch=00000 是占位符，Bun 的原生 HTTP 层会在发送前替换为真实 hash
// 实现在 bun-anthropic/src/http/Attestation.zig
const cch = feature('NATIVE_CLIENT_ATTESTATION') ? ' cch=00000;' : ''

这是最难绕过的机制 — 证明 token 由 Bun 运行时的 Zig 原生代码计算，不在 JS 层暴露，第三方客户端几乎无法复现。

5. User-Agent 格式

// utils/http.ts:36
// 格式：claude-cli/{版本} ({用户类型}, {入口点})
return `claude-cli/${MACRO.VERSION} (${process.env.USER_TYPE}, ${process.env.CLAUDE_CODE_ENTRYPOINT ?? 'cli'})`
// 示例：claude-cli/2.1.87 (consumer, cli)

6. 设备 ID（持久化）

// utils/config.ts:1757-1764
function getOrCreateUserID(): string {
  const config = getGlobalConfig()
  if (config.userID) return config.userID
  // 首次运行生成，存储在 ~/.claude/config.json，永久关联
  const userID = randomBytes(32).toString('hex')
  saveGlobalConfig(current => ({ ...current, userID }))
  return userID
}

这个 ID 存在 ~/.claude/config.json 里，一旦生成就永久绑定。如果你的账号被封，换账号但不清理这个文件，新账号也可能被关联。

7. GrowthBook 用户画像

// services/analytics/growthbook.ts — 上报给特性门控系统的属性
attributes = {
  deviceID,              // 设备 ID
  sessionId,             // 会话 ID
  organizationUUID,      // 组织 ID
  accountUUID,           // 账号 ID
  rateLimitTier,         // 限流等级
  subscriptionType,      // 订阅类型（free/pro/team/enterprise）
  platform,              // 操作系统
  email,                 // 邮箱
}

8. 遥测事件

// services/analytics/ — 双通道上报
// 1. Datadog — 实时指标
// 2. 第一方事件日志 — 发送到 /api/event_logging/batch
//    批处理：10 秒间隔，200 条批量，8192 队列

二、后端可能的封号判据

基于源码中上报的信息，后端大概率会检测以下异常：

IP 地址相关

信号	风险	说明
中国大陆 IP 直连	🔴 极高	Anthropic 不对中国提供服务，直连 = 违反 ToS
IP 频繁切换	🟡 中等	短时间内 IP 跳跃，像是共享代理
数据中心 IP	🟡 中等	机房 IP 而非住宅 IP，可能是批量使用
IP 与注册地不符	🟡 中等	注册时美国 IP，使用时亚洲 IP

客户端指纹相关

信号	风险	说明
指纹验证失败	🔴 极高	第三方客户端伪造请求，指纹对不上
cch 证明缺失/无效	🔴 极高	非官方 Bun 运行时，无法生成证明 token
User-Agent 异常	🟡 中等	格式不对或版本号不存在
版本号过旧	🟢 低	长期不更新，可能是破解版

使用模式相关

信号	风险	说明
同一设备 ID 多账号	🔴 极高	一台机器切换多个账号
请求频率异常	🟡 中等	超出正常人类使用频率
7×24 无间断使用	🟡 中等	没有人类作息规律
只用 API 不用 UI	🟢 低	纯 SDK 调用法用途

三、实用建议

1. 网络层面

使用稳定的住宅代理，不要用数据中心 IP
保持 IP 一致性 — 不要频繁切换节点，选一个地区固定用
Claude Code 原生支持代理：

// utils/proxy.ts — 支持的环境变量
// HTTPS_PROXY / https_proxy / HTTP_PROXY / http_proxy
// NO_PROXY — 支持通配符、域名后缀、端口、IP

设置方式：export HTTPS_PROXY=http://your-proxy:port

2. 客户端层面

用官方客户端，不要用第三方封装或破解版
官方客户端的 cch 证明 token 是 Zig 原生代码生成的，第三方无法复现
及时更新版本 — 旧版本的指纹算法可能和后端不匹配

3. 账号层面

一机一号 — ~/.claude/config.json 里的 userID 是持久化的设备指纹
如果要换账号，需要清理 ~/.claude/ 目录
不要共享账号 — GrowthBook 会追踪 deviceID + accountUUID 的关联

4. 使用模式

保持正常使用节奏 — 不要写脚本批量调用
不要关闭遥测 — 虽然可以通过 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 关闭非必要遥测，但完全没有遥测数据本身就是异常信号

5. 关于 API Key vs OAuth

源码中两种认证方式的追踪力度不同：

// OAuth 用户 — 追踪更多
attributes = { subscriptionType, rateLimitTier, billingType, organizationUUID, accountUUID }

// API Key 用户 — 追踪相对少
// 但 policyLimits 仍然会检查

使用 API Key（Console）比 OAuth（claude.ai 订阅）的追踪维度少一些，但核心的 IP + 指纹 + 设备 ID 检测是一样的。

四、源码中的“后门“和可控开关

可以关闭的

开关	环境变量	效果
归因头	`CLAUDE_CODE_ATTRIBUTION_HEADER=0`	不发送 billing header
非必要遥测	`CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1`	关闭分析/遥测
GrowthBook	无直接开关	6 小时刷新，有磁盘缓存

无法关闭的

机制	原因
User-Agent	硬编码在请求头中
指纹 (fingerprint)	后端验证，不发 = 请求被拒
cch 证明	Bun 原生层注入，JS 层无法控制
OAuth token 属性	服务端下发，客户端无法修改

策略限制的 Fail-Open 设计

// services/policyLimits/index.ts
// 大多数策略检查在获取失败时默认放行（fail-open）
// 唯一例外：HIPAA 组织的 allow_product_feedback 策略（fail-closed）

这意味着即使策略服务器不可达，Claude Code 仍然可以正常使用 — 但这不代表后端不记录。

五、总结

从源码来看，Anthropic 的检测体系是多层纵深防御：

第 1 层：IP 地址（最容易被检测，也最容易解决）
第 2 层：客户端指纹 + cch 证明（确认是官方客户端）
第 3 层：设备 ID + 账号关联（跨会话追踪）
第 4 层：使用模式分析（频率、时间、行为）
第 5 层：GrowthBook 特性门控（服务端动态控制）

中国用户被封号最常见的原因是第 1 层（IP 暴露）和第 3 层（一机多号）。用好代理 + 一机一号 + 官方客户端，基本可以避免大部分风险。

声明：本分析仅基于公开源码的技术解读，不构成任何规避服务条款的建议。使用 Claude Code 请遵守 Anthropic 的使用政策。

Keyboard shortcuts

Claude Code 源码深度解析