IPLeak 的价值就在这里。它把常规出口、WebRTC、DNS、Torrent 和位置资料放在同一页，让用户有机会发现“只有部分流量符合预期”的情况。它不像采购工具那样重点给 IP 打标签，而是更接近一张连接检查清单。
我的评价是：适合验证连接覆盖范围，尤其适合代理、VPN、分流和多客户端一起使用的人。 但它并不会自动运行所有项目；如果忽略等待、激活和权限状态，一张看起来没问题的页面，也可能只是检查还没有做完。
一页多模块，是它最好用也最容易误读的地方
打开 IPLeak，首先看到的是当前浏览器相关地址，往下依次有 WebRTC、DNS，以及需要另外激活的 Torrent 和浏览器定位。下面还有 IP 地区、网络背景、系统信息与请求头。
这种布局的好处，是不必在多个工具之间来回切换。接入前后对照时，可以沿同一页面寻找变化；远程排查时，也比较容易告诉对方具体看哪个模块。对不熟悉网络原理的人，功能名称至少把问题拆成了几个可操作的部分。
这一页最容易漏看的，是检测有没有开始、有没有完成。2026 年 10 月 21 日观察页面时，可以看到几种状态：
- **Pending：**DNS 还在等结果。
- **Activate：**Torrent 或浏览器定位还需要启动。
- **已显示结果：**只代表对应那项检查。
把这些状态放在一页很方便，但还缺一个清楚的完成提示。我不会仅因没有出现本地地址，就把整页算作通过。
我不认为多放一个总分能解决这个问题。更有用的改进，是让每个模块更明确地展示已完成、失败、未授权或未启动。使用者也应把这些状态写进记录，而不是只看页面有没有出现本地地址。
先给连接画一个范围：你希望哪些程序走哪条路？
检查之前，有一个问题比刷新页面重要：代理到底配置在哪里？浏览器扩展、某个应用自己的代理、系统代理和 VPN，作用范围可能不同。即使都填了同一个服务地址，也不表示所有程序会以同一种方式处理连接和解析。
例如，仅为浏览器设置代理，下载客户端继续直连，并不一定是代理服务出现故障；可能只是客户端从未使用这项设置。相反，如果预期整台设备都经过隧道，而某个应用仍出现本地公网出口，就值得调查覆盖或分流规则。
因此，“泄漏”首先需要一个明确的预期。它不是看到两条不同地址就自动成立，而是出现了本来不应经过的公开路径。没有这个前提，合法分流也可能被误判成故障。
我建议先写下四件事
- 这次要验证哪个浏览器或客户端，以及它是否有独立代理配置。
- 希望普通网页、DNS、实时通信、IPv4 和 IPv6 分别走哪条路。
- 是否允许部分应用或域名直连，允许的范围是什么。
- 哪些项目确实与任务相关，哪些可以不启动。
这几行信息会让 IPLeak 的结果更容易解释。它也使后续沟通具体起来：问题不是抽象的“检测没过”，而是某个应用的某种请求没有按预期走。
普通出口模块：很好的第一步，但只能代表这类请求
页面上方的地址，是网站从相关连接观察到的结果。它能帮助确认这个浏览器访问检测服务时，对方看到了哪个公网地址。配置刚改完时，这一步很实用：出口没变，就不必急着研究更细的指纹。
但它不是设备上所有程序的代理状态。浏览器能访问 IPLeak，不能证明命令行工具、邮件客户端或下载程序采用了同样的配置。也不能因为网站识别到某个国家，就认为每个业务站点都识别相同。
IPv4 与 IPv6，要当成两个需要确认的方向
同一设备可能同时具备两类连接能力。如果代理或隧道只覆盖其中一种，另一种路径就可能与预期不同。IPLeak 提供相应地址族入口，适合用来缩小问题范围。
看不到某一类地址，也需要解释：可能没有这类连接能力，可能请求失败，也可能页面没执行完成。应结合设备与客户端配置核实，不能把“没显示”自动写成“已安全阻断”。
我的做法是先确认普通浏览器请求的实际出口，再继续看其他模块。这样即使后来发现问题，也能知道它发生在哪类连接，而不是反复换地址、刷新页面却没有诊断方向。
WebRTC：看见什么地址，远比看见几条地址重要
WebRTC 用于浏览器实时通信。它可能通过候选地址和网络探测，建立与普通网页请求不同的连接条件。因此，仅检查网页出口，不足以代表这一模块。
IPLeak 把它独立列出，是实用的设计。用户可以把普通出口与实时通信暴露的公开地址相互比较。如果后者出现了明确不希望对方看到的本地公网路径，就有了继续检查的依据。
但私有地址、.local 名称与公网地址需要区分。私有地址通常只在局域网内使用；mDNS 名称则可能用于隐藏直接展示的局域网地址。它们不应仅因为与代理出口不同，就被一律当成公网泄漏。
出现差异后，怎样继续？
先确认地址性质，再查看浏览器、客户端和当前代理对实时通信的处理。若当前配置根本不支持预期的路径，需要调整接入方案，而不是认为换一个“纯净度更高”的地址就能解决。
是否关闭 WebRTC，要结合通话、会议和其他实时功能需求。关闭可能影响正常功能，安装扩展也不等于自动解决所有版本与客户端组合的问题。更稳妥的是依据当前环境验证配置，再保留结果。
IPLeak 的帮助说明对部分浏览器给出操作方向，也明确标注旧 WebRTC Network Limiter 扩展已经过时。这一点值得肯定：至少提醒读者不要把多年前的修复步骤当成现行通用方案。具体设置仍应核对当前浏览器文档。
DNS：它测的是解析请求，不是替你列出所有访问内容
访问一个域名，通常先要把名称转换成地址。IPLeak 的 DNS 模块通过特定查询，观察哪些解析服务响应了探测。它帮助回答的是：这类名称查询实际经由哪些服务处理，是否与预期一致。
页面列出的 DNS 地址，不能简单理解为你自己的出口地址，也不能把某个解析器所在国家直接当成设备所在国家。公共解析服务、转发和不同部署方式，都可能使两者不同。
我的评价是，这个模块对发现意外解析路径很有帮助，但解释应建立在配置背景上。看到一个不熟悉的解析器，先问它来自系统、浏览器安全 DNS、路由器还是应用设置，比直接宣布泄漏更有效。
| 页面现象 | 应先核实的条件 | 合理的下一步 |
|---|---|---|
| DNS 一直等待 | 网络、脚本与探测是否完成 | 记录未完成，必要时重新检查 |
| 出现预期之外的解析服务 | 浏览器、系统、VPN 与分流设置 | 找出哪一层选择了解析路径 |
| 出现多个解析服务 | 是否存在转发、并行或不同应用配置 | 结合预期判断，不按数量直接定风险 |
| 地址与出口国家不同 | 服务部署与路由背景 | 检查路径要求，不机械要求同城同国 |
安全 DNS 与系统 DNS，可能不是同一个设置
现代浏览器可能有自己的加密解析配置，系统和 VPN 也可能设置解析服务。改了系统 DNS，不代表浏览器一定采用它；浏览器结果正常，也不能代表其他应用同样如此。
这解释了为什么我会推荐 IPLeak 给实际排障的人：它能把问题落在一个可检查的模块。但对于“所有解析流量是否都经过某个隧道”这种完整证明，仍可能需要客户端日志与更细的网络观察，网页结果只是其中一部分证据。
Torrent 检测：这是它区别于一般查 IP 网站的功能
只为浏览器配置代理后，下载软件可能继续使用另外的路径。IPLeak 把 Torrent 检测单独提供出来，恰好针对这种跨应用差异。
Torrent 检测值得单独保留，因为它真的需要下载客户端参与。测试磁力链接会让客户端联系 IPLeak 控制的 tracker，也就是协调连接的服务器，网站据此看到该请求的出口。它不再只是替下载软件沿用浏览器的结果，这正是它能发现“网页走代理、客户端却直连”的原因。
它的优势很明确：可以发现“网页走代理，客户端没有”的情况。使用者无需先分析全部网络包，就能获得一个具体观察入口。对于确实使用该类客户端的人，比单独查网页出口更贴近任务。
一次观察能说明到哪里？
它说明的是该测试涉及的客户端与 tracker 连接，不自动覆盖客户端所有协议、所有连接和所有以后会话。其他请求是否采用相同路径，应结合客户端设置和具体任务继续验证。
本文没有激活 Torrent 测试，因此不提供某个客户端的通过结果。对于读者，是否启动取决于任务相关性；不用该类客户端的人，可以把它保留为未测试，不需要为了让页面“全部完成”而启动所有功能。
我认为这个模块体现了 IPLeak 最有价值的思路：从“整台设备安全吗”这样太宽的问题，走向“这个程序的这类请求用了哪个地址”。后者更容易测试，也更容易修复。
两张地图可能不同，因为它们根本不是同一种定位
IPLeak 既有按 IP 数据库展示的位置，也有需要激活的浏览器定位模块。页面放得近，容易使读者以为两者是在校验同一条 IP。
这里最容易误会的，是把两张地图当成同一项测试。IP 地图查数据库；浏览器定位则需要位置权限，还可能使用设备的位置能力。后者不是再查一次 IP。把它们放在同一页有比较价值，但如果页面没有讲清来源，反而可能让用户把设备定位误当成代理失效。
所以，代理换到另一地区，不代表设备定位数据自动跟着迁移。两张地图不一致，不能直接归因为代理地区错误；需要先确认每张地图的来源。用户拒绝定位权限，也不等于已完成测试并证明没有位置资料。
看坐标时，别忽略精度范围
IPLeak 的地址详情包含 Accuracy Radius，网站也说明部分数据基于 MaxMind，并可能缓存。坐标和城市名称应与范围、来源和时间一起理解，而不是被读成设备的街道位置。
如果任务只要求国家，城市点位差异未必影响验收；如果任务要求特定城市，就需要更强证据与明确容差。地图看起来越具体，越应问数据究竟能支持多精确的结论。
我认可它把范围字段放进详情，这比只给地图针更诚实。但对非技术用户，两个定位入口仍需要更醒目的解释。否则，功能越完整，反而越容易让人把不同来源的结果混在一起。
重新连接后怎样复测，结果才有可比性？
切换 VPN 或代理后，不建议只盯着已经打开的旧页面。连接和页面状态可能保留此前信息，IPLeak 的帮助说明也提醒重新开标签页检查。复测需要给新配置一个清楚的开始。
我会按任务安排一次小范围对照：
- 写清当前浏览器、客户端版本、接入方式与允许的分流。
- 接入完成后打开新的检测页面，确认普通出口。
- 等待相关自动模块完成，保留失败或等待状态。
- 只激活与任务有关、且愿意授权的模块。
- 修改一个相关设置后，再用同样步骤重测。
- 保存实际出口、时间与具体差异，最后回到真实任务验证。
这套流程的重点是减少变量。一次同时改 DNS、关闭 WebRTC、切换出口和更换浏览器，即使结果变好，也很难知道是什么起了作用。没有因果方向的“全套优化”，往往让下次排障更困难。
协议支持与作用范围，要在接入前确认
接入 PuraRoute 后，我会先用浏览器检查一次，再到真正使用的应用里检查一次。配置时可对照所选资源与客户端的接入方式，确认协议和作用范围。这样做尤其适合浏览器、下载软件同时使用的人：一个程序填过代理，不等于另一个程序已经跟着设置好了。
这也使产品选择更具体：先明确需要浏览器接入、应用接入还是更广范围的连接管理，再选择相应资源和配置。住宅属性与路径覆盖是两个问题，前者合格不能替代后者，检测也应分别进行。
三种“地址不一样”，为什么不应该采取同一种修复？
下面是排查思路的推演，并非三组商业代理测试。它们说明，同一个页面上的差异，需要结合用途才能变成行动。
浏览器正确，下载客户端仍使用本地出口
如果只在浏览器设置代理，这个结果可能完全符合现有配置。下一步应检查客户端是否支持并启用了相应接入，以及它对不同请求的处理，而不是先把浏览器里已经正确的地址换掉。
修复后，再让相关客户端参与测试，确认观察结果是否改变。若实际任务还有其他连接类型，应继续核对相应设置。这里 IPLeak 帮助缩小的是应用范围，不负责替客户端保证所有连接都采用相同路径。
网页出口符合预期，解析器却让人陌生
先查看是不是自己启用的公共解析服务、浏览器安全 DNS 或企业网络配置。如果它正是预期设计的一部分，陌生不等于故障；如果任务明确要求解析也经过指定路径，而结果与之冲突，就应找到选择解析服务的那一层。
对于向供应商反馈，“DNS 不对”仍然太宽。记录模块中的服务、浏览器和系统配置以及预期，会比只发一个国家名称更利于定位。修改之后用同样条件复测，才能知道调整是否生效。
IP 地图在海外，设备定位仍显示真实位置
这时首先应检查定位权限与页面来源。代理改变网络出口，不意味着设备提供的位置能力已改变；如果不希望网页取得设备位置，应管理相关权限，而不是购买一个定位更“精准”的出口。
相反，如果需要位置功能正常工作，简单关闭所有定位也可能影响任务。应根据具体需求选择授权范围，再检查结果。这个情境最能说明：把所有不同都叫泄漏，会让用户修错问题。
地址查询接口能省步骤，但不能替浏览器运行全部检测
IPLeak 还提供 JSON 等输出，并有区分地址族的服务入口。这对于需要记录地址和相关资料的人比较方便，减少了人工复制；但“有接口”不代表一个请求就执行了浏览器里的全部项目。
手动查询某个地址，主要是在获取该地址资料；让当前客户端访问接口，则可用于观察这类请求的出口。两者都不能代替浏览器的脚本能力、授权位置或另一个客户端的实际参与。自动化前，应先写明接口究竟观察了什么。
我更推荐先把手动流程跑清楚，再自动保存稳定的字段。若连等待与未启动都没有区分，自动化只会更快地产生一批难以解释的“正常报告”。对偶尔使用的人，保留一份完整、清楚的记录，已经足以支持很多排障沟通。
与 BrowserLeaks、Whoer 比，IPLeak 更适合哪种人？
Whoer 的摘要更醒目，适合快速看环境概况；BrowserLeaks 的模块与原始信息更丰富，适合继续研究具体机制。IPLeak 的优势在于一页串起几类实际连接，尤其包含需要另一个客户端参与的测试。
我会优先推荐给需要核对分流、IPv4/IPv6、DNS 或下载客户端的人。对于只关心住宅来源、滥用历史与地理数据库的人，应再选择相应工具；在 IPLeak 上看不到风险标签，不代表资源已经获得信誉认证。
网站与 AirVPN 的支持和社区有明显联系。它不妨碍使用这些检测模块，但读者应知道工具来源，而不是将其想象成对所有 VPN 或代理产品独立完成过比较实验的实验室。本文也没有据此评价任何服务的泄漏率。
最终取舍：它让“代理接好了”变成一个可以逐项验证的说法
IPLeak 不是最会打分的工具，也没有替普通用户把每个结果都解释完。等待状态、多个定位来源、手动激活模块，仍会带来阅读成本。部分深层问题也必须回到客户端与系统核实。
但它的功能围绕一个真实需求展开：确认不同请求是否按照预期走。对于经历过“网页正常，另一个程序却直连”的人，这种检查比再多一个 IP 标签更有帮助。
我的建议是把它用作连接配置后的验证页，按任务选择模块，保留未完成与未授权状态。当你能说清哪个程序、哪类请求、在什么配置下走了哪条路，检测才算真正帮助了工作。
关于IPLeak的常见问题
IPLeak 的网页出口正确，是否整台设备都已走代理？
不能。其他应用与解析、实时通信等请求可能采用不同设置，需要按实际范围检查。
DNS 显示 Pending，是否代表没有泄漏？
不是。它表示等待，结果尚不完整，应保留该状态并排查执行条件。
WebRTC 出现 .local，就是暴露本地公网地址吗？
不能这样判断。它可能是 mDNS 名称，应与私有地址、公开地址分别理解。
Torrent 测试会自动运行吗？
不会仅因浏览网页就代表已经完成。它需要相应激活和客户端参与，本文没有实际启动该项。
浏览器定位与 IP 地图不同，代理一定有问题吗？
不一定。两者来源不同，设备定位涉及权限和可用定位能力，IP 地图则依赖数据库推断。
改完代理后应该怎样复测？
接入完成后打开新页面，确认相关模块状态，用相同条件对照，并记录实际出口与时间。
IPLeak 能测住宅属性或目标平台通过率吗？
不能替代相应验收。它主要帮助检查连接与暴露路径，业务效果仍要在真实任务中验证。
