握手成功却上不了网：Windows 11 上要先修哪一层
握手只能证明 UDP 交换成功。要判断是哪一层失效：Windows 安装的路由、它使用的解析器，还是出口。
在 Windows 11 上，新近的握手常常伴随着什么都打不开的浏览器。握手只证明与对端的 UDP 交换已经完成。它说明不了 Windows 安装的路由、所用的解析器，也说明不了 出口是否真的在转发任何流量。
四个条件决定上述哪一层失效。按顺序走一遍只要几分钟，而重写密钥更费时间且什么也改变不了。
先定位层级，再动密钥
按这个顺序检查三个目标。先试隧道侧的地址，再试按数字写的公网 IP，最后试主机名。链条在哪里断，就是哪一层的问题。第一步失败是路由，第二步是转发或 NAT，第三步是域名解析。
这个顺序就是全部方法。它能避免把 DNS 故障误判成隧道损坏，而那是这里最常见的错误方向。
wg show
Find-NetRoute -RemoteIPAddress 1.1.1.1
Resolve-DnsName example.com -Server 1.1.1.1如果握手时间为空
握手时间为空，说明加密交换从未完成。因此故障在路由之前。先看端点地址和端口，再看网络是否过滤 UDP。丢弃 WireGuard 流量的主机会造成这种情况，从旧配置里抄来端点的客户端也一样。
只有发出、没有收到的字节是另一种情况。这指向 NAT，或把流量退回错误位置的防火墙。
如果路由输给物理网卡
做全局隧道时，对端网段必须覆盖你要访问的目标。即使配置了全量规则，Windows 有时仍保留物理网卡的默认路由。把全量规则拆成 0.0.0.0/1 加 128.0.0.0/1，会生成两条更具体的路由，从而在查表中胜出。这种拆法是官方记录的变通做法，而不是偏好。
用 route print 或查询公网地址来确认。选中的接口应当是隧道网卡。如果物理网卡仍然胜出，先修对端网段，再动服务器。
如果地址通、域名不通
WireGuard 只搬运 IP 包，对 DNS 没有任何主张。在接口段加一行 DNS =，或者通过 Windows 设置网卡。没有它时，按地址 ping 能通，但每个主机名都失败，用户就把这报告成没有网络。
检查连接后 Windows 实际使用哪些服务器。物理网卡上残留的解析器可以解释部分失败：有的名字能解析，有的不能。应当清掉它，而不是在上面再加一个。
如果 Windows 机器就是出口
Internet Connection Sharing 启用后会重写地址，可能把共享网卡挪到另一个网段。仍指向原地址的客户端就会失效。注册表值 ScopeAddress 和 StandaloneDHCPAddress 控制该网段，而且这一设置在重启后可能回退。
还有两个 Windows 特有的冲突值得一看。Routing and Remote Access 服务可能干扰隧道。为错误架构打包的安装程序会失败，而错误信息从不提架构。
修好测试指出的那一层，然后重跑同样的三个目标。修好了主机名测试却弄坏了隧道地址的改动，就是改在了错误的层上。