WireGuard 连接故障通常表现为握手成功但无法上网、完全无法握手、或连接频繁断开。排查时应优先确认对等端双方的实时可达性与配置一致性，避免盲目重置网络栈或重装驱动。由于 WireGuard 采用对等端模型，双方角色对称，客户端同样可以配置监听端口，且 UDP 与 TCP 使用相同数字并不代表同一个监听端点，混淆这一点是常见错误来源。
检查握手状态与 Keepalive 设置
在 WireGuard 管理界面或系统状态中查看 Handshake 时间戳是否更新。若长期无握手，水母VPN检查对等端配置中的 PersistentKeepalive 字段（注意是单数形式）。该参数用于主动发送 keepalive 数据包以维持 NAT 映射，适用于处于对称 NAT 或防火墙后的客户端。若该值为 0 或注释掉，且对端防火墙无状态跟踪，连接可能在空闲一段时间后断开。仅当确认对端能主动访问客户端时，才考虑移除该参数。
验证 AllowedIPs 路由匹配
AllowedIPs 不仅决定哪些目的地流量进入隧道，还参与接收源地址校验。若客户端将 AllowedIPs 设为 0.0.0.0/0，看似吞掉所有 IPv4 流量，但局域网网关（如 192.168.1.1）若不在隧道内网段范围内，水母仍需通过物理接口路由。检查路由表时，确认默认路由或特定网段是否被正确指派给 WireGuard 接口。若 AllowedIPs 配置过窄，会导致部分流量未入隧道而直接泄露；过宽则可能覆盖本地服务，造成局域网访问失败。需结合实际网络拓扑调整，而非默认使用全零掩码。
排查连接故障时需重点监测握手状态与Keepalive参数，确保NAT映射正常维持。
观测 UDP 可达性与端口监听
使用系统级网络工具测试对端 ListenPort 的 UDP 可达性，但需明确 UDP 无连接特性，测试工具可能误报“超时”实际为 ICMP 不可达或静默丢弃。重点检查两端防火墙是否放行 WireGuard 配置的 UDP 端口。注意不要混淆：在客户端配置 ListenPort 不等于开放该端口的 UDP 服务给外部，若客户端在 NAT 后，外部无法直接入站连接该端口。检查日志中是否有“failed to connect”或“no route to host”等具体错误，这些能区分是网络层阻断还是配置错误。不要仅凭 ping 通或 TCP 连通就推断 WireGuard 隧道正常，因为协议栈不同。
区分握手成功与数据面故障
若握手时间戳正常更新但无法访问互联网，问题在数据面而非控制面。此时检查隧道接口的 MTU 设置，通常应小于底层路径 MTU 以避免分片丢包。同时确认对等端 IP 地址是否与 AllowedIPs 前缀匹配，否则数据包会被接口丢弃。查看内核日志或 WireGuard 日志中是否有“dropped”计数增长，这能定位是源地址校验失败还是路由查找失败。数据面故障通常不会导致握手重置，因此握手正常不能作为排除所有故障的依据。
