先给答案
不要先重装 VPN。先拿同一个目标做三次对照：用 FQDN 查 DNS、用目标 IP 查路由与 TCP 端口、再把结果和 VPN 网关/防火墙日志对上。VPN 图标显示 Connected，只能说明隧道或会话已建立，不等于企业 DNS 已正确分流、到目标网段的路由存在，也不等于访问策略允许这个用户和设备访问目标服务。
本文只处理一个问题：VPN 已显示连接，但企业内网网页、文件服务或业务端口打不开。下面的地址、域名、用户名和日志均为示意，不是煜企客户现场或本机实测。
先固定一个可重复的目标
选一个确实属于企业内网的 FQDN 和一个明确端口，不要把“网页打不开”当成唯一证据。示意目标为 portal.corp.example、解析地址 10.20.30.40、HTTPS 端口 443；corp.example 和地址均为文中编造的占位符。
| 要回答的问题 | 证据 | 结果如何解释 |
|---|---|---|
| 名字能否解析到企业地址？ | nslookup portal.corp.example | 无记录、超时或返回公网地址，先查 DNS/NRPT/后缀 |
| 去目标网段走哪条路？ | ipconfig /all、route print 10.* | 没有 VPN 接口或目标网段路由，先查地址池/分流路由 |
| 目标端口是否可达？ | Test-NetConnection portal.corp.example -Port 443 -InformationLevel Detailed | TcpTestSucceeded=False 只说明 TCP 未建立，需继续看策略/服务/回程路由 |
| 网关是否看见这次请求？ | VPN/RAS/防火墙同一时间窗日志 | 有拒绝才定位规则；没有记录先查路径、网关或日志范围 |
Microsoft 的 nslookup 用于诊断 DNS 基础设施；ipconfig /all 显示各适配器的地址、掩码、网关等 TCP/IP 配置；route print 显示本机路由表；Test-NetConnection -Port 用于测试目标 TCP 端口。命令依据已在本内容包的来源记录中列明。
第一步：先查 DNS，不要把名字问题误判成网络不通
在 VPN 已连接状态执行以下命令。参数使用示意值，替换成实际内网 FQDN 和端口：
ipconfig /all
nslookup portal.corp.example
nslookup portal.corp.example 10.20.10.53第一条看 VPN 虚拟适配器是否拿到预期地址、DNS 服务器和后缀；第二条看系统默认 DNS 返回什么；第三条是把查询明确发给示意的企业 DNS。不要把 10.20.10.53 当成通用配置，也不要为了“验证”修改 DNS。
Windows VPN 的名称解析会先检查 NRPT；没有匹配时才按接口 metric 和 DNS 后缀继续解析。Microsoft 还说明，Always On VPN 可以为企业命名空间指定 DNS 后缀和 NRPT 规则。因此，“VPN 已连接但短名称打不开”可能是 DNS 分流或后缀问题，不应直接归因于防火墙。Microsoft VPN name resolution
判断顺序：
- FQDN 无法解析，但直接访问已确认的目标 IP 可以建立 TCP：优先查 NRPT、企业 DNS、DNS 后缀和 DNS 服务器可达性。
- FQDN 解析到公网或错误网段：先保留
nslookup输出，检查内部 DNS 记录、分流规则和缓存；不要直接改 hosts 文件掩盖问题。 - FQDN 正确解析到企业地址：进入路由检查，不要继续反复刷新浏览器。
第二步：用目标 IP 检查 VPN 路由
route print 10.*
Test-NetConnection 10.20.30.40 -Port 443 -InformationLevel Detailedroute print 需要看到覆盖 10.20.30.40 的目标网段或主机路由，并确认它指向 VPN 接口；具体接口、下一跳和 metric 取决于企业配置。Microsoft 的 Always On VPN 文档区分 split tunnel、force tunnel、应用路由和 exclusion route；所以“连接成功”不能推出“所有内网网段都自动进入隧道”。Always On VPN networking features
如果没有匹配路由，记录 route print、VPN 分配地址和配置版本，交给负责 VPN 网关/路由的人员检查地址池、分流网段、汇总路由和回程路由。不要在不清楚企业路由设计时执行 route add 或删除现有路由；那会改变现场状态，且可能把问题从单台客户端变成更难回滚的配置偏差。
实物照片仅展示一台 VPN 防火墙设备的外观，不能从外观判断 DNS、路由或 ACL 状态；它不是本文示例网络或煜企客户现场。摄影：Zuzu / Wikimedia Commons，CC BY-SA 3.0；原照片仅转换为 WebP，未裁剪。
第三步：端口不通时才对照 ACL、主机防火墙和服务
Test-NetConnection portal.corp.example -Port 443 -InformationLevel Detailed
Test-NetConnection 10.20.30.40 -Port 443 -InformationLevel Detailed这两次测试的目标是区分“名字路径”和“IP/端口路径”，不是证明应用一定健康。若 FQDN 与 IP 都解析正确、路由也存在，但 TCP 仍失败，应在同一时间窗对照：
- VPN 网关是否给该用户/设备分配了访问企业网段的策略；
- 网关到目标网段的转发与回程路由是否存在；
- 防火墙/ACL 是否允许该源地址到目标地址的 TCP 443；
- 目标主机是否监听该端口，以及主机防火墙是否允许来自 VPN 地址池的源地址。
日志示意：
2026-09-27T10:14:22Z action=deny src=10.99.8.27 dst=10.20.30.40:443 rule=REMOTE_TO_APP这行只是示意格式；不要把它当成煜企现场日志、厂商固定字段或真实时间。若网关没有同一时间窗的命中记录，先确认查看的是正确设备、正确策略集和正确时区，再下结论。
一张可交接的排查清单
把以下内容一次性发给网络或系统负责人，通常比“VPN 连上了但打不开”更容易交接：
- 发生时间、时区、用户名/设备标识（按企业隐私规范脱敏）；
- VPN 配置名称、连接状态、客户端地址池信息；
ipconfig /all中 VPN 接口的地址、DNS 和后缀；nslookup的 FQDN 查询结果，以及查询使用的 DNS 服务器；route print中覆盖目标地址的路由行；Test-NetConnection的目标、端口、TcpTestSucceeded与InterfaceAlias；- VPN 网关、防火墙和目标主机在同一时间窗的允许/拒绝记录；
- 明确写出：同一目标用 FQDN 失败、用 IP 成功，还是两者都失败。
不要上传完整凭据、Cookie、私钥、未脱敏业务日志或客户原始数据。命令输出可能包含内部网段和主机名，外发前按组织规则脱敏。
常见误判与边界
“Connected”不是“已授权访问所有内网资源”。NIST SP 800-207 将访问拆成身份认证与授权，并强调按资源和请求执行最小权限；本文因此把 VPN 会话、路由和目标资源策略分开验证，而不是用“在内网”作为默认信任证明。NIST SP 800-207
本文不提供通用 VPN 产品选型、零信任迁移方案、厂商配置模板或未经确认的改路由命令。实际企业环境可能使用第三方客户端、IPv6、代理、应用层网关或多级防火墙，排查顺序需要按真实拓扑调整。
FAQ
VPN 显示已连接，为什么内网域名还是打不开？
最先验证 DNS：用 FQDN 查询并确认返回的是企业地址，再检查目标网段路由。VPN 会话建立不代表 NRPT、DNS 后缀或内部 DNS 已按预期工作。
直接用 IP 能打开，域名打不开，说明 VPN 坏了吗？
不一定。这个现象更像名称解析、DNS 分流或证书/应用层名称依赖问题。先保留 FQDN 与 IP 的对照结果，再由 DNS 和应用负责人继续确认。
route print 有目标网段，为什么端口仍然不通？
路由只说明本机选择了路径，不证明网关转发、回程路由、ACL、主机防火墙或服务监听都允许。继续用 Test-NetConnection 和同一时间窗的设备日志做对照。
可以直接执行 route add 修好吗？
不建议把它当第一修复动作。静态改路由会改变客户端状态，且可能掩盖集中配置、地址池或回程路由问题。先采集证据并确认变更窗口、回滚方式和实际拓扑。
相关解决方案
如果证据已经显示问题跨越 VPN 网关、交换路由、防火墙和内网服务，下一步应先整理拓扑、策略与日志时间线，再评估网络设备和交换路由配置，而不是反复重装客户端。可查看网络设备与交换路由服务。
相关阅读
如需把一次故障排查纳入持续的账号、设备和交接流程，可阅读企业 IT 运维服务。
下一步
如果你已经整理好脱敏后的拓扑、策略和时间线，可通过联系煜企说明问题范围；本文不承诺特定修复时长或结果。
来源与说明：本文命令与 VPN 行为依据 Microsoft Learn 和 NIST 官方资料；示例地址、域名、日志和判断过程均为教学示意，不代表现场实测。