不少自行部署WireGuard VPN的用户都会遇到endpoint握手超时、连通性时断时续的问题，很多人排查时随手敲几条命令就重启服务，既没留存有效信息，也没法复现偶现的故障，WireGuard Endpoint：排查时应记录的信息都是经过大量实操验证的核心内容，不需要复杂的专业工具就能完成，能大幅缩短故障定位的周期，避免无效的重复操作。
两端同步采集基础网络状态快照，高效定位WireGuard连通性故障
WireGuard Endpoint 两端的基础网络连通快照
首先要记录的不是直接抓包，是endpoint两端设备的公网出口地址、对应WireGuard监听端口的当前状态，比如你在家用边缘路由器上跑WireGuard服务端，手机作为远端endpoint连入的时候，快喵先分别在两端执行基础的网络探测命令，把输出结果完整留存。
这里要注意不能只记通或者不通，要把服务端侧执行ss -ulnp看到的WireGuard进程绑定地址、端口的输出，客户端侧ping服务端公网IP的连续输出，还有UDP端口探测的结果全部存下来，很多新手排查的时候只记“端口没开”，但没留当时的探测时间点，后续发现是运营商临时封端口，没有时间戳的记录根本没法佐证故障场景。
还要同步记录两端设备当前的默认路由表条目，尤其是如果服务端是多WAN接入的场景，很可能WireGuard的endpoint地址绑定到了故障的WAN口上，路由表的记录能直接排除本地路由规则错误导致的转发异常。
WireGuard 运行时的实时握手与流量统计信息
很多人排查故障的时候习惯直接重启WireGuard服务，梯子软件反而把最关键的运行时状态清掉了，正确的操作是先执行wg show命令，把完整输出复制留存之后，再做任何配置修改操作。
这份记录里要重点标注最新一次握手的时间、两端传输的字节数、当前endpoint配置的公网地址和端口，很多场景下用户的家庭宽带公网IP发生了动态变更，但远端的WireGuard配置里的endpoint地址还没更新，wg show的输出里会显示一直没有新的握手请求，对比配置的旧IP和当前服务端的新IP就能直接定位问题。
还要同步记录故障发生时的内核日志片段，也就是dmesg里和WireGuard相关的输出，部分低版本内核的WireGuard模块会出现UDP队列溢出的报错，这类信息不会出现在普通的服务日志里，只有留存当时的内核日志才能定位是系统内核层面的资源瓶颈，不是配置错误。
故障发生前后的防火墙与NAT规则变更记录
WireGuard的endpoint用UDP协议传输，很多连通性故障都和路径上的防火墙、NAT网关的超时规则有关，排查时要把两端设备本地的iptables或者nftables规则完整导出留存，尤其是涉及UDP端口放行、状态跟踪的规则条目。
如果中间路径上有运营商级的NAT设备，还要记录故障发生时客户端的NAT映射相关的配置特征，比如连续发送空包保活的间隔设置，很多时候用户之前修改过保活间隔参数之后故障才出现，对比变更前后的配置记录就能发现是保活间隔太长导致中间NAT映射被回收。
这里要注意常见误区是不要随便把防火墙全部关了测试，关防火墙之后就算连通了也找不到根因，留存原始的规则记录之后再做调整，后续就算故障复现也能对比规则差异，找到之前漏掉的端口放行或者地址伪装规则。
跨场景复现的对比测试信息
如果在本地网络里排查半天找不到问题，还要记录不同接入场景下的测试结果，比如同一个WireGuard客户端，分别用家庭WiFi、手机移动数据、快喵公司办公网三个不同的网络接入点尝试连接endpoint，把每个场景下的连通结果、握手状态记录下来。
这类对比记录能快速区分故障是出在服务端侧、客户端侧，还是中间的运营商链路侧，比如所有外部网络都连不上，大概率是服务端的端口映射或者防火墙规则出错，只有某一家运营商的网络连不上，才是中间路径的UDP传输被限制。
所有这些记录不需要用复杂的工具整理，纯文本存成日志文件就可以，后续遇到同类故障的时候直接对比历史记录，能避免很多重复的无效排查操作，也能在需要求助技术社区的时候提供足够完整的信息，不用反复回溯当时的配置状态。
