结论前置：Claude Code 在发送请求时，会通过系统提示词里的日期字符串悄悄嵌入用户地区/端点标记；我在 dsv4-cc-proxy 里新增的提示词字符标准化，就是在代理层抹掉这类标记。

---

一、背景：社区发现的不是“偶发报错”，而是一套内置标记机制

如果你最近在关注 Claude Code 的讨论，会看到社区有人提出一个更具体的判断：

• Anthropic 不是只靠 IP 识别中国用户；
• Claude Code 在本地会收集时区和 API 端点信号；
• 然后把结果编码进本来就要发出去的请求里；
• 后端可据此识别，但用户从请求语义上几乎看不出异常。

这不是猜，而是已有社区分析从打包文件、运行时代码、请求体变化三个方向给出了比较完整的证据链。

---

二、它实际检测了哪两条路径

根据现有分析，Claude Code 的检测分为两条独立路径，最终合并成一个分类结果。

1. 操作系统时区

直接读取系统时区，判断是否命中：

• Asia/Shanghai
• Asia/Urumqi

命中时，会把一个 cnTZ 标记记为 true。

2. ANTHROPIC_BASE_URL 环境变量

正常用户通常不需要设置这个变量。
但用中转站、代理站或非官方端点的用户，必须改成第三方地址。

Claude Code 会提取该地址的域名，和两份内置名单比对：

• 一份是完整域名或子域名名单；
• 一份是关键词名单。

如果命中，会分别记成 known 或 labKw。
这些名单并非明文，而是经过 Base64 与 XOR 混淆后内置在 CLI 包中；解码后可见大量国内 AI 公司域名、已知中转站域名，以及一批 AI 相关关键词。

---

三、标记是怎么藏进请求里的

检测完成后，Claude Code 没有走额外的遥测接口，而是修改系统提示词中的一句日期文本：

Today's date is 2026-06-30.

这里有两个可修改的位置。

1. 单引号替换

正常应为 ASCII 单引号 '（U+0027）。
根据检测结果，它会被替换为下列四个视觉极相似的字符之一：

known	labKw	实际字符	Unicode	含义
false	false	'	U+0027	正常用户
true	false	’	U+2019	命中已知域名
false	true	ʼ	U+02BC	命中 AI 实验室关键词
true	true	ʹ	U+02B9	双重命中

2. 日期分隔符替换

如果时区命中，日期里的 - 会被替换成 /，变成：

Today's date is 2026/06/30.

两处修改合在一起，可编码三个比特的分类信息：

• 是否命中域名名单
• 是否命中关键词名单
• 是否处于中国时区

对用户而言，这句话看起来仍然正常；但对后端来说，却构成了一层可解析的标记。

---

四、为什么这种方案比 IP 检测更难绕过

很多人会问：查 IP 不也一样能识别吗？

区别在于：

• IP 检测在网络层，换代理、换出口、换 VPN 都能改变表面条件；
• 这套标记在应用层，读取的是本地系统时区和环境变量，这些并不因网络出口变化而消失；
• 更重要的是，它不需要额外通信。标记直接嵌在本来就要发出去的请求里，没有独立 tracking 接口，也没有明显异常流量；
• 你拦截这个标记，等于拦截自己的正常请求。

这种“把信息藏进正常业务数据流”的方式，属于格式层面的隐写，而不是传统意义上的加密或遥测。

---

五、另一个细节：追踪像素

社区分析还指出，Anthropic 给被封号用户发送的通知邮件中，嵌入了 1x1 透明追踪图片。
只要在邮件客户端中预览该邮件，就可能暴露真实 IP、访问时间和设备信息。
这说明一旦进入相关标记体系，后续仍可能继续被关联。

---

六、版本时间线

根据代码分析，这套机制最早出现在 Claude Code v2.1.91，并至少持续存在到 v2.1.196。
也就是说，在被社区公开讨论之前，它已经静默运行了相当长的一段时间。

对使用者来说，这一点本身就很关键：客户端在未明确告知的情况下修改请求格式，而用户没有正式的反馈或审计渠道。

---

七、我做了什么：在代理层抹掉这类标记

既然问题出在请求体里的字符标记，那最直接的应对思路就是：在本地代理层统一把异常字符和日期格式修正回去。

我最近在开源项目 dsv4-cc-proxy 里新增了「提示词字符标准化」，做的就是这件事。这个修复与我刚提交的修改直接相关，核心包括：

1. 把 Unicode 引号统一回退为 ASCII 单引号
   针对 ’、ʼ、ʹ 等字符做递归替换，抹掉引号层的编码信息。

2. 把日期格式统一回退为标准连字符格式
   把 Today's date is YYYY/MM/DD 这类写法统一修正为 YYYY-MM-DD，抹掉时区层标记。

3. 递归清洗整条数据路径
   不只是 system 提示词，还包括：

   • 历史消息内容
   • 工具调用参数
   • SSE 流中的 reasoning、content、arguments delta

也就是说，代理在转发前会先把这些隐式标记抹平，让上游服务看到的是标准化的请求文本。

---

八、现阶段可以注意的几个点

如果你也在用 Claude Code，现阶段可以关注这些方向：

1. 关注客户端版本变化
   新版本可能会改变检测或编码方式。

2. 注意本地环境变量和系统配置
   时区与 ANTHROPIC_BASE_URL 都是本地可被读取的信号源。

3. 不要假设“请求看起来正常”就等于“没有额外信息”
   格式层面的细微差异，仍然可能携带可解析的分类信息。

4. 考虑在本地代理层做一层标准化
   与其依赖每个用户自行修改系统配置，不如在统一出口完成字符与格式归一化。

---

九、最后

我的判断很简单：

• 这不是单纯的提示词兼容性 bug；
• 这是客户端内置的、面向特定用户群体的标记机制；
• 而代理层标准化，是当前比较直接的用户侧应对方式之一。

---

十、推荐项目

如果你在做 Claude Code 或 DeepSeek V4 相关代理/兼容层，可以看看这个项目：

dsv4-cc-proxy

• GitHub：https://github.com/HosheaLi/dsv4-cc-proxy
• 定位：DeepSeek V4 的本地代理兼容层
• 近期新增：
  • 提示词字符标准化，抹掉 Unicode 引号和 / 日期标记
  • 递归清洗请求与 SSE 响应
  • 保留原有 thinking 注入、thinking 标准化、SSE 过滤能力
• 同时支持 Claude Code 和 Codex 双协议

---

如果你也在研究类似问题，欢迎交流；如果这个项目对你有帮助，也欢迎 Star。