隐私安全 · 域名封禁说明

对禁止 ping0 域名的说明

一个用来"查 IP"的网站,
却可能正用 WebRTC 把你的真实 IP 悄悄传走。

近期社区陆续有人分析指出:ping0.cc 这类"IP 质量检测"页面,疑似在后台借助浏览器的 WebRTC 能力,绕过代理直接拿到访客的真实公网 IP 并上报。出于审慎,我们已在全线路节点封禁该域名——所以在我们的节点上打不开 ping0.cc,是预期行为,不是故障。下面把来龙去脉和技术原理讲清楚。

同样访问一个含 WebRTC 探测的页面,真实 IP 泄漏概率

浏览器已关 WebRTC ≈0

TUN / 全局(UDP 也走代理) 较低

仅系统代理 / PAC(UDP 直连) 真实 IP 暴露

01 — 起因

事情是怎么被发现的

这件事最早在 V2EX、NodeSeek 等社区被讨论开:有用户在分析 ping0.cc 页面脚本时发现,它在做常规 IP 展示之外,还额外建立了 WebRTC 连接,并把采集到的地址信息发回服务器——而这一过程对访客是无感、无提示的。

多篇复盘还提到页面里夹带了混淆/加密的脚本,真实意图被刻意藏了起来;除了 IP,可能一并采集了浏览器指纹等信息。需要说明:这些都属于社区公开分析与推测,我们无法替对方下定论,但对一个"你主动把自己 IP 交给它检测"的工具来说,这类风险足以让人提高警惕。

关键点在于:查 IP 的网站,是这类手法最理想的载体——你本来就是冲着"看我的 IP"去的,它跑各种网络检测脚本显得天经地义,没人会怀疑其中混进了一段悄悄上报真实 IP 的代码。

02 — 技术原理

WebRTC 为什么能绕过代理,拿到你的真实 IP

WebRTC 是浏览器内置的实时音视频/点对点通信能力(视频通话、屏幕共享都靠它)。为了在复杂网络里把两端"连起来",它会做一套叫 ICE 的候选地址收集流程——而正是这套流程,可能在你毫不知情时暴露真实 IP。

①

页面悄悄建一个 RTCPeerConnection 不需要你点任何按钮,JS 直接在后台创建连接对象,并指定一个公共 STUN 服务器。

②

浏览器枚举本机网卡 + 向 STUN 发问 ICE 会收集本地内网地址(host),并通过 STUN 询问"我在公网上长什么样",拿回一个 srflx(server-reflexive) 候选——这就是你的真实公网出口 IP。

③

关键:WebRTC 多走 UDP,常常不经过代理 很多代理只接管 TCP/HTTP 流量(系统代理、PAC、浏览器插件式代理尤甚)。WebRTC 的 STUN 探测走 UDP,会直接从你本机出网,于是拿到的是真机 IP,而不是节点 IP。

④

把候选地址回传服务器 页面监听 onicecandidate,从候选串里正则抠出 IP,再用一个普通请求发回去。整个过程没有任何弹窗或授权。

下面是这类探测的结构示意(非 ping0 原始代码,仅说明原理):

// 后台静默建立连接,指定公共 STUN
const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.l.google.com:19302" }]
});
pc.createDataChannel("");
pc.createOffer().then(o => pc.setLocalDescription(o));

// 候选里就藏着真实公网 IP(srflx)
pc.onicecandidate = (e) => {
  if (!e.candidate) return;
  const ip = (e.candidate.candidate.match(/([0-9]{1,3}\.){3}[0-9]{1,3}/) || [])[0];
  // ↓ 悄悄回传,你看不到
  if (ip) fetch("/collect?ip=" + ip);
};

一句话:你以为代理把你藏好了,但 WebRTC 可能从侧门把真实 IP 直接递了出去。这也是为什么所有正经的"防泄漏"教程都强调要测 WebRTC——它是代理用户最常见、也最隐蔽的泄漏点。

03 — 我们的处置

为什么在我们的线路上打不开 ping0.cc

基于上述风险,我们已在全部节点的系统层面封禁 ping0.cc 域名(IPv4 / IPv6 双栈一并处理),拦截不依赖单一 IP,换 IP 也照样生效。因此:

✓
打不开 ping0.cc 是正常的这是我们主动设置的保护,不是节点故障,也不是线路被封。
✓
不影响其它任何网站仅针对该域名,正常上网、流媒体、AI 服务都不受影响。
✓
想查 IP,用下面更稳的工具同样能看清归属、类型、解锁情况,而不必把真实 IP 交给来路不明的页面。

查 IP 这件事本身没问题,但要挑可信的工具。与其赌一个页面"应该没问题",不如换一个不会在背后做小动作的。

04 — 自保

怎么防住 WebRTC 这类真实 IP 泄漏

✓
用 TUN / 全局模式让 UDP 也走代理。TUN 接管整台设备后,WebRTC 的 STUN 探测也会从节点出网,而不是从你本机。这是最省心的根治办法。
✓
浏览器关掉 / 限制 WebRTCFirefox 在 about:config 把 media.peerconnection.enabled 设为 false;Chrome / Edge 装 "WebRTC Leak Prevent / Control" 类扩展强制只用代理 IP。
✓
别在"裸连"状态打开陌生查-IP 站尤其不要在没开全局、只挂了系统代理时,去访问来路不明的 IP 检测页面。
✓
定期自测泄漏换线路、换设备后,花十秒测一下 WebRTC 与 DNS,确认露出去的只有节点 IP。

用这些工具自检(替代 ping0)

browserleaks.com/webrtc 直接看 WebRTC 暴露了哪些 IP —— Public IP 这栏应是节点 IP,出现你的真实公网 IP 就是泄漏。 cc.mastersgo.cc Claude IP 检测 · 综合检测,看 IP 干不干净、能否解锁。 browserleaks.com/dns 顺手测 DNS 泄漏,只应出现节点所在国家的 DNS。 /claude-ban-guide 延伸阅读:Claude 封禁因素整理 —— 雷区与防封指南。

正确状态下,WebRTC 测出来的 Public IP = 节点 IP,和你网页上看到的出口 IP 一致;一旦冒出一个你熟悉的本地公网 IP,立刻把全局/TUN 打开重测。

05 — 参考

原始讨论与分析来源

本文基于以下社区公开讨论与分析整理,具体细节与结论请读者自行查阅、独立判断:

nodeseek.com/post-674661-1 NodeSeek 社区帖:对 ping0.cc WebRTC 静默上报真实 IP 的讨论。 80aj.com · ping0cc-ip-upload-alert 复盘文章:ping0.cc 疑似借 WebRTC + 混淆脚本采集并上报真实 IP 的提醒。

本文为隐私安全科普,基于社区公开讨论与个人分析整理,不代表对 ping0.cc 运营方的最终定性,相关推测请读者结合原始资料独立判断。我们对该域名的封禁,是出于审慎的隐私保护与对用户负责的考虑;WebRTC 泄漏是浏览器通用机制,并非某一网站独有。技术细节可能随版本变化,请以你实测结果为准,并合规使用各项服务。