在日常使用WireGuard搭建站点到站点或者远程访问VPN的过程中，很多用户遇到端点握手失败、隧道频繁断连、内网资源无法访问等问题时，往往反复调整配置却找不到根因，核心原因就是排查过程中没有系统留存WireGuard Endpoint：排查时应记录的信息，大量关键细节随着测试过程被覆盖，导致故障定位效率极低。这份清单覆盖从底层网络到上层配置的全维度必填记录项，帮使用者在排查过程中少走弯路，快速锁定故障点。
端点基础连通性层的记录信息
首先要记录的是故障发生时两端的公网IP、WireGuard配置文件里填写的Endpoint字段原始值，包括对应的端口号，很多人排查时容易忽略核对这部分信息，便宜机场比如对端用动态域名解析绑定公网IP，IP变动后域名没有及时更新，配置里的Endpoint字段还是旧的IP地址，所有流量都会发往无效地址。核对后的预期结果是配置内的端点地址和对端当前实际公网访问地址完全匹配，常见误区是直接ping对端的新公网IP，忘了配置里的旧地址才是WireGuard实际发包的目标，测试结果完全没有参考性。
接下来要记录两端的ICMP可达性测试结果，包括从本地设备直接ping对端Endpoint的IP的连通状态，以及traceroute的完整路径记录，测试时还要备注本地是否同时开启了其他VPN或者代理服务，一分机场避免本地流量被其他隧道转发，得到错误的路径测试结果。
技术人员正在逐一核对记录WireGuard端点故障排查所需的关键网络信息
WireGuard核心运行状态记录项
要完整记录两端执行wg show命令的全部输出内容，包括最新的握手时间、系统识别到的对端公网端点实时值、隧道启动后累计传输的上下行字节数，还要核对配置内的对端公钥、预共享密钥是否和预期值完全一致。如果输出里显示最新握手时间远早于故障发生时间，说明两端的密钥协商过程已经中断，不需要再浪费时间排查上层内网路由问题。
要同步记录故障发生时两端的防火墙规则状态，包括本地系统的firewalld、ufw放行规则，还有前端路由器的端口映射配置，WireGuard默认基于UDP协议传输，很多用户排查时只放行了对应端口的TCP流量，UDP报文全部被拦截，自然无法完成握手。还要同步记录系统内的iptables NAT规则，确保隧道内网段的转发策略没有被误修改。
还要记录故障复现的完整触发条件，比如故障是只要传输大流量就出现，还是闲置一段时间后自动断连，端点所在的NAT网关有没有配置特殊的UDP会话超时规则，这些信息可以直接区分故障是传输链路不稳定导致，还是没有配置保活机制导致NAT会话被回收。
隧道内网连通性验证的留存信息
要记录隧道建立后两端内网虚拟IP的互ping结果，还有跨端点访问内网资源的连通性记录，很多场景下公网端点连通正常、WireGuard握手也成功，但内网虚拟网段的路由配置错误，没有把对应网段的路由指向WireGuard虚拟接口，就会出现公网通但内网完全无法访问的问题，留存当时的系统路由表输出就能直接定位这类配置错误。
还要记录两端系统内核日志里和WireGuard接口相关的所有报错信息，比如dmesg输出里有没有出现UDP校验和异常、接口MTU不匹配的提示，部分跨运营商的链路中MTU设置不合理会导致大尺寸报文直接被丢弃，小数据包可以正常传输，这类问题不查看内核日志很容易误判成端点被运营商封禁。
边界场景下的补充记录信息
要记录故障发生时两端设备的网络环境属性，比如本地设备是处于家用宽带的CGNAT网络后，还是在企业内网的多层NAT节点后，对端的端点是直接暴露在公网，还是部署在云服务商的安全组、便宜机场反向代理之后，很多时候云服务商的安全组默认拦截非白名单的UDP报文，不记录环境属性很难想到是云端的访问控制策略拦截了隧道流量。
最后还要完整记录排查过程中每一步修改配置的操作记录，比如调整Endpoint的端口号、一分机场修改保活间隔之后的运行状态变化，避免反复修改配置后遗忘原始状态，故障复现时无法回溯根因，也能为后续同类故障的排查留存可参考的历史记录。
