VPN 客户端显示“已连接”，网页却一直转圈，这类问题很少是单一原因。更有效的做法是从下往上分层验证：先确认隧道真的通，再看流量有没有走进隧道，然后是名称解析、包大小，最后才是服务端的转发。每一层都有一条命令能给出明确结论。
第一层：隧道本身有没有建立
“已连接”只代表客户端进程在运行，不代表握手完成。WireGuard 用 wg show 查看 latest handshake，没有这一行或时间很久以前，就说明握手没成功；OpenVPN 看日志里是否出现 Initialization Sequence Completed。握手失败的常见原因是服务端端口被防火墙拦住、两端密钥不匹配，或者本机时间偏差过大。
怎么判断是握手问题还是后面的问题
能 ping 通隧道对端地址（例如服务端的内网地址）就说明隧道已通，后面都是路由或转发问题；连隧道对端都 ping 不通，就停在这一层继续查。
第二层：流量有没有走进隧道
在 Linux 上执行 ip route get 8.8.8.8，输出里的 dev 应当是隧道网卡；Windows 上用 route print 看 0.0.0.0 的默认路由。如果配置的是分流，目标地址不在 AllowedIPs 或推送路由范围内，流量会走原来的网卡，表现为“连上了但没有任何变化”。
默认路由被其他软件抢走怎么办
同时运行多个 VPN 或代理软件时，后启动的会改写路由表。关掉其他网络类软件后重连，用 route print 对照前后的变化即可确认。
第三层：域名解析是否正常
先用 IP 直接访问，例如 ping 8.8.8.8。IP 通而域名不通，基本就是 DNS 问题：隧道配置里的 DNS 服务器在服务端不可达，或系统仍在使用本地网络下发的 DNS。Linux 用 resolvectl status 查看当前链路的 DNS，Windows 用 ipconfig /all。
第四层：MTU 与大包丢失
症状是小页面能打开、大页面和 HTTPS 握手卡住。隧道封装会占用头部空间，隧道网卡的 MTU 小于物理网卡。可以用带不分片标志的 ping 探测：Linux 用 ping -M do -s 1372 8.8.8.8，Windows 用 ping -f -l 1372 8.8.8.8，逐步减小数值直到能通。
怎么算出应该设置的 MTU
探测到的最大不分片负载加 28（20 字节 IP 头加 8 字节 ICMP 头）就是这条路径的 MTU。隧道 MTU 要再减去封装开销：WireGuard 在 IPv4 上占 60 字节、IPv6 上占 80 字节，默认值 1420 就是按 1500 减 80 预留的。例如探测到负载 1372，路径 MTU 为 1400，保守起见把隧道 MTU 设为 1320。
第五层：服务端是否开启转发与地址转换
如果是自建服务端，需要确认 net.ipv4.ip_forward 为 1，并且有把隧道网段转换成出口地址的规则，可用 iptables -t nat -L POSTROUTING -n 检查。缺少这一条时，客户端的包能到服务端，回包却回不来。
症状与所在层对照
| 症状 | 可能所在层 | 验证方法 |
|---|---|---|
| 没有 latest handshake | 隧道 | wg show，查看服务端端口与密钥 |
| 连上后 IP 没变化 | 路由 | ip route get 或 route print |
| ping IP 通，域名不通 | DNS | resolvectl status、ipconfig /all |
| 小页面能开，大页面卡住 | MTU | 不分片 ping 逐步缩小 |
| 隧道内通，外网不通 | 服务端转发 | ip_forward 与 NAT 规则 |
