VPN 已连接却无法上网？Windows 11 的 8 步排查清单
资料核对：2026 年 9 月 27 日。适用于 Windows 11 上的 VPN 与代理客户端常见排障；界面名称随软件版本变化。下文是诊断方法，不是某家服务的实测报告。
VPN 显示已连接却无法上网，应该先查什么？ 先确认基础网络是否可用，再依次检查服务状态、系统代理、应用接入、DNS 和 TUN 路由。每次只改变一个条件，才能知道是哪一步产生了作用。
本文也适用于部分“机场节点能测速，但网页打不开”的情况。VPN 和代理的接入方式不同，如果不清楚自己的模式，可先阅读 VPN、机场和代理有什么区别。
先按现象缩小范围
| 现象 | 优先检查 | 不能直接得出的结论 |
|---|---|---|
| 关闭客户端后仍无法访问平时可用的网站 | Wi-Fi、认证页面、残留代理、基础网络 | 不能直接认定节点故障 |
| 只有某个节点异常 | 节点连接、服务状态、出口线路 | 不代表所有节点都失效 |
| 浏览器能用，其他软件不能用 | 软件代理设置、接入模式、分流规则 | 不一定是 DNS 问题 |
| 只有一个网站打不开 | 该站状态、规则、响应错误 | 不代表整条网络断了 |
| 开启 TUN 后才断网 | 虚拟接口、出口选择、路由与 DNS | 不应立刻重置所有网络设置 |
第 1 步：建立一个基础网络对照
先在客户端中正常断开连接，再退出客户端。尝试打开两个平时在当前网络可直接访问的网站，并观察其他设备是否正常。
如果浏览器出现酒店、校园或公共 Wi-Fi 登录页面，先完成网络本身要求的认证。也可以让同一台电脑临时连接手机热点进行对照，但需要留意移动数据用量。
有些 VPN 的断线保护会在断开后继续阻止直连。如果你启用了该功能，应根据客户端文档确认当前状态；断开后打不开网页，可能正是保护策略在工作。
这一轮只回答一个问题：不依赖当前隧道时，基础连接有没有可用路径？
第 2 步：检查账号、订阅和单个节点状态
查看客户端的有效配置、订阅更新时间、服务到期状态、流量额度与服务公告。用另一个已经包含在你现有服务中的节点做对照，避免同时导入新的规则或新客户端。
记录连接日志中的原始错误：认证失败、名称解析失败、超时和连接被拒绝，指向的方向并不一样。客户端显示的延迟数字只是一项测试结果，不能替代实际访问目标网页。
如果所有节点都异常，而同一账号在另一台设备上正常，更值得继续查本机配置；如果只有一个节点持续异常，先记录它并切换到可用节点。
第 3 步：检查 Windows 是否留着失效的代理地址
打开 设置 → 网络和 Internet → 代理，查看手动代理及配置脚本。Microsoft 文档说明了这些设置入口，以及 VPN 连接单独使用代理设置的情况。Microsoft：在 Windows 中使用代理服务器
如果这里指向本机地址，而提供该端口的客户端已经退出，采用这项设置的应用可能继续连接一个无人监听的端口。
先记录当前地址和端口。对你自己此前设置的代理，可通过原客户端关闭系统代理，或在系统中暂时撤销该设置，随后重新测试。由组织管理的配置应按管理员提供的方法处理。
不要把教程里的示例端口当作自己客户端的真实端口，也不要把“自动检测设置”当作能够修复所有问题的开关。
第 4 步：确认出问题的应用有没有进入代理
在客户端的连接记录里，观察你打开目标网页或软件时是否出现相应请求。
- 有请求：看匹配了什么规则，走的是直连还是哪个节点。
- 没有请求：检查该应用的代理设置和当前接入模式。
- 浏览器正常但命令行失败：检查命令行程序自己的代理支持，不能直接套用浏览器结论。
“全局模式”可能只是统一处理已进入客户端的流量。先确认流量进入，再讨论它应该如何转发。
第 5 步：分别观察 DNS 和 TCP 连接
在 Windows PowerShell 中，可以使用以下只读诊断命令。www.microsoft.com 只是示例；排查特定网站时应替换成那个网站的真实域名。
Resolve-DnsName -Name www.microsoft.com
Test-NetConnection -ComputerName www.microsoft.com -Port 443 -InformationLevel Detailed
第一条用于查询域名解析，第二条用于观察指定 TCP 端口的连通性及相关网络信息。参数含义可核对 Resolve-DnsName 文档 和 Test-NetConnection 文档。
| 结果 | 接下来怎么查 |
|---|---|
| 域名解析失败 | 检查当前解析器是否可达、客户端是否接管 DNS |
| 解析成功，TCP 测试失败 | 继续检查路由、目标端口或线路，不要只改 DNS |
| TCP 测试成功，网页仍异常 | 查看浏览器错误、HTTPS、代理路径和网站响应 |
这些命令有边界： 它们走的是各自的系统解析与连接路径，不会自动模拟浏览器的 HTTP/SOCKS 代理设置；在 TUN 模式下，又可能受到系统路由接管。TCP 443 成功也不等于 TLS 握手、登录和网页资源全部正常。这些输出是排查证据，不能单独给问题定性。
第 6 步：对照浏览器的安全 DNS 设置
如果只有某个浏览器异常，检查它是否设置了独立的安全 DNS。以 Firefox 为例，DoH 使用加密连接查询域名；保护级别和所选解析服务会影响解析行为。Mozilla：Firefox DNS over HTTPS
先记录原设置，再按浏览器和客户端文档做一次对照，确认两者是否使用了不同路径。不要同时更换系统 DNS、浏览器 DNS 和客户端 DNS，否则很难判断变化来自哪里。
也不建议用“直接访问网站 IP”作为通用结论：很多网站依赖域名选择服务和验证证书，IP 能否打开并不能完整代表 DNS 是否正常。
第 7 步：如果开启 TUN 才出问题，检查路由与出口
确认客户端需要的服务或权限已经正常启用，并检查当前出口网卡是否与实际连接一致。电脑同时启用 Wi-Fi、有线网络、虚拟机网卡或另一套 VPN 时，应特别关注出口和路由。
Mihomo 文档分别提供自动路由、出口接口识别、DNS 接管与严格路由配置；不同系统有不同限制，严格路由也可能影响部分应用。Mihomo：TUN 配置与限制
可以保存配置后，按该客户端文档恢复一组已知可用的设置，再逐项启用需要的功能。不要同时改 MTU、禁用 IPv6、关闭防火墙并重置网络；这样会失去判断依据，也增加恢复难度。
第 8 步：仍未解决时，整理一份可复现记录
把以下模板填好交给服务支持人员，通常比只说“不能用”更有帮助。不要附上订阅链接、密码、Token 或完整个人访问历史。
故障时间与时区：
Windows 版本、客户端版本：
网络类型：家庭宽带 / 手机热点 / 其他
接入方式：系统代理 / TUN / VPN
受影响范围：所有应用 / 单个应用 / 单个网站
更换节点后的结果：
更换网络后的结果：
目标域名与错误提示：
已做的单项修改及结果：
常见问题
Ping 不通，是不是节点坏了？
不能这样确定。ICMP 测试与实际应用请求不同，目标也可能不响应 Ping。应结合客户端连接日志、实际应用和对应协议的检查。
为什么退出客户端后，网页还是打不开？
可能是基础网络异常、残留系统代理，或断线保护仍生效。回到第 1 步和第 3 步，先恢复可解释的网络状态。
重装客户端一定能解决吗？
不能保证。如果问题来自服务端、基础网络或保留的配置，重装后仍可能复现。先做对照并保留记录，确需重装时再按官方说明备份与恢复。
若问题最终指向协议支持，可继续阅读 WireGuard、OpenVPN 和 Shadowsocks 的区别与测试方法。
评论