很多人说「我就是打开了封邮件，号就没了」。这话里有一半是真的，但归因错了地方 —— 错在哪里，决定了你下次该防什么。
开信 ≠ 封号。两件事都真实存在，但强度差得很远。
本页所有数字都是你这台机器此刻的真实读数，进页面就已经采集完了， 不是示意图。每个英文字段下面都有中文解释。
下面拆的三封邮件都是公开渠道收集的样本，彼此没有关系，只是拿来讲机制。 所有收件地址、令牌、域名都已脱敏。真实案例部分单独放在后面，和这些样本无关。
三封真实的 Claude 邮件源码：一封登录魔法链接，走 SendGrid；一封营销推送，走 Iterable + Mailgun； 一封账号停用通知，也走 SendGrid。三套追踪设计完全不同， 这直接决定了「打开」这个动作能泄露多少。
| 项 | 登录邮件（SendGrid） | 营销邮件（Iterable） |
|---|---|---|
| 1×1 开信像素 | 有。wf/open?upn=u001.mfmMJ…，令牌唯一 |
没有。12 个图片全过了一遍，没有 1×1，也没有带令牌的 |
| 图片 URL 是否带收件人标识 | 否（除像素外） | 否。10 个是 assets.claude.ai/lifecycle/<内容哈希>.png，
2 个是 library.iterable.com/<项目ID>/<模板ID>/… ——
都是 campaign 级别的公共资源，同一批人人相同 |
| 点击追踪链接数 | 7 个（页尾 Help / Privacy / 社交） | 21 个（全文 22 个链接，只有退订那个没被改写）。 包括头部 logo、568px 大图、页尾 logo、 两个应用商店徽章、4 个社交图标、点赞/点踩 |
| 关键按钮 | clicktracking="off"，不改写，直连 |
全部改写为 links.email.claude.com/s/c/<每人唯一令牌> |
| 纯文本备份里的链接 | — | 换成了裸链 + utm_content=inline_link，
不带个人令牌 |
| 头部里的收件人标识 | VERP 退信地址 | X-Mailgun-Sid base64 解出
["7eeb2","<收件别名>","e2989d"]；
X-Mailgun-Variables 里还有 Iterable 的
recipientUserKey UUID |
那封营销邮件没有开信像素。12 个图片全是 campaign 级别的公共资源， 同一批收件人拿到的 URL 一模一样。
所以当你只是「打开看了一眼」——
Anthropic 那侧只会收到几个来自某个 IP 的普通图片请求，
没有任何字段能把它对应到 <收件别名>。
「打开就暴露身份」这条路，在这封邮件上技术上不成立。
营销邮件正文开头塞了几百个   ͏ ­。
这不是追踪，是防止 Gmail 在收件箱列表里把正文当预览摘要显示。
地址栏里的 54‌​8 M‌a‌r…
也是同一类手法 —— 用零宽字符把 548 Market St 拆开，绕过垃圾邮件规则的字符串匹配。
两者都属于投递优化，跟你无关。
这封「你的账号已被停用」的邮件，追踪设计和前两封都不一样 —— 它该有的全有， 而且多了一样东西。
| 发现 | 说明 |
|---|---|
| 1×1 开信像素 | 有，令牌唯一。正文最后一个标签就是它 |
| 正文 6 个链接 | 全部改写。包括「登录申诉」那一个 —— 去申诉的动作本身就被记了一次 |
From 和 Reply-To |
都是 no-reply-<唯一令牌>@mail.anthropic.com。
你回信也是一次身份确认，而且回信里会带上你真实邮箱 |
Reference: TS-019fa508-… |
这是 UUIDv7，前 48 位就是毫秒时间戳。
解出来 2026-07-27T19:24:08.524Z，
和邮件 Date 头精确到秒对上 |
工单号一般被当成不透明字符串，但 UUIDv7 是按时间排序设计的， 时间戳明文躺在前 12 个十六进制位里。任何人拿到这个号， 都能反推出这条记录在数据库里被创建的精确毫秒。
对收件人来说这其实是好事：它给了一个可核对的时间锚点。 如果多个账号的 Reference ID 解出来的时间挨得很近， 那说明它们是同一批处理任务里出来的 —— 也就是被批量判定的， 不是逐个人工审的。
假设你在 Gmail 网页版打开。Gmail 在存这封邮件的时候改写了 HTML：
每个远程 URL 前面都被套上一层 ci3.googleusercontent.com/meips/…，
真实地址被塞到 # 后面。
GoogleImageProxy
手机上的邮件 App 大多不走这层代理。 Gmail 手机客户端、系统自带邮件、QQ 邮箱 App、Outlook 移动端 —— 这些环境下图片请求直接从你的手机发出去， 源 IP 就是你当时的蜂窝或 WiFi 出口。
换句话说，「Gmail 帮你挡住了」这个安全感，只在你用网页版的时候有效。 这是本页后面案例复盘里的关键变量。
两条独立的 TCP 连接。你的浏览器从头到尾没和 Anthropic 通过一次话。 不是信息被过滤掉了 —— 是它物理上不在第二段连接里。
| 信号 | 登录邮件 | 营销邮件 | 强度 |
|---|---|---|---|
| 「这封被打开了」+ 时间戳 | 能 | 不能（无像素） | 弱 |
| 「邮箱托管在 Google」 | 能（UA 自报） | 能 | 弱 |
| 打开延迟（发信到回源隔多久） | 能 | 只能到图片级 | 弱 |
| 真实 IP / 城市 / ISP | 不能 | 不能 | — |
| Chrome 版本 / 系统 / 屏幕 / 显卡 | 不能 | 不能 | — |
| 时区 / 语言 | 不能 | 不能 | — |
| Cookie | 不能（代理不传，也不许种） | 不能 | — |
Google 代理缓存很激进：你第二次打开通常不回源，少算。 反过来，代理可能在收信时就预取，在你真正看之前就产生一次「已打开」，多算。 这个数字发件方自己也不该太当真。
下面是你这台机器刚才访问本页时真实交出去的东西。 如果邮件里那张图是你的客户端直连抓的（手机 App 基本都是）， 发件方拿到的就是这些 —— 一个字段都不多，一个字段也不少。
这里面没有显卡、屏幕、字体、Canvas 指纹 —— 因为抓图不执行 JavaScript。 这就是「开信」和「点击」的分水岭：能不能跑 JS，决定了信息量差两三个数量级。
上面那套保护完全取决于你用什么客户端。 「我在手机上打开的」这句话，信息量比大多数人以为的大得多。
| 客户端 | 远程图片怎么取 | 发件方看到的 IP |
|---|---|---|
| Gmail 网页 / 官方 App | Google 代理全量改写 | Google 机房 |
| Apple Mail + 邮件隐私保护（默认开） | Apple 中继代理 | Apple 中继 |
| Apple Mail 关掉隐私保护 | 客户端直连 | 你的真实 IP |
| Outlook / Thunderbird / 第三方 IMAP | 客户端直连 | 你的真实 IP |
| QQ 邮箱 / 163（网页或 App） | 确认后多为直连；部分路径有缓存 | 真实 IP，或腾讯/网易的中国 ASN |
| 「显示原始邮件」 | 纯文本，不加载任何图片 | 无请求 |
用 Gmail 地址不等于走 Gmail 客户端。 很多人邮箱在 Gmail，但手机上装的是系统自带邮件 App 通过 IMAP 收 —— 那条链路上没有任何代理。同一个邮箱，两种客户端，泄露量差一个数量级。
这里才是重点。点一下链接，就是一次真实的浏览器导航，落到发件方自己的域上。 一个网站能知道的，它全都知道。
#
登录邮件的令牌放在 URL fragment 里 —— #<32位十六进制>:<base64>，
后半段 base64 解开就是收件人邮箱明文。fragment 不进 HTTP 请求，
所以首个请求确实不带它。
但页面 JS 会 location.hash 读出来再 POST 给认证接口。
fragment 防的是服务器日志、CDN 日志、Referer 外泄；防不住 Anthropic 自己。
这个设计是对的，只是别误解它保护的是什么。
User-Agent + Client Hints：
Sec-CH-UA-Platform-Version（能区分 Windows 10 / 11）、
-Arch、-Bitness、-Model、
-Full-Version-ListAccept-Language → 语言地区偏好排序，强地域信号Sec-Fetch-Site: none + Sec-Fetch-User: ?1 →
证明这是真人点击的顶层导航，不是预取、不是安全扫描器。
服务端不用任何 JS 就能区分人和机器Referer → 从哪个邮件客户端跳出来的
如果这个浏览器以前访问过 claude.ai，那么点击这一下
把邮件里的令牌和你既有的浏览器身份焊在了一起：
__cf_bm、cf_clearance）这比任何硬件指纹都硬。指纹是概率匹配，Cookie 是确定性关联。
下面不是清单，是你打开本页这一下真实交出去的东西。
你点邮件链接落到 claude.ai 的时候，那边拿到的是同一套字段，
唯一区别是它还拿到了那个能指向你邮箱的令牌。
代理能换掉 IP。但下面这些来自你的操作系统设置和已装软件， 代理碰不到它们。
走代理换掉了 IP，但换不掉 Intl 报告的时区，也换不掉 Accept-Language。
出口节点在某地、时区却是 Asia/Shanghai、语言是 zh-CN ——
这个矛盾本身就是最常用的代理识别启发式。
另外，如果代理不接管 UDP，WebRTC 可能绕过它直连，把真实 IP 漏出去。
这个问题问得准，而且答案分两半 —— 一半让人放心，一半不让人放心。
| 场景 | 能不能读 | 为什么 |
|---|---|---|
你在 claude.ai，它读自己域名的 Cookie |
全部能读 | 同源。而点邮件链接的落地页就是它自己的域， 所以那一刻它读得到你在这个域下的全部登录态和历史标识 |
| 它读别的网站的 Cookie（银行、微信、淘宝） | 读不到 | 同源策略是浏览器最底层的隔离，没有例外。 这条是硬的，不用担心 |
| 它读你的浏览器历史记录 | 读不到 | :visited 探测这类老漏洞早被堵了 |
| 装在它页面里的第三方 SDK（分析、广告） | 读它自己那一份 | SDK 跑在 claude.ai 的页面里，能读 claude.ai 的 Cookie， 还能往自己的服务器回传。但仍然读不到别的站 |
| 跨站追踪 Cookie（第三方 Cookie） | 正在被淘汰 | Safari 和 Firefox 早默认拦了，Chrome 也在收紧。 但指纹和登录态关联填上了这个缺口 |
你的直觉方向是对的，但泄露的东西和「读走你的 Cookie」不太一样。真正流出去的是这些：
这些数据在广告和分析生态里流动，和风控系统是两套东西。 分析平台不会把「这个人是中国用户」直接推给某个厂商的封号流水线 —— 合同、合规、技术管道都不通。
真正需要担心的不是这条，而是第一方自己就够了： 你点一下链接，它不需要问任何人，自己就拿到了完整的一套。
很多人以为清了 Cookie 就断了关联。但同一个域名下还有
localStorage、IndexedDB、Service Worker 缓存、
以及 TLS session ticket —— 浏览器的「清除 Cookie」
往往不动这几样。
再往下还有一层：就算全清了，指纹还在。 显卡型号、Canvas 哈希、字体集合这些不需要在你机器上存任何东西， 每次重新算都一样。往下滚到实测区，看你自己那几个哈希值 —— 它们和你清不清缓存没关系。
换个角度想问题。假设有一个检测方，它的目标函数里只有「别漏掉」，没有「别错杀」 —— 宁可封一万个正常用户，也不放过一个疑似目标。它手上就这些邮件，会怎么用？
这不是阴谋论练习。把攻击面完整列出来，是判断自己该防什么的唯一办法。 下面每一条在技术上都成立。
每封邮件里的每个令牌都是一对一发出去的。这意味着：
这是整条链路上最关键的一步，而它不需要任何高级技术 —— 就是一个带参数的 URL。
一个不在乎错杀的检测方，会把下面这些全部当作正向信号：
| 信号 | 正常解释 | 激进解读 |
|---|---|---|
时区 Asia/Shanghai，IP 在国外 |
华人在海外工作、留学 | 判为规避地域限制 |
| 装着微软雅黑 / PingFang SC | 系统是中文装的，或装过中文软件 | 判为中文用户 |
Accept-Language 里有 zh-CN |
会中文，很自然 | 同上 |
| IP 属于机房 / VPS ASN | 开发者在服务器上跑东西 | 判为代理规避 |
| TCP 握手 RTT 偏高 | 网络差、跨运营商 | 判为物理位置和声称位置不符 |
| 同一浏览器出现过两个账号 | 一个人有工作号和个人号 | 判为多开 / 代开 |
| 邮箱是自有域名的别名 | 很多人这么管理邮件 | 判为批量注册 |
这是最需要理解的一点，也是最让人不舒服的一点。 对平台来说，两类错误的代价严重不对称：
在这个代价结构下，把阈值调低是理性选择，哪怕误杀率上去了。 这不需要谁有恶意，把优化目标写成「最小化漏报」就会自动长成这样。
所以真正的结论不是「他们坏」，而是「不要给系统机会」。 骂设计者改变不了阈值，减少自己产生的信号可以。
这一步设计得很聪明，值得单独讲。那封停用通知里， 「登录申诉」按钮也是带令牌的追踪链接。
于是：
结果是：封号动作本身成了最有效的一次数据采集。 之前所有的推测，在申诉这一下全部变成确认。
一个不在乎误伤的检测方，还可以主动利用邮件的传播特性：
这一节有实证。我拆了一封真实的转发件 —— QQ 邮箱转发给另一个 QQ 邮箱，原始邮件是一封 Claude 登录邮件。结果比预想的严重。
令牌不认人，只认自己。它不知道现在是谁在看， 它只知道自己是发给谁的那一份。所以：
| 转发之后发生的事 | 后果 |
|---|---|
| 第二个人在中国打开 | 原账号新增一条「中国 IP 开信」记录 |
| 第二个人误触了链接 | 原账号新增一条第一方点击，带完整设备指纹 |
| 转发进了群、发到了微信 | 同一个令牌被几十个不同 IP 请求 |
| 被转发给了海外的人 | 同一账号短时间内出现跨洲多地开信 —— 这个模式比单一异地更可疑 |
| 第二个人点了「登录」链接 | magic-link 可能直接被别人用掉， 这是账号安全问题，不只是隐私问题 |
你以为你在分享一封邮件。实际上你在把一个身份令牌交给 n 个陌生的网络环境， 而所有产生的记录全部归到最初那个账号名下。
最讽刺的一点：转发的人自己什么风险都没有。 令牌不指向他。承担全部后果的是原收件人 —— 而他可能根本不知道邮件被转出去了。
「转发」这个按钮的设计目的是把邮件原样递出去。 它做得很好 —— 包括把追踪原样递出去。
一个真实的说法，值得认真拆：
这个对照组很有说服力 —— 两组账号唯一的显式差异就是「有没有在异地打开过邮件」。 但「唯一的显式差异」和「唯一的差异」不是一回事。逐个查。
这封营销邮件没有开信像素。12 个图片全是 campaign 级别的公共资源， 不带任何收件人令牌。抓这些图只会暴露一个 IP， Anthropic 那侧没有字段能把它对到具体哪个账号。
退一步说，就算有像素：这类遥测在 Iterable / Mailgun 那边（营销栈）， 要进风控得跨系统 join，通常是批处理，延迟按小时甚至天算。 对不上「一回去就已经封了」。
这封邮件里有 21 个点击追踪链接，每个都带每人唯一的令牌。 而且它们的位置很要命：
在手机上滑动浏览一封邮件，误触一次的概率相当高。 而误触之后发生的事，从用户视角看只是「弹出一个网页」—— 没人会把它记成「我登录了」。
关键在于：点击带令牌的链接不需要登录，就已经是一次账号归属的请求。
点击 → links.email.claude.com/s/c/<唯一令牌> → 落地 claude.com
<收件别名> 这个收件人点的」结果就是一条实时、第一方、账号归属明确的记录： 这个账号的人此刻在这个国家。这和「登录」在风控数据上几乎等价 —— 而它完全符合「一回去就已经封了」的时间特征。
如果那台手机上装着 Claude App，或浏览器里留着登录态 —— 后台刷新、推送轮询、打开 App 看一眼，任何一个动作都会产生 带 Cookie 的第一方请求，源 IP 就是当地网络。
在这个假设下，开信只是一个时间标记： 它标记了「这台手机当天在这个国家被用了」，而真正被记录的是同一台设备的其他请求。
留在原地那几个号「安然无恙」，因为它们从来没有产生过来自异地的第一方请求。 差异不在「有没有开信」，而在哪台设备、在哪个网络、和服务器说过话。
开信是那台手机当天做的事情里最容易被记住的一件， 所以它成了归因的落点。但它是伴随现象，不是机制。
很多人把自己的域名邮箱、线下办事用的邮箱、各种服务的别名， 统统转发进一个 Gmail 统一收。这是很合理的管理方式， 绝大多数人都这么干。
那么问题来了：这种汇聚，发件方看得到吗？ 先纠正一个我自己一开始搞错的地方 —— 大多数情况看不到。
| 路径 | 发件方能否看到汇聚点 | 说明 |
|---|---|---|
| 转发正常投递成功 | 看不到 | 转发链只存在于你自己收到的那份副本里。 发件方那边只知道「投递成功」，看不到下游去了哪 |
| 转发失败退信（NDR） | 能 | 退信回到 VERP 地址，诊断信息里常带下游目标地址。 一次投递失败就能暴露汇聚点 |
| 你回信 | 能，而且是明文 | 真实邮箱直接出现在 From 里。
停用通知那封的 Reply-To 还带唯一令牌 ——
令牌和真实邮箱同时到手 |
| 图片代理指纹 | 部分能 | 能看出邮箱服务商是 Gmail（UA 里写着
GoogleImageProxy），但看不出具体是哪个 Gmail 账号 |
| 同一浏览器点过多个别名的链接 | 能，而且最硬 | 两个不同令牌，撞上同一份 Cookie、同一个 Canvas 哈希、 同一个显卡串 |
域名可以不同，别名可以不同，账号之间可以毫无关系。 但只要你在同一个浏览器里点过它们的链接， 关联就在那一刻建立了 —— 不是在邮件里，是在你的浏览器里。
邮件层面的汇聚（都进一个 Gmail）基本是安全的， 因为发件方看不到。危险的是浏览器层面的汇聚， 而这一层大多数人从来没想过要隔离。
抛开具体账号不谈，讲通用机制：如果多个账号之间真的存在关联， 下面这些是换 IP 完全无效的。
| 信号 | 为什么显眼 | 能否用代理规避 |
|---|---|---|
| 同一浏览器指纹下出现多个账号 | Canvas 哈希、显卡串、字体集合都一样 —— 确定性关联，不是概率猜测 | 不能 |
| 多账号共用一台服务器出口 | 同一 IP / ASN 上挂着一组独立账号，行为节奏还相似 | 能换 IP，换不掉「聚集」本身 |
| 注册时间、付费卡段的簇状分布 | 批量操作留下的时间和环境相似性，聚类算法专门抓这个 | 不能 |
| 同域名下大量随机词别名 | 用户名是随机生成的，且集中在一个域 —— 和正常人手工起的别名不一样 | 不能 |
| Reference ID 解出的时间聚集 | 多个账号的工单号解出来时间挨得很近 → 说明是同一批任务判定的 | 这条是你能反过来用的 |
如果封号依据是聚合模式，那么同一批账号本来就都在名单上， 区别只是先后。异地那次请求不是「原因」，是触发器 —— 给了一个明确时间点和一条硬证据，把已经积累的怀疑推过阈值。
这个假设有个不太舒服的推论：留下来那几个号不是安全，是还没轮到。
前面几节已经穿插显示了一部分。这里是剩下的全部 —— 你进这个页面的时候，这些就已经采完了，一次点击都不需要。 这正是重点：读取是被动发生的。
Cookie / Authorization
头在服务端代码里直接丢弃源码就那几个文件，可以自己看。真实的追踪方不会给你这份说明。
单个字段本身不算证据。真正把人认出来的是字段之间对不上 —— 下面这几条就是风控系统实际在看的组合判断。
| 浏览器与平台 | 内核版本、操作系统、自动化标志。自动化工具驱动的浏览器 webdriver=true |
| 屏幕与显示 | 分辨率、像素比、色域。少见的分辨率组合唯一性很高 |
| 硬件 | CPU 核心数、内存档位、电池、触控。直接反映设备类型和档位 |
| Client Hints（客户端） | 系统版本、CPU 架构、设备型号。这是浏览器主动交出去的，不是被读取的 |
| 显卡与渲染指纹 | 高熵，最接近唯一。GPU 型号 + Canvas 哈希组合，同型号同驱动的机器才一样 |
| 音频栈指纹 | 离线合成一小段音频取哈希。无声音、无权限，你完全感知不到 |
| 媒体设备与编解码 | 摄像头/麦克风数量（不需要授权）、视频格式支持。能区分设备年代和平台 |
| 网络与时序 | RTT / 带宽估计 / DNS 耗时。跨国链路的握手延迟压不下来，是物理距离的直接体现 |
| 存储 | localStorage / IndexedDB / Service Worker。清 Cookie 通常不清这些，是最容易被忽视的持久化层 |
| CPU 性能画像 | 跑一段固定计算量计时。反映 CPU 性能档位，还能推断当时的系统负载 |
⚠ 如果某一栏是空的，通常是你的广告拦截器或隐私保护插件把对应的采集脚本拦掉了。 遇到这种情况页面顶部会出现一条警告，列出被拦截的具体项目。 暂时停用扩展后刷新即可看到完整数据 —— 这不影响文章内容的阅读。
先把结论摆正：不要因为怕「开信被封」而去优化开信这件事，那不是杠杆所在。
| 做法 | 实际效果 |
|---|---|
| 邮件客户端关闭「自动加载远程图片」 | 有用，成本近乎为零。挡掉开信像素这一层 |
| 不点邮件里的任何链接，需要访问就手输域名 | 最有用的一条。绕开所有点击追踪令牌 |
| 账号和浏览器环境一一对应，不混用 | 有用。切断 Cookie 合并和存储层关联 |
| 只换 IP（代理 / VPN），其他不动 | 效果有限，甚至反向 —— 时区、语言、字体对不上会制造新信号 |
| 要给别人看就截图，不点转发 | 有用。令牌一个都带不出去 |
| 多个邮箱别名转发进同一个 Gmail | 基本安全。发件方看不到转发链 —— 但别让转发失败产生退信 |
| 被停用之后立刻点申诉链接 | 要点，但先想清楚从哪个网络点。 那个按钮也带令牌，申诉动作本身会被记一次 |
| 原样转发邮件给别人 | 最危险的一条。像素和全部令牌实测完整存活， 别人产生的记录全算在你头上 |
| 回复这类系统邮件 | 没必要。Reply-To 带唯一令牌，
回信还会附上你的真实邮箱 |
开信几乎不暴露身份，点击才暴露。 差别在能不能跑 JavaScript，量级是两三个数量级。
转发是放大器。令牌不认人只认自己， 别人打开产生的记录全部算在你账上，而转发的人毫发无伤。
汇聚点在浏览器里，不在邮箱里。 邮件都收进一个 Gmail 没问题；用同一个浏览器点它们的链接才是问题。