WireGuard 没有 latest handshake？Endpoint、UDP 与密钥匹配排查

WireGuard 隧道显示“已启用”，却一直没有 latest handshake，先确认流量确实进入了目标 peer，再检查 Endpoint、UDP 通道和双方密钥。**隧道开关、TCP 端口测试和一次 Ping 都不能单独证明 WireGuard 握手成功。**本文针对首次建立不起来的连接；曾经正常、空闲后才断流的情况应另行分析。

作者：小仓｜资料核对日期：2026-10-12

先分清“没有握手”和“握手后无法上网”

观察到的状态	优先调查
接口未能启用、配置导入失败	本机配置和客户端日志
已启用，但没有成功握手记录	流量触发、Endpoint、UDP 与密钥
曾有握手，空闲时没有更新时间	先发起受控流量，核对能否恢复
握手已成功，业务仍不可用	隧道路由、DNS、转发与目标服务

WireGuard 快速入门 说明，它在不用时尽量保持安静，主要在 peer 要发送数据时工作。看到旧握手时间不应立即认定故障；测试过程中是否有新的有效请求同样重要。

第一步：读取状态，再触发一个已知目标

Linux 上已经安装 wg 且有管理权限时，可以读取以下信息。wg0 是示例接口名，需替换为实际名称：

sudo wg show wg0 latest-handshakes
sudo wg show wg0 endpoints
sudo wg show wg0 transfer

三条命令分别读取握手时间、当前 Endpoint 和传输计数，不修改配置。参数定义见官方 wg 手册。Windows 或手机用户应查看所用客户端提供的握手、计数器与日志，不能把 Linux 命令直接套用。

记录测试前的状态，再访问管理员提供、应当经过该隧道的 IP 或服务，随后读取一次状态。若用域名测试，DNS 失败可能让请求尚未到达目标；若用 Ping，目标禁用 ICMP 又可能造成误判。因此以握手变化和指定服务结果共同判断，不要求随便找一个公网地址当测试对象。

不要为反馈问题直接导出整份配置。showconf 和 dump 可能包含密钥；这里选用只读的具体字段，输出中的公钥、Endpoint 和内网信息也应按需脱敏。

第二步：检查流量是否真的选中了这个 peer

WireGuard 会按目标地址匹配 peer 的 AllowedIPs；系统还需要把数据交给对应接口。这是两个相关但不能混为一谈的条件，机制见 官方概念说明。

例如，配置只覆盖某个内网网段，却用不在该范围内的网站来测试，可能根本没有触发目标 peer。先与管理员核对测试目的地址、AllowedIPs 和实际路由，不要为了“试一下”把所有网段都改成默认路由。

在 Linux 的常见使用方式中，wg-quick 通常根据 AllowedIPs 添加系统路由，但其 Table 选项可以改变这一行为，其他网络管理工具也有自己的处理方式，见 wg-quick 手册。不能只看配置文件中有 AllowedIPs，就断定路由已经安装。

第三步：核对 Endpoint 与 UDP 入口

Endpoint 是对端的地址或主机名加端口，不是你的隧道内网 IP。它可以随收到的正确认证数据更新，所以运行状态中显示的地址需要与当前实际部署一起核对，不能只盯着一份旧配置截图。

把检查分成三段：

1. 本机到入口：Endpoint 主机名能否解析，当前网络能否到达选中的 IPv4 或 IPv6 地址。
2. 入口到服务：管理员确认实际 UDP 监听端口、防火墙及必要的 NAT 转发与部署一致。
3. 回程：服务端是否能把回复送回客户端所在网络，而非只看到发出去的包。

不要照抄常见端口号。WireGuard 可以配置不同 ListenPort，外部 NAT 端口也可能与内部监听端口不同；普通使用者应以服务方提供的有效配置为准。

为什么 Test-NetConnection 成功仍然没握手？

Windows 的 Test-NetConnection -Port 测试 TCP；Microsoft 文档 对此有明确说明。WireGuard 使用 UDP，因此同一个数字的 TCP 端口成功或失败，都不能代替 UDP 握手验证。浏览器能访问服务器上的 HTTPS 页面，也只证明了那条网页连接。

保持配置不变，换另一种获准网络重复同一测试，可以缩小范围。但“手机网络成功、Wi-Fi 失败”只是路径差异证据，仍可能涉及路由、NAT、防火墙或来源限制，不能直接宣布运营商封锁了某个协议。

第四步：让双方核对身份，而非随意重生成密钥

客户端 peer 中应配置服务端公钥，服务端对应 peer 应配置客户端公钥；各自私钥留在各自设备。如果还配置了 PresharedKey，也需要双方一致。重置一端私钥会改变身份，另一端未同步更新时，反而会制造新的不匹配。

WireGuard 对未获正确认证的请求可以保持沉默，见 协议中的 DoS 防护说明。因此“服务端没有回复”既可能是数据没到，也可能是身份不匹配，单靠客户端超时无法区分。

有服务端权限的管理员可在同一时间窗观察：请求有没有到入口、是否被本机规则丢弃、有没有回复。抓到 UDP 包也不等于包已通过认证。没有管理权限时，提供脱敏时间和客户端日志，请服务方对照检查即可，不扫描无关端口。

握手成功后，切换到业务排障

如果本轮已有成功握手，下一步检查测试服务、隧道地址、转发与 DNS，而不是继续围绕“端口没开”猜测。局域网目标可参考 VPN 后 NAS 与打印机排查；仅空闲后失联，可参考 PersistentKeepalive 与 NAT 排查。保活不会纠正错误公钥或错误入口地址。

留下可对照的记录

测试时间与时区、客户端版本：
接口或隧道名称：
网络类型、Endpoint（按需脱敏）：
应经过隧道的目标与服务：
测试前后握手、收发计数变化：
双方公钥是否核对一致（不附私钥）：
管理员观察到的请求与回复：
本次只改变的条件与结果：

本文提供排查方法，没有实测某个节点。把“是否发起、是否到达、是否通过认证、是否能访问业务”分开记录，才能避免一次改动多个配置后失去根因线索。