WireGuard 握手成功但没有数据时，双方最近完成了身份验证，却不能说明测试包去了哪里。生成一条受控流量，对比两端新鲜的发送与接收增量，便能判断应检查本机路由和 peer 选择、外层路径、远端转发与回程，还是 DNS、MTU 等后续层。

完整 VPN 指南覆盖全部连接阶段。本文只从预期 peer 的 latest handshake 已经更新开始。

关键要点

当前握手证明 peer 互相验证，不证明某个应用流量使用隧道。［1］

只比较同一测试前后的计数增量，不看混有背景流量的累计值。

本机 TX 不增长，先查路由或 peer 选择；只发不收，说明存在单向断点。

TX 与 RX 都随测试增长后，应转查 DNS、MTU、传输或应用层。

不要共享私钥、PSK、完整配置或原始诊断 dump。

怎样诊断 WireGuard 握手成功但没有数据？

WireGuard 握手会在预先知道静态公钥的 peer 间建立新会话密钥；传输数据是握手后的另一类消息。［1］所以当前握手是强身份与当时可达性证据，却不是通往目标的合成事务。

wg 会显示最近握手与累计传输字节。［2］只有在窄范围探针前后记录，这些数字才有定位价值。保活、其他应用或早期流量都可能令累计值非零，而当前请求从未进入隧道。

cryptokey routing 让目标与来源前缀参与 peer 选择：出站包按目标地址分配 peer，入站包则按发送 peer 的允许来源校验。［3］与 peer A 握手成功，不能证明系统没有把测试包送往其他接口或 peer B。

七步数据路径检查

步骤 1：定义一条受控数据探针

选一个你获准测试的目标地址与协议，最好是在远端网络上有已知预期回应的服务，例如内部网关地址或受控 Web 端点。记录准确时间、目标、地址族、来源接口与预期结果。

不要一开始就用主机名。DNS 会引入第二个请求、解析器路由、缓存，以及可能多个 IPv4 和 IPv6 结果。先用数字地址，数据包路径正常后再测试名称。

探针前立即记录目标 peer 在两端的最近握手时间和 TX/RX 总量。然后只发送一个小型、有边界的请求，再次记录相同字段。不要持续制造流量，因为重叠的探针会让增量难以归属。

到此停止：如果预期 peer 的最近握手并不新鲜，那是握手或身份问题，而不是本文讨论的握手后状态。可用服务器回应但握手失败指南分离可达性与验证阶段。

步骤 2：读取 TX/RX 增量矩阵

方向以测试发起端的角度标注：“客户端 TX”指发起端 peer 发出的加密传输字节；“服务器 RX”指对应 peer 收到的加密字节。确切字节数可能包含协议开销，不必完全相等；要寻找的是与探针时间和方向相关的变化。

本次探针的新鲜观察	首先检查	原因
客户端 TX 不增长	客户端路由、来源策略、peer 选择	探针没有成为该 peer 的传输数据
客户端 TX 增长，服务器 RX 不变	外层端点路径、过期端点、防火墙、NAT 状态	加密数据已发出但未抵达
服务器 RX 增长，未见转发包	来源前缀、本机输入/转发、防火墙	WireGuard 收到数据，下一跳失败
已转发，无回应返回	目标服务、上游过滤、NAT 或回程	请求离开 peer，但回应未回来
回应到服务器，客户端 RX 不变	返回 peer、允许来源、外层回程	回应未成为客户端接收数据
客户端 TX、RX 都增长	DNS、MTU、TCP/TLS 或应用	加密路径已双向传输

任一行只是下一条证据边界，并非最终结论。配置变更前，用同一探针复现两次。

步骤 3：本机 TX 不动时检查选择过程

查询操作系统对确切目标所选的路由、接口和源地址。接口活跃、peer 近期握手时，更具体的主表路由、策略规则、本地子网或其他隧道仍可获胜。

再把目标与所有 peer 的 AllowedIPs 对照。重叠条目或意外的窄前缀可选中另一 peer；多 peer 环境应记录所有可能候选的计数，而不是只看你预期的那一个。

确认应用没有绑定到其他接口或地址，并且它所在的网络命名空间看到的路由与你检查的一致。容器、虚拟机、按应用 VPN 控制和分流排除项，看到的网络可能与宿主机 shell 不同。

只做一项受支持的路由或 peer 选择修正。复测同一探针；如果选中的接口或计数增量没有变化，就恢复原状。

步骤 4：数据发出却未到达时检查外层路径

最近的握手与丢失的传输包可以同时存在，因为握手后网络状态可能变化：远端漫游、NAT 映射过期、移动网络切换路径，或防火墙对后续包采用不同策略。

比较两端当前记录的端点与预期会话，但不要无谓公开私有地址。如果是漫游 peer 发起了最近的握手，对端通常会学习到它最新的已验证端点。［3］网络切换之前的旧观察不足为据。

在外层接口上使用获准的抓包或防火墙计数，找到第一个缺失的方向。不要暴露私钥，也不要关闭主机防火墙。若一次新握手立即让数据到达，应记录这种时间关系；它更支持路径状态问题，而非密钥不匹配。

