检测网页看到多个IP，应该先判断这些地址属于什么、由哪个机制取得，以及哪些请求原本应由连接工具处理。地址数量本身不能判定泄漏；真正需要调查的是：实际路径是否违背了你已经确认的处理范围。
给“预期路径”写一句明确的话
例如，“浏览器的这次HTTPS请求应经当前代理出口”是可以验证的要求；“开启以后所有软件任何时候都匿名”则过于宽泛。系统代理、隧道模式和分流规则的作用范围不同；DNS、IPv4、IPv6以及浏览器相关机制也不宜混成同一个测试。
| 检测显示 | 首先识别 | 不能仅凭它推断 |
|---|---|---|
| 私有局域网地址 | 是接口信息还是远端看到的地址 | 真实公网出口已暴露 |
| 两个公网地址 | 请求类型、地址族和采样时间 | 两个地址都应相同 |
| IPv4改变，IPv6未变 | 当前模式是否覆盖两类流量 | IPv6本身就是泄漏 |
| DNS检测出现其他服务商 | 解析由谁完成、工具如何命名 | 已确认访问内容被记录 |
私有IPv4地址的用途可参阅RFC 1918；双栈应用可能尝试不同地址族，相关机制见RFC 8305。它们解释地址背景，不能替任何客户端证明其实际路由或隐私实现。
示例：代理浏览器和未代理应用结果不同
假设某工具仅配置系统代理，而另一个应用没有遵循该代理。两个应用访问检测服务时显示不同公网地址，可能符合这个有限覆盖范围；如果你的目标是让后一个应用也使用受支持路径，就应查应用代理支持和客户端模式。不能通过让检测页只显示一个结果，就宣布整台设备已经完成验证。
同样，检测前后切换了节点、Wi-Fi或移动数据，也会让多个地址失去同时比较的基础。先核对时间，再讨论路由。
分项核对，减少额外信息暴露
- 记录系统、客户端版本、模式和已经确认的规则，不上传完整配置。
- 选择可信且用途明确的检测方式，记录它测的是HTTP出口、DNS还是浏览器机制。
- 保持网络与节点不变，分别观察IPv4、IPv6及真正需要使用的应用。
- 对不符合预期的项目保留准确结果，用最小的受支持设置变化复核。
- 不能解释的环节标为未知，必要时提交脱敏记录给客户端支持。
不要把订阅令牌、账号或身份证明填进不明检测站；HTTPS也不能消除地址参数被历史记录或日志保存的风险。一次网页通过只涵盖该次检测范围，不证明后台应用、未来会话或所有网络切换都通过。
继续用双栈检查、WebRTC地址解释和代理与隧道覆盖范围选择对应分支，避免把所有差异统称为泄漏。
来源与核验范围
以下为参考原始资料。品牌价格和功能应以资料库对应字段为准；本文不包含品牌测速或使用体验。内容由站点维护者使用 AI 辅助整理，尚不构成独立实测。