自己动手：三分钟判断一个浏览器有没有在偷看你

先说结论

判断一个浏览器有没有在「偷看你」，不需要读它的隐私政策，也不需要相信任何人的评测。跑四个检查，看四个结果，三分钟给出一个你自己能复现的结论：

一、出口 IP 和它的归属 → IP 地址查询。看的不只是 IP，是这个 IP 属于运营商还是数据中心。

二、DNS 走哪里 → DNS 泄露检测。流量走了代理，但「你要访问哪个域名」可能仍然原原本本告诉了本地 ISP。

三、WebRTC 有没有漏 → WebRTC 泄露测试。浏览器为了建立点对点连接会主动探测自己的地址，这个动作不一定经过你的代理。

四、权限和扩展要了什么 → 系统设置 + chrome://extensions / about:addons。前三项查的是「流量去哪了」，这一项查的是「谁能读到页面内容」——而后者的危害更大。

关键的一条：四个结果必须一起读。 单看任何一个都会得出错误结论。比如「出口是数据中心」这件事，在「我开着代理」和「我什么都没开」两种预期下，含义完全相反。所以——

做任何检查之前，先跑一次基线：把所有代理关掉，跑一遍这四项，把结果记下来。这是「没有任何保护时你长什么样」。后面所有判断都跟它比。

这套流程对任何浏览器都适用，包括明年才出现的那个新名字。具体案例可以对照 芒果浏览器到底连的是谁的服务器；「免翻墙浏览器」为什么不可能存在见 这一篇。

第 0 步：先跑基线（30 秒，但别跳过）

关掉所有代理／VPN／加速器，用你平时信任的浏览器，把下面三项各跑一次，把结果抄下来：

这三行就是你的「裸奔状态」。之后每一次检查，你要问的都是「和基线相比变了什么」，而不是「这个结果看起来对不对」。

跳过基线最常见的错误：看到一个陌生城市的 IP 就以为代理生效了——其实那可能只是运营商的出口城市；或者看到 WebRTC 显示了一个 IP 就以为漏了——其实那正是代理的出口地址，是正常的。

检查一：出口 IP 和它的归属

怎么做：在要检查的浏览器里打开 IP 地址查询。

看两件事：

1. IP 的归属地，是不是你预期的节点所在国家／地区。
2. 这个 IP 属于谁——是宽带运营商，还是某家云厂商／IDC（数据中心）。

怎么读：

• 你开着代理 + 出口是数据中心 → 正常。代理节点本来就架在机房里。
• 你开着代理 + 出口还是你本地运营商 → 代理没生效，或者这个浏览器根本没走代理（常见于只配了系统代理、而浏览器另有自己的代理设置）。
• 你什么都没开 + 出口是数据中心 → 警报。有东西在替你转发流量，而你没同意过。这时候要做的是查清楚它是谁：具体方法（按进程／按应用看连接）见 这一节。
• 你什么都没开 + 出口是本地运营商 → 正常，这就是基线。

一个补充动作：拿一个你常访问的域名去 DNS 查询工具 查一下解析结果，和你本机拿到的对比。差异很大，通常意味着解析被干预过——原理见 什么是 DNS 泄露。

检查二：DNS 走哪里

怎么做：同一个浏览器里打开 DNS 泄露检测。

通过标准：列出的 DNS 服务器不应出现国内运营商（中国电信／联通／移动）。

不通过说明什么：这是最常见也最容易被忽略的一种泄露——流量走了代理，但「你要访问哪个域名」仍然原原本本地交给了本地 ISP。加密的是内容，暴露的是意图，而对很多场景来说后者更敏感。

怎么修：

• 浏览器侧：把「基于 HTTPS 的 DNS（DoH）」调到最大保护这一档——它在安全 DNS 不可用时直接报错而不回退明文。完整设置见 把 Firefox 配成一台安全的跨境浏览器。
• 客户端侧：检查代理客户端有没有开启「远程 DNS 解析」，让解析发生在节点那一端而不是本机。
• 手机侧：安卓的「私人 DNS」（DNS over TLS）值得开，但要知道它的边界——Google 官方公告写明这条安全通道只作用于 DNS，不解决链路是否通畅。详见 安卓上怎么选浏览器。

检查三：WebRTC 有没有漏

怎么做：打开 WebRTC 泄露测试。

它为什么会漏：WebRTC 是浏览器内置的实时音视频能力，要建立点对点连接就必须先知道自己的地址。按 MDN 的说明，它用 STUN 协议「向互联网上的 STUN 服务器发送请求，服务器会回复客户端的公网地址」，同时也会把本机地址作为候选（ICE candidate）一并交换——MDN 对 host 类型候选的定义就是「其 ip 地址是对端实际的、直接的 IP 地址」。这个探测由浏览器直接发起，不一定经过你配置的代理。

通过标准：结果里不应出现你在基线里记下的那个真实公网 IP。

不通过说明什么：任何一个网页都可以用同样的方式拿到你的真实地址——代理挡不住它，因为它压根没走代理那条路。这正好说明了为什么「浏览器」和「跨境连接」要分别选好：指望一个「内置VPN浏览器」同时搞定两者是不现实的。

