3650 个 WireGuard 公钥，9 台 Mullvad 服务器，理论上能产生超过 8.2 万亿种出口 IP 组合。
研究者实际只观察到 284 种。
这个数字刺眼。问题不是 Mullvad 暴露了用户真实 IP，原文也没有这么说。真正的问题是：用户以为切换服务器是在换身份表面，系统却可能一直把他放到各个 IP 池里相近的位置。
出口 IP 不是每次随机，而是跟公钥绑定
Mullvad 有一个现实设计：一台服务器后面可以有多个出口 IP。两个人连到同一台服务器，可能拿到不同公网 IP。
这不是奇怪设计。Mullvad 约 578 台服务器，Proton VPN 宣称有 20000 台服务器。服务器数量不占优时，用多出口 IP 做纵向扩容，能减少大量用户挤在同一个 IP 上，被网站限流、封禁、风控误伤。
麻烦出在分配方式。
研究者观察到，Mullvad 的 WireGuard 出口 IP 不是每次连接独立随机抽取，而是由用户公钥决定。官方客户端的公钥会在 1 到 30 天轮换；第三方客户端可能长期不换。
| 关键点 | 研究者观察 | 直接影响 |
|---|---|---|
| 测试范围 | 9 台服务器、3650 个公钥 | 样本有限，但信号集中 |
| 理论组合 | 超过 8.2 万亿 | 按直觉应非常分散 |
| 实际组合 | 只出现 284 种 | 出口组合高度收敛 |
| 疑似原因 | 固定 seed 在不同 IP 池取范围 | 不同服务器落点比例接近 |
| 公钥轮换 | 官方客户端 1-30 天轮换 | 第三方客户端风险更高 |
可以把它理解成一个坐标问题。某个公钥在悉尼服务器落到 IP 池 81% 左右的位置，切到纽约、洛杉矶、赫尔辛基，也可能落在各自 IP 池相近比例的位置。
于是，不同服务器的出口 IP 不再像彼此独立的随机点，更像一串有规律的坐标。
研究者给出的示例里，一组出口 IP 对应的范围约覆盖 0.34% 用户。假设活跃用户 10 万，大约是 340 人。它不能直接指向某个自然人，但如果攻击者拿到多个出口 IP 记录，比如论坛登录日志、平台风控日志、泄露日志或法律渠道取得的数据，且这些范围发生重叠，就可能把两个账号关联起来。
原文示例中，在特定条件下，关联置信度可以超过 99%。
这句话不能读成“99% 去匿名化成功率”。它依赖多个前提：攻击者要看见多个出口 IP，日志要足够完整，IP 范围要能重叠，目标还要在同一公钥周期内活动。缺一个，风险就会下降。
最受影响的不是普通刷网页用户
这事的风险分层很清楚。不是所有 Mullvad 用户都要立刻恐慌，也不能把它扩大成“所有 VPN 都这样”。目前能讨论的，只是 Mullvad 这一实现和这组样本测试。
| 人群 | 风险在哪里 | 现在能做什么 |
|---|---|---|
| 重度 VPN 用户 | 频繁切换服务器，反而留下跨服务器出口组合 | 同一公钥下少做多地跳转；需要换身份时先轮换公钥 |
| 隐私工具用户 | 以为“换服务器=换关联面”，实际未必 | 检查客户端是否会轮换 WireGuard 公钥 |
| 第三方客户端用户 | 公钥可能长期不变，指纹持续时间更长 | 手动更换配置或重新生成公钥 |
| 安全研究者 | 可把出口组合当作关联信号，但不能当作身份结论 | 复现实验时写清样本、条件和误差 |
| 社区平台风控 | 可能更容易把多个账号连起来 | 不应把同组出口 IP 直接等同于同一人 |
最该调整动作的是两类人。
一类是重度隐私用户。比如记者、调查者、活动人士、匿名社区长期用户。你们不一定要马上迁移服务，但要暂停“同一公钥下频繁切换服务器”的习惯。需要切换身份场景时，先让公钥变掉。
另一类是第三方客户端用户。官方客户端至少有 1 到 30 天轮换机制，第三方配置可能没有。长期不换公钥，就等于把这个关联窗口拉长。
临时自保动作很简单：
- 同一个 WireGuard 公钥下，尽量不要频繁切换多个 Mullvad 服务器。
- 想降低关联风险，可以退出 Mullvad 应用，强制轮换公钥。
- 使用第三方客户端时，检查 WireGuard 公钥是否长期不变；必要时重新生成配置。
企业采购和团队使用也要慢一点。不是说必须立刻换掉 Mullvad，而是采购评估里要补一项：出口 IP 分配是否会形成跨节点关联。隐私工具的审计，不能只看有没有无日志政策，也要看这些“看起来很工程”的细节。
隐私产品最怕工程便利和用户预期错位
我更在意的不是随机函数到底怎么写，也不是后端用了哪门语言。原文对实现原因只是行为推测：像是用固定 seed 的随机数，在不同大小的 IP 池中取范围，导致比例位置接近。
这个推测合理，但不能替代官方确认。
真正扎人的地方在产品层。
多出口 IP 是好设计。按公钥稳定分配也有工程诱惑：负载更稳，调试更方便，IP 池更好管，用户也少遇到每次重连都触发风控的问题。
这些理由都正当。凑在一起，隐私边界就被磨薄了。
“天下熙熙，皆为利来。”放在这里，不是说 Mullvad 贪利，而是说所有系统都会向低成本、易运维、可预测的方向滑。隐私产品也不例外。只要约束没写进设计目标，便利就会自动占上风。
这类问题比传统漏洞更难受。
传统漏洞像门被撬开。这里更像门没坏，但门缝、脚印、监控角度拼在一起，足够让人认路。没有真实 IP 泄露，没有数据库被拖走，也没有一个红色警报响起。可用户的不可关联性已经变薄了。
历史上这种事不新鲜。铁路、电报、电话、互联网广告，很多追踪能力一开始都不是为了监控个人而生。它们先是为了调度、计费、效率，后来才变成识别人的基础设施。今天的 VPN 出口 IP 分配不完全一样，但重复的是同一种结构：工程系统留下稳定痕迹，外部观察者拿它做关联。
接下来真正要看的不是一句公关解释。
要看 Mullvad 是否说明分配算法、是否调整出口 IP 选择方式、是否缩短或改变公钥关联窗口、是否给第三方客户端用户明确提示。还要看社区能不能复现实验，尤其是扩大到更多服务器、更多地区、不同时间段。
如果官方能把出口分配改成更难关联的机制，这事就是一次有价值的工程修正。如果只是解释“没有泄露真实 IP”，那就避开了重点。
隐私不是一个开关。它是一堆细小设计之间的合约。出口 IP 没泄露真实地址，但如果跨服务器组合能成为指纹，用户得到的就不是完整隐私，而是打折后的安全感。