网页出口已经切换，DNS 检测却仍出现本地运营商时，先区分浏览器解析、系统解析与内核解析，再决定修改哪一层。本文以 Windows 上的 v2rayN 为操作主线，给出对照测试、远程 DNS 出站检查、TUN 接管验证与日志排错步骤。适合已经导入节点、能够连接，但需要确认域名查询是否按预期分流的用户。
DNS 泄漏的判断边界
DNS 用于把域名转换为地址。代理连接成功，只能说明某条业务连接已经通过代理，不代表所有应用的域名查询都经过同一路径。浏览器可能使用自己的加密 DNS，系统可能向路由器查询，代理内核也可能为了节点连接或路由判断单独解析域名。这些路径需要分别检查。
本文所说的泄漏，是指原本要求通过代理处理的域名查询，意外发给了本地网络的解析器。如果配置本来就是国内域名直连、其他域名代理，那么国内域名使用本地 DNS 可能是预期行为。不能只看检测结果里出现了本地地区，就认定整个配置失效。
v2rayN 是客户端界面，实际解析行为取决于所选内核、生成配置和应用自身设置。VMess、VLESS 等连接协议不会自动接管系统 DNS。检测页显示的通常是向测试域名权威服务器发起查询的递归解析器出口，不一定是代理节点地址，也不能单凭解析器所属国家判断查询是否加密。
建立对照：先测出口，再测 DNS
先保持同一台电脑、同一个网络和同一个浏览器。可在浏览器搜索并打开 DNSLeakTest 或 BrowserLeaks 的 DNS 检测页；检测服务会接收到测试请求，敏感环境应先确认其隐私说明。不要上传订阅地址、节点凭据或完整客户端配置。
- 记录直连基线。关闭 v2rayN 的系统代理和 TUN，确认浏览器未手动设置代理。记录公网出口、检测到的解析器名称以及浏览器安全 DNS 的当前状态。
- 只开启系统代理。选择可用节点，使用托盘菜单「系统代理」→「自动配置系统代理」。确认网页出口发生预期变化，再运行一次完整 DNS 检测。
- 只改变一个变量。保持节点、路由模式不变，调整 DNS 或浏览器安全 DNS 后重新检测。不要同时更换节点、切换网络和启用 TUN，否则无法定位原因。
- 建立 TUN 对照。确认系统代理状态并记录，再开启 TUN，用相同检测项目复测。切换后重启浏览器，避免连接池沿用之前建立的连接。
| 观察结果 | 可能解释 | 下一步 |
|---|---|---|
| 网页出口未变化 | 浏览器未使用代理，或目标被规则直连 | 先查系统代理和路由命中，不急着修改 DNS |
| 出口变化，解析器仍是本地运营商 | 存在本地查询路径，也可能命中了预设直连规则 | 核对测试域名的路由与浏览器 DNS 设置 |
| 出现多个公共解析器 | 浏览器、内核或上游服务采用了不同解析路径 | 对照日志和抓包，逐一确认来源 |
| 解析器与节点地址不同 | 节点使用独立递归服务或公共 DNS | 不要据此直接判定泄漏 |
结论：以预期路径为标准，不以地址数量为标准
先写清“哪些域名必须经代理解析”，再核对这些域名的实际请求。检测到多个解析器不是独立证据；目标域名意外走向本地解析器，才是需要修复的具体问题。
系统代理与浏览器 DNS：先排除旁路
系统代理主要影响遵循系统代理设置的应用，不等于接管所有网络连接。某些程序会自行解析后再连接，某些程序完全不使用系统代理。浏览器的安全 DNS，也就是基于 HTTPS 的 DNS 查询，属于另一条需要确认出站的连接；开启它并不自动等于经代理解析。
- 确认监听地址和端口。在 v2rayN 主界面查看当前本地监听信息；若设置中有「设置」→「参数设置」→「基础设置」，核对其中的本地监听端口。不同界面版本的分组名称可能不同，不要直接套用示例端口。
- 固定浏览器解析策略。在浏览器设置中搜索“安全 DNS”，记录提供商和开关状态。诊断时可以暂时关闭该功能，使浏览器回到系统或代理提供的解析路径，随后再单独测试开启后的行为。
- 检查手动 SOCKS 配置。如果应用提供“通过代理解析域名”选项，应明确启用；如果应用先在本地解析，再把 IP 交给 SOCKS 代理，网页仍可能访问成功，但域名已经在本地查询。
- 区分 WebRTC 与 DNS。WebRTC 地址暴露属于不同的测试项目。不能因为同一检测页上出现其他地址，就把所有结果都归因于 DNS。
不要把 Windows 网卡 DNS 改成 127.0.0.1 作为通用修复。只有本机确实在对应地址的 53 端口运行 DNS 监听服务时，这样设置才有意义。v2rayN 的本地 HTTP 或 SOCKS 代理端口不是系统 DNS 服务端口，二者不能互换。
v2rayN DNS 设置：检查服务器，也检查出站
修改前备份当前配置，并记下所选内核。进入「设置」→「DNS 设置」；部分界面会把相关项目放在参数设置内。如果看不到同名入口，应按实际界面的 DNS 项操作，不要把其他内核的 JSON 直接粘入。字段名称、可用模板和 DNS 路由能力随内核而异。
- 明确直连解析和代理解析的职责。如果保留分流，直连 DNS 服务用于预期直连的域名，远程 DNS 服务用于需要代理的域名。若目标是所有业务域名均经代理解析，测试时不能仍保留把这些域名交给直连 DNS 的规则。
- 指定可用的远程服务。DNS 服务器可以采用普通 DNS 或受内核支持的加密方式。仅填写公共 DNS 地址不会改变出站；例如把服务器换成
1.1.1.1，但查询仍从本地网络直出，便没有达到“经代理查询”的目标。 - 核对 DNS 请求的路由。确认远程解析器连接使用预期代理出站，而不是被私有地址、地区地址或其他宽泛规则提前直连。DoH 通常使用 443 端口，不能只添加一条针对 53 端口的规则就认为已经覆盖。
- 处理首次解析依赖。若代理节点地址是域名，建立代理前通常需要先获得节点地址。若 DoH 服务器地址也是域名，还需要解决该服务器的首次解析。为必要的启动解析设置明确路径，避免出现“建立代理需要 DNS，而 DNS 又必须依赖尚未建立的代理”的循环。
- 保存并重启内核。检查启动日志是否正常，再访问新域名测试。若只是保存但未重新加载配置，观察到的结果可能仍来自旧配置。
路由分流与 TUN：把系统查询纳入检查
TUN 通过虚拟网卡接管符合路由条件的 IP 流量，适合不遵循系统代理的程序。但开启 TUN 不代表所有 DNS 自动进入内核解析器。需要检查当前内核是否启用了 DNS 接管或劫持功能、接管范围是什么，以及是否存在排除路由。不要照搬不同内核之间同名但语义不同的字段。
- 先确认 TUN 启动成功。按界面提示提供必要权限，查看是否出现虚拟网卡创建失败、路由添加失败等日志。开关显示启用但网卡未建立，不能作为接管成功的证据。
- 检查传统 DNS 接管。核对发往 UDP/TCP 53 的查询是否被送入预期解析流程。只覆盖 UDP 会遗漏 TCP 查询；只覆盖 IPv4 也可能遗漏 IPv6 路径。
- 检查加密 DNS 的单独出站。浏览器自带 DoH 是 HTTPS 流量，不属于传统 53 端口查询，应按其服务器域名或地址检查路由。
- 检查规则顺序。规则通常按内核规定的顺序匹配。宽泛直连规则可能先于远程 DNS 规则命中，应以生成配置和日志为准，而不是只看界面中是否存在某条规则。
- 检查 IPv6 与多网卡。无线网卡、有线网卡及其他隧道可能同时存在。确认活动接口的 DNS 服务器与路由；不要把关闭 IPv6 当作永久通用方案，应优先补全对应接管路径。
FakeDNS 不是必须开启的防泄漏开关。它通过返回虚拟地址、保留域名映射来配合流量处理，需要解析入口与后续连接都进入对应内核。若系统缓存保留了虚拟地址，而流量离开该处理链，反而可能无法访问。普通远程解析能满足目标时，可先保持简单配置。
Windows 验证命令与真实报错排查
在 PowerShell 中执行下列命令，可以查看接口 DNS、检查本地缓存并清理系统缓存。清理会影响本机其他应用的下一次查询，但不会清掉浏览器自己的全部缓存，也不会自动关闭既有连接。建议清理后完整退出浏览器，再打开检测页。
Get-DnsClientServerAddress
Get-DnsClientCache
Clear-DnsClientCache
Resolve-DnsName example.comResolve-DnsName 和 nslookup 不是浏览器代理测试工具。仅开启系统代理时，它们的查询通常不会因此进入 HTTP 或 SOCKS 代理；在 TUN 模式下是否被接管，则取决于 DNS 接管设置和路由。命令返回成功只能证明解析完成，不能证明所走路径符合要求。
报错：i/o timeout
原因：请求在期限内没有得到响应，若出现在 DNS 日志中，可能是上游不可达或对应出站不通。
解法：先查看同条日志的目标地址和出站，再分别验证代理连接与 DNS 服务；不要一遇超时就反复增大超时值。
报错：no such host
原因：名称解析失败，可能是域名拼写错误、上游返回不存在，或启动解析路径没有配置正确。
解法：确认报错对应节点域名、DNS 服务域名还是访问目标，再检查该域名所用的解析器；不要把所有失败都归为节点故障。
报错：connection refused
原因：目标端口拒绝连接，常见于把 DNS 指向本机却没有 DNS 服务监听，或本地代理端口填写错误。
解法：对照界面的实际监听信息，区分 DNS 的 53 端口与代理端口；撤销没有对应监听服务的回环地址配置。
需要更强证据时，可以在物理网卡上抓取传统 DNS 流量，关注 UDP/TCP 53 的目标地址和测试域名。只看虚拟网卡上的请求容易忽略最终出站。看到物理网卡上的加密代理流量是正常现象；看不到 53 端口流量，也不能排除直接发往 DoH 服务的查询，因此仍需结合浏览器设置与内核日志。
常见问题与修复后的复测标准
为什么换了远程 DNS，检测还是显示原来的运营商？
先确认浏览器是否使用独立安全 DNS，再确认 DNS 设置已经保存并重启内核。随后核对测试域名是否被直连规则命中。只更换服务器地址而不修改查询出站，通常无法改变查询经过的网络路径。
系统代理检测正常，其他程序还会泄漏吗？
可能。检测页只能覆盖当前浏览器触发的查询。对不遵循系统代理的程序，应单独检查其代理和 DNS 选项，或启用并验证 TUN 接管；不要用一次浏览器检测代表所有应用。
检测页显示多个国家，是不是一定没有配置好？
不一定。公共解析服务可能采用分布式出口，地址库也可能有误差。先关闭额外的浏览器解析路径进行对照，再根据出站日志和物理网卡流量判断，不要只按国家标签删除服务器。
开启 TUN 后网页全部打不开，应该先改什么？
先关闭 TUN 恢复原连接，再检查虚拟网卡、路由权限和启动解析循环。恢复到能工作的配置后，一次只修改一个项目；不要同时叠加 FakeDNS、全局路由和新的 DNS 模板。
修复完成后，按“系统代理测试、TUN 测试、实际应用测试”分别记录结果。每次都核对网页出口、解析器、浏览器安全 DNS 状态及内核错误日志。若保留国内直连，应把预期直连的查询与必须代理的查询分开记录，避免把正常分流误报成泄漏。
- 必须代理的测试域名没有意外出现在本地明文 DNS 查询中。
- 远程 DNS 连接命中预期出站，日志没有持续超时或启动解析循环。
- 重启客户端和浏览器后结果可重复，切换网络后重新验证。
- 需要恢复浏览器安全 DNS 时，单独开启并复测其连接路径。