网络图标显示错误但 VPN 正常？三项检查

通知区域显示没有网络，私有应用却仍在工作，于是有人想改 VPN 配置直到图标恢复正常。这是把三种不同的观察混成了一件，而其中只有一件与隧道有关。把它们分开，图标问题才不会变成一次不必要的配置变更。

先给这项观察命名，再决定是否真的需要修复。

三种观察，三个问题

Windows 的连通性指示回答的是系统的检测过程对当前网络配置文件得出了什么结论。VPN 客户端的状态回答的是该客户端是否报告已建立的伙伴会话。一次新的应用操作回答的是某一个具体请求是否沿它实际走的那条路径成功。三者都是有效结果，任何一个都不能替代其他。把它们混在一起，就会得到针对错误层面的修复。

典型的混淆是把第一个当成后两个的总结。一台机器可以拥有健康的隧道和可用的私有资源，却仍被判定为无网络，因为该判定来自一次从未到达其服务的探测。

Get-NetConnectionProfile
Get-DnsClientServerAddress -AddressFamily IPv4
Test-NetConnection -ComputerName internal.example -Port 443

在动任何东西之前，把三个结果连同时间戳一起写下来。这类报告大多在这一步就解决了，因为分歧一旦写出来就变得明显。

分类过程实际做了什么

Microsoft 的 NCSI 概述描述了向已配置的探测服务发送 HTTP 请求进行主动探测，并结合对网络流量的被动观察。未能获得预期响应，可能来自该路径上的路由、代理或其他环境条件。它比一般可达性测试更具体，范围也比人们以为的更窄。正是这种窄，才是分歧出现的全部原因。

它从不审计加密、解析器的隐私，也不审计应用是否被授权。正面分类不能证明每个应用都走隧道，负面分类也不能证明隧道已断。

反向的混淆同样常见。隧道可能已建立，而当初为它构建的应用却没有可用路由、没有可用的解析器或没有权限。客户端指示报告的是比你所需更早、更窄的结果。

分歧本身告诉你该修什么

私有访问正常而系统说没有网络：出问题的组件是探测路径，而不是隧道。记录接口和时间，然后请网络负责人查看探测如何到达其服务，以及策略是否阻断它。用一个宽泛的互联网路由替换可用的私有访问配置，改变的是图标，扩大的是你并未要求扩大的访问范围。

隧道报告已连接，而访问所需服务的新请求失败：这是真实故障，把图标称作误报会跳过它。比较应用错误、配置的预期范围、正在使用的解析器以及所选路由。仅私有隧道并非为提供公网出口而设计，期待它承担公网出口属于范围错误，而不是缺陷。

保留记录，只改一条路径

在相应应用里做一次新操作，而不是看从早上就开着的页面。保持必要的阻断生效，任何获准的直接对比都应通过客户端有文档记录的控件完成，而不是手动改路由。

如果受管代理或防火墙挡住了预期的探测，就与它的负责人一起修正那条具体路径。Microsoft 的指引提醒不要把关闭主动探测当作解决办法，而硬编码地址例外或改注册表并不能说明是哪个组件的回答不对。

变更之后，把三个结果都留在工单里：分类、会话状态和应用结果。如果只是图标变了，你只知道指示变了，并不知道数据库或站点现在可用。