IP Lens分别检查两种地址
- 打开 IPv4 与 IPv6 出口工具并运行。
- 记录每行返回地址还是未知。
- 同时记录网络、浏览器和 VPN 状态，方便之后比较。
浏览器分别向 ipify 的 IPv4 和 IPv6 接口请求。成功结果是对应接口在本次请求中看到的公网来源地址，不是设备全部接口列表。
IPv6 失败可能因为没有可用的 IPv6 连接，也可能受到浏览器限制、DNS 问题或接口状态影响。因此页面显示未知，不直接认定 IPv6 已被关闭。
比较网络背景，而非字符串是否一致
两种地址的格式不同，本来就不应完全一致。应检查观察到的出口是否符合预期配置。可分别查询其来源机构和 ASN，解释方法见 IP 与 ASN 指南。
VPN 开启时，出现意外机构或地区只是排查起点。先确认配置是否接管两种协议。位置估计本身不能证明路由失败，相同位置标签也不能保证所有连接都走同一路径。
比较 Wi-Fi 和移动数据时，等切换完成后重跑两项检查，分开保存结果。混合不同网络的数据会形成误导。
测量浏览器 HTTPS 请求
- 需要较安静的基准时，暂停大型传输并保持标签页活动。
- 打开 HTTP 延迟工具，运行一次。
- 等待 Google DNS 和 Cloudflare DNS 结果。每个目标尝试三次，失败时等待可能更长。
- 同时记录耗时与成功响应数。
计时从发出请求到读取 JSON 响应。连接复用、HTTPS 处理、服务端响应、浏览器调度和响应处理都会影响结果。它不是 ICMP Ping、下载测速或全球探针。
这两组请求没有分别强制使用 IPv4 和 IPv6，因此不能将目标间的耗时差当成协议间的速度比较。
把中位耗时与响应数一起看
三次成功时，工具排序并显示中间值。例如，仅作计算说明，40、55、170 毫秒会显示 55 毫秒。这样减少一次异常慢请求的影响，但三次仍是很小的样本。
失败请求不参与显示耗时，却会减少成功次数。当前实现中，两次成功时显示较大的值；一次成功显示该次值；全部失败显示未知。即使数字很低，1/3 也不能当作与 3/3 同样充分的证据。
单次的小差距无法决定哪个解析器对所有任务都最快。测试描述的是当前浏览器、当前条件下对指定 HTTPS 接口的访问表现。
根据观察缩小问题范围
- 两个出口都失败时，先确认普通网站能否打开。保存错误，等连接稳定后再试。
- 只有 IPv6 未知时，调整前先查看路由器、运营商或 VPN 文档。
- 延迟部分成功时，稍作间隔后再试一次，既比较耗时，也比较次数。
- 只有一个目标持续失败时，调查过滤、扩展或提供方状态，不要认定整个网络断开。
- 问题只影响某个名称时，先分别检查 A 与 AAAA，再判断路由。
持续故障时，向支持方提供时间、网络类型、响应次数与目标。非必要不发送完整导出报告，其中可能包含地址和同一会话的其他检查。有范围、可重复的观察，比笼统说“网络慢”更有帮助。
资料来源与延伸阅读
参阅 ipify 接口文档、MDN performance.now() 浏览器计时说明和 Google DNS-over-HTTPS 文档。采样与不完整结果的处理描述的是 IP Lens 实现。