NodePurify 的 WebRTC 泄漏缓解笔记

WebRTC 泄漏最容易被低估，因为它看起来不像传统的网络请求。

你以为页面只会看到代理出口 IP，但浏览器为了建立点对点连接，会通过 ICE candidate 暴露一部分网络信息。在某些环境里，这可能让页面拿到本地地址、局域网拓扑线索，或者至少得到一组可用于指纹识别的网络候选项。对普通用户来说，这更多是隐私问题；对自动化环境来说，它会变成环境一致性问题。

NodePurify 这类清理工具要处理的，不只是"删缓存"，还包括让浏览器运行时少暴露一些不该暴露的特征。

问题在哪里

WebRTC 的连接协商会收集 ICE candidates。候选项可能来自：

• host candidate：本机网络接口地址。
• srflx candidate：通过 STUN 看到的公网映射地址。
• relay candidate：通过 TURN 中继地址。

如果用户使用代理或隔离网络，但浏览器仍然暴露 host candidate，页面就可能看到和代理出口不一致的网络线索。即使现代浏览器已经收紧了很多行为，自动化环境里仍然要把这个面当成风险项检查。

缓解目标

这里的目标不是把浏览器伪装成另一个完美设备，而是做到三件事：

1. 默认不暴露本地地址。
2. 不让 WebRTC 绕过预期的代理路径。
3. 在不同浏览器配置之间保持可解释、可复现。

换句话说，系统应该减少泄漏面，而不是追求玄学式的"指纹满分"。

浏览器侧策略

Chromium 系浏览器可以从策略和启动参数两层处理。

常见方向包括：

• 禁用或限制 WebRTC 的非代理 UDP。
• 设置 IP handling policy，避免暴露非代理地址。
• 在自动化 profile 中固定相关实验参数。
• 对需要 WebRTC 的站点保留显式例外，而不是全局一刀切。

自动化脚本里最容易犯的错，是只加一个参数就认为问题解决。正确做法应该是启动后跑一次检测页面或自测脚本，确认实际 candidate 行为符合预期。

NodePurify 可以怎么落地

我会把它做成一个清理/启动前检查模块，而不是散落在各个脚本里的参数拼接。

nodepurify
- profile cleanup
- cache cleanup
- browser launch policy
- webrtc leak check
- report

其中 WebRTC 部分至少输出：

• 当前浏览器类型和版本。
• 当前 profile 的 WebRTC 相关配置。
• 是否检测到 host candidate。
• 是否检测到非代理路径候选项。
• 如果检测失败，给出阻断启动或降级运行的明确结果。

报告比静默修复更重要。安全和隐私类工具如果只告诉你"已优化"，实际价值很低；它应该告诉你做了什么、没做到什么、下一步风险在哪里。

不要过度承诺

WebRTC 只是浏览器暴露面的一个入口。Canvas、字体、时区、语言、设备内存、扩展痕迹、自动化特征都可能参与指纹识别。把 WebRTC 修好，并不代表环境就"干净"。

因此文档里应该避免这类表述：

• "彻底防指纹"
• "百分百匿名"
• "绕过所有检测"

更准确的说法是：减少 WebRTC 导致的本地网络信息暴露，并提供可验证的检测结果。

验证清单

第一版我会用下面的清单验收：

• 代理开启时，检测页看不到本地网段地址。
• 禁用策略不会破坏不依赖 WebRTC 的普通浏览。
• 需要 WebRTC 的页面能通过显式配置恢复能力。
• 每次启动都能输出可读报告。
• 配置失败时默认保守，不悄悄继续运行。

这类工具最怕"看起来很安全"。我更想要的是：风险能被看见，配置能被复现，失败能被阻断。