步骤 5：远端收到数据后跟踪内层包

服务器 RX 增长后，先判断内层目标是服务器本身还是其后方网络。本机服务要核对监听地址、端口、地址族和输入规则；后方目标要核对 IP 转发、转发防火墙与出口接口。

然后确认回应如何返回客户端前缀。NAT 设计需要准确范围的转换与状态；路由设计需要上游知道 WireGuard 客户端网络。目标若为另一 WireGuard peer，服务器双向映射必须唯一。

不要自动加宽泛 NAT。这可能让单一探针工作，却掩盖错误拓扑。计数指向互联网网关后，使用已连接但无法上网清单继续检查 DNS、双栈与完整回程。

步骤 6：双向数据增长后离开握手层

客户端 TX、RX 随探针同时增长，说明加密传输数据已双向移动。用户操作仍失败时，应停止轮换密钥或修改 peer 身份，转而测试下一层。

先比较数字地址与域名，再比较小请求和较大回应，并分开测试 IPv4、IPv6。小型双向流量成功而大传输停滞，符合 WireGuard MTU 问题；仅名称失败则指向解析器。TCP reset、TLS alert、HTTP 错误或应用鉴权回应，也证明隧道已把请求送到更后层。

应用超时需要做关联。确认 TX/RX 增长属于本次请求，而非保活或背景进程。必要时暂停无关流量，使用独特目标与短时间窗。

步骤 7：保留证据并恢复初始状态

记录初始握手时间、四组计数快照、路由结果、端点观察和证据首次消失的位置。只保留确实移动断点且符合设计的最小修正。

删除临时路由、防火墙规则、流量生成器和测试服务。持久 peer 映射有变时，应核对管理真源，防止重启恢复故障。不要提交 wg show all dump；它可能泄露公开身份、端点、允许前缀与 PSK 状态。

若当前握手存在却怀疑身份配置，先确认该握手实际使用哪一 peer 和密钥代次。密钥不匹配指南提供安全公钥对照；沉默或计数缺口不能独自判定错误端。

第二条隧道能当作对照测试吗？

当你自己的 peer 能完成握手却传不了任何数据时，在同一台设备上再起一条独立隧道，是区分设备问题和 peer 问题的低成本方法。先断开你自己的 peer，再安装 AethoVPN，连接推荐位置，并让真实数据通过它，比如加载一个网页或下载一个小文件：如果传输成功，说明设备和接入网络能承载隧道流量，下一个要查的就是你的 peer 的 AllowedIPs、转发或回程路由。AethoVPN 显示的是连接状态，而不是原始 peer 计数或抓包，所以 TX/RX 增量对比仍要在你自己的服务器上完成。对比之前可先用邮箱开始 3 天免费试用。

总结

只在预期 peer 最近握手已更新时进入本流程。
围绕一个数字地址探针对比新鲜 TX/RX 增量。
客户端 TX 不动指向选路；单向增量可定位丢失方向。
服务器 RX 后再分离本机服务、转发、NAT 与回程。
双向计数增长后应转查 DNS、MTU、传输或应用层，而不是握手。
保存范围最窄的证据、撤除实验改动，绝不分享秘密材料。

常见问题

最近握手能证明 AllowedIPs 正确吗？

不能。双方可以完成身份验证，但测试目标仍可能选择其他路由或 peer，接收端也可能不允许该内层源地址。

测试失败时为什么累计传输量仍非零？

累计值可能来自旧会话、保活或其他流量。应在一次受控请求前后记录两端 TX/RX，只比较该窗口的增量。

网络路径改变后握手还能显示为最近吗？

可以。路径、端点或 NAT 映射可能在上次交换后改变。把外层接口和端点证据与这次失败探针对齐。

客户端 TX 增长而服务器 RX 不变说明什么？

本地 peer 已生成加密传输数据，但远端在该窗口没有记录接收。下一步检查外层端点路径和过滤。

服务器 RX 增长但目标没有收到数据怎么办？

检查内层源地址、本机输入与转发、防火墙、转发状态和出口选择。加密数据已到达，故障点已越过握手层。

TX 与 RX 都双向增长时应该轮换密钥吗？

不应。双向增量证明当前 peer 关系可承载该探针，应转查 DNS、包大小、传输或应用行为。

保活足以证明应用数据正常吗？

不足以。保活只维持状态，不会验证目标、响应大小、DNS 查询或应用协议。应另发一条有边界的请求。

免责声明：本文仅提供一般技术排障信息。只检查你获准管理的系统和流量，尽量减少抓取的数据，绝不泄露私钥或预共享密钥。

来源：

WireGuard, "Protocol & Cryptography": https://www.wireguard.com/protocol/
WireGuard Tools, "wg(8)": https://git.zx2c4.com/wireguard-tools/tree/src/man/wg.8
WireGuard, "WireGuard: Next Generation Kernel Network Tunnel": https://www.wireguard.com/papers/wireguard.pdf

Sources checked 2026 年 9 月 12 日。

延伸阅读：

WireGuard 握手成功但没有数据：收发增量、节点与回程排查