公司 VPN 连上却打不开内网域名？Windows NRPT 与分流 DNS 排查

公司 VPN 已连接，内网域名却打不开，先核对完整名称、Windows 的有效解析策略和内部 DNS 可达性。**把 DNS 换成公共解析器，通常不能替你获得公司内部记录；nslookup 成功，也不能单独证明 NRPT 分流解析正常。**解析出地址之后，还要确认服务流量进入了正确路由。

作者：小仓｜资料核对日期：2026-10-14

分流 DNS 与分流路由解决不同问题

分流 DNS 决定某些名称交给哪个解析服务；分流路由决定去往某个 IP 的数据经哪条网络路径。公司 DNS 能返回内网地址，不代表你的电脑已经有到该地址的可用路由。

Windows 的 NRPT（名称解析策略表）可以按名称空间决定 DNS 客户端行为，例如对某个完整名称或域名后缀应用指定策略。Microsoft 的 VPN 名称解析说明 解释了 NRPT、DNS 后缀与持久规则的关系。

本文适用于核对 Windows DNS 客户端及相关 VPN 配置。不要求每一种第三方 VPN 都使用 NRPT，也不把策略列表为空直接认定为故障。需要先向管理员确认该连接预期采用哪种解析方式。

第一步：用完整名称固定测试目标

先取得管理员提供的完整内网域名，例如 portal.corp.example。只输入 portal，结果可能依赖后缀搜索列表；两台电脑后缀不同，就不是相同查询。

下面均为 PowerShell 示例，名称与地址是占位内容，必须替换。测试 DNS 时在完整名称末尾添加点，可以明确目标，减少后缀追加造成的干扰；这一方法见 Windows DNS 客户端排障文档。末尾点用于此处查询，不要求修改浏览器书签或企业应用地址。

Resolve-DnsName -Name 'portal.corp.example.' -Type A -DnsOnly -NoHostsFile

记录查询成功、超时、名称不存在或其他原始错误。-DnsOnly 限定 DNS 协议，-NoHostsFile 跳过 hosts 文件；它们的用途见 Resolve-DnsName 文档。这次对照刻意排除了 hosts，不能直接等同于所有应用的默认行为。

如果业务使用 IPv6，应再用 -Type AAAA 记录对应结果。A 查询成功只说明这次取得了 IPv4 记录，不证明 IPv6 路径也正常。

第二步：读取接口 DNS 与有效 NRPT

在出现问题的同一台 Windows 电脑上、VPN 保持连接时执行：

Get-DnsClientServerAddress
Get-DnsClientNrptPolicy -Effective | Format-List

第一条读取接口配置的 DNS 地址，见 Get-DnsClientServerAddress。第二条读取当前有效 NRPT，-Effective 的含义见 Get-DnsClientNrptPolicy。两条都是读取，不添加、删除或重置策略。

重点核对三个问题：目标完整名称或后缀有没有预期规则；规则里是否指向管理员确认的 DNS；VPN 连接后看到的有效信息是否与下发配置一致。不同规则可能含有不同字段，不能仅凭某个 NameServers 字段为空就删掉整条策略。

如果门户首页能打开，登录跳转后才失败，记录跳转后的实际主机名，并对它重新做查询。首页与接口可能属于不同名称空间，针对一个完整名称的规则不一定覆盖另一个名称。让管理员核对预期匹配范围，比把首页测试结果套用到全部内部服务更有用。

接口信息也不是全部答案。例如，Microsoft 明确说明，使用 Entra ID 认证的 Azure VPN Client 会使用 NRPT，相关 DNS 不显示在 ipconfig /all 中，见 Azure VPN Client 可选配置说明。这是一种具体实现，不能推广成所有 VPN 都有同样输出。

第三步：比较默认路径与指定内部 DNS

保持 VPN、名称和记录类型不变，向管理员确认的内部 DNS 做一次指定服务器查询：

Resolve-DnsName -Name 'portal.corp.example.' -Type A -Server '10.20.0.53' -DnsOnly -NoHostsFile

10.20.0.53 只是示例地址，不能拿它当你公司的 DNS。-Server 指定查询服务器；这是一项隔离对照，不是完整复现默认选择 DNS 的过程。

对照结果	接下来优先核对
默认失败，指定内部 DNS 成功	名称匹配、有效策略与默认解析路径
两种都超时	到内部 DNS 的路由、访问控制与服务状态
指定内部 DNS 返回名称不存在	拼写、记录是否存在及是否查询了正确 DNS
两种均成功，浏览器失败	浏览器自己的 DNS、代理路径与目标服务

表格提供调查方向，不凭两条命令宣布根因。还应记录缓存与测试时间；切换多项设置后再比较，容易把缓存变化误当成策略修复。

为什么不用 nslookup 验证 NRPT？

VPNv2 CSP 文档 明确指出，NRPT 设置用于采用 Windows DNS API 的应用，nslookup 不走该 API，应使用 Resolve-DnsName 检查 NRPT 功能。应用自行实现 DNS 时，也不能仅凭 Windows 查询正常就认为它使用了同一路径。

只有浏览器失败时，可继续阅读本站 Chrome 与 Firefox 安全 DNS 排查，结合企业浏览器策略核对，不随意取消受管理设置。

第四步：解析成功，再测实际服务

对管理员确认的内网地址与实际 TCP 服务端口做测试：

Test-NetConnection -ComputerName '10.20.0.80' -Port 443 -InformationLevel Detailed

IP 与 443 都是示例，需替换。查看所选源地址、接口及 TCP 结果；Microsoft 的 Test-NetConnection 文档 说明了端口测试和路由信息。

TCP 成功不证明 HTTPS 名称校验、登录权限和应用响应正常；失败也不必然是 DNS 问题。若与本地网段重叠或选错接口有关，可参考 VPN 后 NAS 与局域网访问排查。不要用浏览器直接访问 IP 的证书报错，代替原域名的完整验证。

哪些信息交给管理员更有用

时间与时区、Windows 与 VPN 客户端版本：
完整目标名称、A 或 AAAA：
VPN 状态、同时启用的代理或 TUN：
相关有效 NRPT 字段与接口 DNS：
默认查询和指定内部 DNS 查询的结果：
目标服务端口、所选接口及 TCP 结果：
是否只有浏览器失败、本次只改了什么：

本文没有对公司网络做实测。内部域名、地址和策略输出按需脱敏后交给管理员即可。持久解析规则可能按设计在断开 VPN 后保留；发现残留时先核对配置意图，不自行清空 NRPT 或把内网名称写死进 hosts。