大家好！今天我们结合实际案例，看看 ZennoPoster 中的网络泄露：哪些情况下会暴露它的网络指纹，哪些情况下您的 IP 地址甚至会绕过代理泄露，以及如何解决这些问题。
下面我们会逐一分析截图中的具体观察结果，解释原因，并介绍如何自行对比使用与不使用 BlankTrail Proxy 时的连接表现。
1. Zenno 浏览器与 HTTP 客户端是不同的网络客户端
ZennoPoster 内置的 Chromium 会生成与自身版本相符的网络指纹。当配置与这个内核及其确切版本一致时，没有必要仅仅为了伪装而修改指纹。
问题出在信息不一致时：例如，配置声称是 iPhone 上的 Safari，但连接仍保留原始 Chromium 的特征。网站可以将 User-Agent 和 Client Hints 与 TLS、HTTP/2 参数进行对比，发现它们属于不同的客户端。
HTTP 客户端的情况则不同。能够发送 Chrome 的请求头，并不会让 HTTP 库变成 Chrome：TLS 握手、HTTP/2 设置和协议交互特征都是由客户端自身生成的。
真实浏览器的对照请求是什么样的
下图中，普通的 Chrome 154 访问了我们的 JSON 测试地址 audit.blanktrail.com/client。响应包含 client: "Chrome 154"、client_kind: "browser"、matches_browser: "Chrome 154"、contradicts_declared: false，以及空的 findings 数组。
ZennoPoster 的 HTTP 客户端显示了什么
在这些测试中，测试平台识别出了以下几种情况：
| 请求发送方式 | 测试返回结果 | 结果含义 |
|---|---|---|
| ZennoPoster 的替代 HTTP 客户端 | client: "ZennoPoster"、client_variant: "plain_client"、client_kind: "client" | 连接被识别为 ZennoPoster 的 HTTP 客户端 |
| ZennoPoster 的 TLS 客户端 | client: "ZennoPoster"、client_kind: "client" | 在这一配置下，实现特征仍足以识别该客户端 |
| 通过 BlankTrail 连接的替代客户端 | client: "Chrome 152"、client_kind: "browser"、matches_browser: "Chrome 152" | 在测试平台看来，连接与所选 Chrome 网络配置一致 |
这是通过网络指纹识别客户端，并不是您的 IP 泄露。下面我们再来看实际泄露的情况。
BlankTrail 改变了什么
BlankTrail 按照所选配置建立与网站的连接。数据库包含真实 Chrome、Firefox、Edge 和 Safari 在不同版本、设备及操作系统上的指纹。自研模拟机制会复现 TLS 和 HTTP/2 参数，User-Agent 与 Client Hints 也可以与该配置保持一致。
我们比较连接时，不只看 JA3/JA4 的值：简短标识符相同，并不代表整个协议行为都相同。在我们的对比测试中，包括 uTLS、curl_cffi 和 TLS-Cloak 在内的常用库，仍与作为参照的浏览器存在差异。对于实际使用的客户端版本，最好在测试平台上验证，而不是仅凭库的名称判断。
网络配置并不能替代 JavaScript 环境：如果您使用的是 Zenno 的真实浏览器，其设置应与所选网络身份一致。对于移动应用 API，BlankTrail 还支持采集应用的网络指纹，并用于后续模拟。
2. DNS 泄露的真实案例：代理已设置，路由却不一致
DNS 是独立的网络交互。即使页面的主要请求通过代理发送，浏览器或其内部机制也可能自行解析域名。仅设置代理并勾选 WebRTC 模拟，并不能证明所有 DNS 查询都沿同一路由发送。
案例：家庭网络子网通过 ECS 暴露
下图中，ZennoPoster 已设置 SOCKS5 代理，并启用了地理位置、时区和 WebRTC 模拟，但没有启用 DNS-over-HTTPS。测试平台显示 ecs_foreign、mixed_ecs 和 mixed_egress。
这里需要正确理解结果：
ecs_foreign— DNS 传递的子网与主连接的地址不一致。在这个示例中，测试平台显示的是真实子网，而不是确切的家庭 IP。但这已经是严重的泄露：每次请求都会暴露您的信息，并将所有实例中的会话关联起来，无论您使用什么代理，也无论如何更换浏览器配置。/24 掩码的子网只有 256 个地址，已经能将范围缩得很小。mixed_ecs— 同一次检查中观察到了不同的 ECS 值，域名解析看起来并未沿一条一致的路由进行。mixed_egress— 同一次检查中的服务端请求来自不同的出口地址。这意味着需要检查路由和代理轮换；仅有两个不同出口，并不能证明其中一个就是家庭网络。
ECS，即 EDNS Client Subnet，会在 DNS 查询中携带客户端网络的信息。 如果查询通过家庭网络连接到达解析器，解析器就能看到其真实来源，并可能继续传递该地址的前缀。网页请求来自代理 IP，而 DNS 却指向另一张网络。其机制及对隐私的影响见 RFC 7871。
案例：启用公共 DoH，并不保证路由一致
另一张截图中，Zenno 的内置动作设置了 Cloudflare DoH。可见的结果部分仍有 mixed_egress、mixed_ecs 和 h3_refused 警告。
这个例子并不意味着 Cloudflare 传递了家庭网络子网：这张截图没有给出这样的结论。它说明的是另一点：仅选择公共 DoH，还不足以确认整个交互都绑定到了所需出口。DNS 加密与 DNS 路由解决的是不同问题。例如，我们曾观察到 Google 的 DoH 服务器偶尔暴露 ECS 子网，但并非每次查询都稳定出现。
3. vDNS、自带 DoH 与 TUN 如何解决不同环节的问题
vDNS：让解析器匹配出口运营商与地理位置
普通用户也会使用公共解析器，这本身并不代表自动化。不过，在建立我们自己的运营商 DNS 数据库时，我们发现，真实用户中使用 Google、Cloudflare 或其他公共 DNS 服务器的比例不到 20%。绝大多数用户保留运营商的 DNS 设置。因此，在网站及其反欺诈系统看来，域名解析请求来自与该 IP 对应的运营商 DNS 服务器，会显得更合理。
BlankTrail 自有数据库收录了超过 4,000 家运营商和超过 10,000 台 DNS 服务器。这是互联网运营商解析器的数据库，其中大多数服务器只向自身用户开放，并非公开 DNS 服务器的合集。
BlankTrail 会识别出口运营商，结合地理位置选择合适且可用的解析器，并通过该出口访问它。这样，IP、DNS 和位置的组合就与普通用户相同，能够消除严格检查中的部分不一致。
还提供以下模式：
- 携带出口 ECS 的公共 DNS — 例如，使用 Google DNS，携带代理子网而非家庭网络子网，适合没有原生运营商 DNS 服务器的服务器代理。
- 通过出口自行解析 — BlankTrail 自行沿 DNS 链查询根服务器、区域服务器和域名权威服务器，不使用中间的公共或运营商递归解析器；查询来源为出口 IP。代理本身并不会因此变成独立的 DNS 服务。这种解析方式能实现理想的 CDN 地理定位精度，并绕过运营商或公共 DNS 上可能存在的过滤与限制，但看起来不那么自然，只符合极少数自行搭建 DNS 的用户，例如在路由器上运行 DNS 服务器的人。
- 将解析交给代理 — 使用代理自身的功能解析域名。
自带 DoH：无需 TUN，让浏览器 DNS 经过 BlankTrail
vDNS 只能处理真正到达它的查询。因此，BlankTrail 在产品端口上提供了自己的 DNS-over-HTTPS 服务器，您可以将其地址填入浏览器的安全 DNS 设置。
浏览器将自行发起的 DNS 查询发送到 BlankTrail，随后按照所选端口的 DNS 策略，通过该端口的出口处理。客户端传入的 ECS 会被移除，后续如何使用子网由端口设置决定。不同浏览器配置可以使用不同端口的 DoH，各自拥有独立的出口和参数。
这样无需 TUN 拦截，也能解决浏览器域名解析中的 DNS 泄露。 需要使用严格 DoH 模式，在出错时不自动回退到系统 DNS。自动模式与严格模式的区别，对普通浏览器同样重要，参见 Chrome 和 Firefox 的设置。
我们的 ZennoPoster 插件可以更方便地应用代理与 DoH 设置。
TUN：当应用无法配置 DNS 或代理时
任何应用都可能通过系统服务发送 DNS 查询，绕过自身的代理设置。在 Zenno 中，可以通过 C# 和插件配置网络行为，但其他软件未必提供这种能力。
这种情况下，可以使用系统级 TUN 拦截。它将流量引导至选定的 BlankTrail 端口，并处理普通 DNS 查询，包括来自系统解析服务的查询。
您可以拦截整个系统，也可以只拦截指定应用及其子进程。不同程序可以使用不同端口：例如，ZennoPoster 使用一套代理与配置，另一个程序使用其他出口。在按应用处理的模式下，系统 DNS 的处理需要单独启用，并为共用的系统解析器选择服务端口。
DoH 适合支持它的浏览器所发起的 DNS 查询。TUN 则用于更广泛地控制网络流量。仅设置 DoH，并不会重定向电脑上的所有连接。
4. HTTP/3 与 QUIC：为什么 DNS 测试全绿，协议问题仍未结束
许多大型网站和 CDN 支持 HTTP/3，即运行于 QUIC 和 UDP 之上的 HTTP。使用普通 HTTP/SOCKS5 代理时，Zenno 浏览器与标准 Chrome 一样，不会通过这种代理建立到网站的 HTTP/3 连接。Chromium 文档明确指出，SOCKS5 用于 TCP 请求，而非 UDP 传输。参见 Chromium 文档。
没有 HTTP/3，本身既不会暴露 IP，也不能证明存在自动化。 普通网络也可能无法使用 UDP。不过，这仍是连接的一项特征，网站可以将其与配置中的其他信息进行比对。
案例：DNS 一致，但尚未使用 HTTP/3
下图中，连接 BlankTrail 后，测试平台显示使用运营商解析器，ECS 仅对应出口子网，User-Agent 也保持一致。同时，h3_refused 仍然存在。
案例：完成检查并使用 HTTP/3
另一个出口展示了已完成的检查。测试平台报告未发现 IP 泄露，ECS 仅对应出口子网，HTTP/3 正常工作且其引擎与 TLS 一致，User-Agent 也与连接指纹相符。不过，由于这是服务器代理，这里没有运营商 DNS 服务器的标记，但即使使用服务器代理，请求仍携带了一致的 ECS。
BlankTrail 通过 HTTP/2 接收 Zenno 的请求，并可以与网站建立基于 QUIC 的 HTTP/3 连接，在这一层同样遵循所选浏览器的网络配置。
为此，网站必须支持 HTTP/3，所选出口必须能够传输 UDP，例如通过可用的 SOCKS5 UDP relay。如果 UDP 不可用，则使用 HTTP/2。BlankTrail 不会为了获得绿色标记而绕过已配置的代理直接发送 QUIC，从而引入另一个出口 IP。
5. 独立会话需要隔离网络状态
在我们的 ZennoPoster 测试中，曾遇到这样的情况：重复使用同一条代理连接字符串时，新的浏览器实例仍与上一会话保持网络层面的关联。即使该地址背后的 IP 已经改变，重启实例也可能不够。例如，您使用的代理可以通过 API 请求更换出口 IP：完成一个 ZennoPoster 会话后，通过代理服务的 API 更换出口 IP，再开启新会话。Cookie、缓存、IP 和浏览器配置都变了，但网络层面的泄露仍在，网站能看到这一点，并把您的所有会话、账号等关联起来。
您可以在我们的审计测试平台自行验证：使用同一条代理连接字符串，从新会话中连续访问。如果新访问被检测到与另一个会话有关联，测试平台就会显示标记。
BlankTrail 按端口隔离网络连接状态。独立任务分配独立端口，各自拥有配置与路由。如果需要继续原来的任务，则可以导出并导入端口会话，同时保留其配置、指纹和 TLS 会话。
6. Smart Cache 与路由：减少重复下载，增强控制
在多线程模板中，相同的脚本、样式、字体和图片会被反复下载。但如果不清空浏览器缓存，标识就会通过缓存泄露，网站很容易将您的所有会话和账号关联起来。Smart Cache 允许线程共享适合缓存的静态资源，减少付费代理流量的消耗。
BlankTrail 会分析个性化特征，将相应响应排除在共享缓存之外，并移除可能关联不同访问的标识，包括 ETag。它支持按域名和资源设置排除规则，也支持自动预热。节省多少流量，需要根据具体项目的实际统计来评估。
出口可以使用 HTTP/SOCKS5 代理、OpenVPN、WireGuard、VLESS（包括 REALITY）、Trojan、Shadowsocks、VMess 和 Hysteria 2。应用可以通过 BlankTrail 的普通本地代理端口使用 VPN 和隧道连接。
连接链与按域名路由允许为不同网站指定不同路径。REST API 和预设则帮助您直接在模板中创建端口、修改设置，并管理多线程项目。
7. 验证码与浏览器验证：包括无 GPU 的 Linux 环境
BlankTrail 还提供 Challenge Breaker：自有浏览器组件，基于经过精细修改的 Chromium，即使运行在没有 GPU 的 Linux 上，也能输出与配置对应的标准参照指纹，并配有在本地处理支持的验证码的机制。
支持的场景包括 Cloudflare/Turnstile 验证、reCAPTCHA v2、AWS WAF、Geetest 滑块、Avito、Ozon，以及 Google 文字验证码。处理过程在运行 BlankTrail 的机器上完成。需要图像识别的任务使用本地模型，不向外部服务发送数据，也不产生额外费用。
以请求方式工作时，Challenge Breaker 会打开所需页面，完成支持的验证，并提供可用的会话状态，供后续请求通过 BlankTrail 使用。出口与网络配置必须保持一致：将获得的结果转移到使用其他 IP 的任意客户端，并不等同于继续同一会话。
此外，还提供遵循 Anti-captcha 标准（Antigate V2）的 API：
RecaptchaV2Task、ImageToTextTask 和 AntiGateTask. 您可以用它替代外部验证码识别服务，只需在相关软件中，将服务地址改为本地 BlankTrail Proxy 设置中指定的地址和端口。例如，当通过 Challenge Breaker 自动处理不适合您的任务时，可以用该 API 获取 reCAPTCHA v2 或 v3 令牌、识别支持的文字验证码，或在通过 Cloudflare 等浏览器验证后获取会话。
无需物理显卡。BlankTrail 也能在没有 GPU 的 Linux 服务器上处理支持的验证码：识别可以在 CPU 上执行，浏览器组件可以使用软件图形渲染。速度和允许的并发任务数取决于处理器、内存及验证复杂度。
8. ZennoPoster 插件：通过熟悉的动作模块连接
为了免去手动拼接 API 调用，我们开发了适用于 ZennoPoster 和 ProjectMaker 的 BlankTrail Proxy 插件。在结果正常的截图中，左侧可以看到它的界面和“打开端口并应用”动作。
插件会按所选设置打开端口，等待识别出口运营商，然后将代理与 DoH 一并应用到实例浏览器。表单中可以设置 API 密钥、BlankTrail 地址、预设、协议、通过代理或 VPN 网关使用的出口，以及其他参数。
除了首次连接，还支持更换出口与配置、检查泄露、保存和加载会话、修改设置、关闭端口，以及清理遗忘的端口。模板开发者也可以通过 C# 调用。
这使多线程工作更加简单：线程获得自己的端口，在任务中使用，并在结束后释放。插件可从账户后台下载。
9. 如何在自己的模板中复现检查
为便于比较，请记录 ZennoPoster 和内核版本、HTTP 客户端类型、所选配置、DNS 模式及代理出口。尽量使用稳定出口：检查期间轮换出口，会增加解读 mixed_egress 的难度。
检查 DNS、ECS、HTTP/3 与会话关联
- 在新的浏览器实例中，使用项目的常规设置打开 audit.blanktrail.com。
- 等待检查完成。
collecting observations表示结果仍在补充中。 - 保存结果，包括测得出口、ECS、解析器、服务端观察结果和警告。重点查看
ecs_foreign、mixed_ecs、mixed_egress和h3_refused。 - 通过插件连接 BlankTrail，应用 DoH，并在新实例中重复检查。手动配置时，请确认使用严格 DoH 模式，不回退到系统 DNS。
- 对比路由与子网。评估 HTTP/3 时，需要考虑出口是否支持 UDP。浏览器报告的 WebRTC 信息不能替代服务端观察结果。
- 检查会话关联时，使用同一条代理连接字符串，从新实例中连续访问几次，并查看是否出现相应标记。
绿色结果意味着，本次运行中，测试平台没有发现其检查范围内的不一致。更换出口、设置或浏览器版本后，建议再次检查。
检查 ZennoPoster HTTP 客户端的指纹
- 使用真实浏览器向 audit.blanktrail.com/client 发起 GET 请求，作为对照示例。
- 使用 ZennoPoster 的 HTTP 客户端访问同一个 JSON 地址，依次检查您使用的模式，包括替代客户端和 TLS 客户端，并保存响应。
- 通过 BlankTrail 端口，使用所需浏览器配置重复 HTTP 请求，使 User-Agent 和其他设置与所选版本一致。
- 当响应中存在相应字段时，对比
client、client_kind、matches_browser、contradicts_declared和findings。 - 检查是否与所选配置一致。如果选择的是 Chrome 152，预期参照也应是 Chrome 152。
JSON 响应检查的是请求的网络层面。评估 JavaScript 环境与浏览器行为，需要使用相应的浏览器测试。
从您自己的项目开始
Lite 套餐免费，面向所有人开放。如果想试用包含 vDNS 和 Challenge Breaker 的 Pro / Enterprise 套餐，请联系支持，我们会提供 1 天的试用权限。