怎么修：Firefox 里把 media.peerconnection.enabled 关掉（代价是所有基于 WebRTC 的网页音视频会失效）；或者用扩展限制 WebRTC 只使用代理接口。更完整的排查（含 IPv6 泄露、Kill Switch 失效）见 VPN 泄漏检测：5 种方法自测。

检查四：权限和扩展要了什么

前三项查「流量去哪了」，这一项查「谁能读到页面内容」——这一项的危害上限更高。原因很简单：代理看到的是加密流量，而浏览器和它的扩展处理的是解密后的页面本身：你打开的网址、填进表单的账号密码、Cookie、验证码。

手机端：设置 → 应用 → 该应用 → 权限 / 流量使用情况。

• 该有的：存储（下载文件）、网络。
• 要问清楚的：位置、通讯录、短信、电话、摄像头麦克风（除非你真的在网页里用）。
• 看到就该停的：无障碍服务（可以读屏和代替你点击）、安装其他应用、设备管理器。一个浏览器不需要这些。
• 顺手看一眼「后台流量」：你没用它的时候它跑了多少流量。

桌面端：打开 chrome://extensions（Chromium 系）或 about:addons（Firefox），逐个点进「详情」看权限。

Chrome 官方文档说明，<all_urls> 这类主机权限会让扩展能够：读取标签页的敏感属性（URL、标题、图标）、以编程方式注入内容脚本、用 chrome.webRequest 监控和控制网络请求、通过 chrome.cookies 访问 Cookie、以及用 declarativeNetRequest 重定向请求和改写请求／响应头。

换成人话：一个拿到 <all_urls> 的扩展，等于坐在你和每一个网站之间。 它值不值得这个权限，取决于它是不是真的需要——一个换主题皮肤的扩展不需要读你所有网页。

动作：把你不认识、不记得为什么装、或者已经半年没用的扩展全部删掉。扩展这一类的风险为什么特别高、以及 2026 年的公开事件记录，单独讲在 浏览器里的「免费 VPN」插件：2026 年的真实风险。

把四个结果放在一起读

单项结果几乎没有意义，组合才有。下面五种是最常见的：

还有一种组合值得单独说：四项全部通过，但你仍然不该用它。

什么情况？当这个浏览器本身值得怀疑，只是今天没露出马脚的时候。典型信号：

• 它的发行主体在公开渠道查不到，或者下载页上「厂商」一栏写着「用户自制」；
• 它必须从商店之外获取，没有可比对的签名或校验值；
• 它的变现方式是「做任务赚钱」「看视频领红包」——这需要持续采集行为数据，与保护隐私方向相反；
• 它内置的代理你不能更换，也不知道出口在谁手里。

这四条里任何一条成立，「今天检测通过」都只是一个时间点的快照。软件会更新，所有权会转手，而更新是静默推送的。 检查能证明「此刻没有泄露」，证明不了「这个供应商可信」。判断供应商只有两个问题：它在哪里分发？谁为它负责？

什么时候要重做这套检查

• 换了代理节点、换了客户端、客户端大版本更新之后；
• 浏览器大版本更新之后（默认设置可能被重置）；
• 装了任何一个新扩展之后；
• 你注意到异常的时候——最典型的是人机验证突然变多。Cloudflare 官方排障文档指出，IP 信誉不好会导致反复挑战，而这种情况「常见于共享 VPN 或企业代理」；也就是说，验证码变多往往是「你的出口被很多人共用、而且被滥用过」的体感信号。

检查之后：按影响面排序处理

1. 先堵 WebRTC 和 DNS——它们直接交出「你是谁」和「你访问了什么」。
2. 再收权限、删扩展——减少能读到页面内容的对象数量。
3. 最后才换浏览器或换方案。顺序反了容易白忙：换了浏览器不改设置，同样的泄露会原样复现。

想要一套配置好就不用反复折腾的浏览器方案，走 把 Firefox 配成一台安全的跨境浏览器；想理解 DoH 与 ECH 各自解决什么，看 DoH + ECH 设置指南。

最后一句：这四个检查的价值不在于它能抓到谁，而在于它把「我觉得应该没问题」换成了「我看过，结果是这样」。前者不可复现，后者可以——而且三分钟就能再跑一遍。

参考资料

• MDN Web Docs — WebRTC 协议介绍（STUN 用于发现客户端的公网地址、ICE 候选）（2026-09-20 核查）
• Chrome for Developers — 声明扩展权限（主机权限 <all_urls> 可读取标签页敏感属性、注入内容脚本、使用 webRequest／cookies／declarativeNetRequest）（2026-09-20 核查）
• Android Developers Blog — DNS over TLS support in Android P（私人 DNS 的作用范围仅限 DNS）（2026-09-20 核查）
• Cloudflare — Challenges 排障文档（IP 信誉与共享 VPN／企业代理导致反复人机挑战）（2026-09-20 核查）
• MDN Web Docs — WebRTC connectivity（host 类型 ICE 候选的定义：其 IP 就是对端实际的、直接的 IP 地址）（2026-09-21 核查）