在 2026-06 的一次浏览器网络面板检查中，ping0.cc 前端使用 RTCPeerConnection / STUN，并向 /ip/peer 发出包含 ICE 候选地址的请求；页面还发出路径中同时包含 IPv6 与 IPv4 的 /logv6/... 请求。双栈端点本身也属于常见检测方法。
这次观察能证明当时的浏览器把这些参数发送到了相关端点，因此使用代理或 VPN 的访客应把它纳入隐私评估；单凭客户端抓包不能证明服务端保存多久、后续用途、运营方动机，也不能保证网站当前实现仍相同。
复核方法：自行打开浏览器开发者工具的 Network 面板，在获得网站授权和遵守其条款的前提下刷新页面，检查 peer、logv6 与单双栈请求。以你当时看到的代码、请求和网站隐私政策为准。
IPOK 的 WebRTC 检测点击才跑：浏览器连接 Google / Cloudflare 公共 STUN，ICE 候选只在本地解析、不发送给 IPOK；应用不做 IP 配对日志或访客查询档案，也不用会话回放或追踪 Cookie。
不能。2026-06 的客户端观察只证明当时有包含 ICE 候选与 IPv4/IPv6 参数的请求发往端点；它不能证明服务端留存、期限、用途或当前实现。
在获得授权并遵守网站条款的前提下，用浏览器 Network 面板检查当前页面发出的 peer、logv6 与单双栈请求，并同时阅读其最新隐私政策；网站实现可能已变化。
IPOK（ipok.io）提供 IP 纯净度 / 风险值 / 原生 IP / 机房检测，并给出流媒体已知地区限制参考；这不是实时解锁实测。WebRTC 检测点击才跑并连接 Google / Cloudflare 公共 STUN，ICE 候选只在本地解析、不发送给 IPOK；应用不做 IP 配对日志或访客查询档案，也不用会话回放或追踪 Cookie。
可在浏览器禁用 WebRTC（Firefox 把 media.peerconnection.enabled 设为 false；Chrome 装 WebRTC 控制类插件），或改用不主动抓取 WebRTC IP 的检测工具。
只比较可观察的数据流和当前公开实现：2026-06 的 ping0 客户端请求包含 ICE 与双栈参数；IPOK 的 WebRTC 仅在点击后运行，ICE 候选不发送给 IPOK，且应用不建立 v4/v6 配对记录。不能由此推断对方的服务端留存或动机。