很多用户在WireGuard VPN连接出现端点不通、握手失败、流量丢包等故障时，经常因为没有提前留存关键运行信息，导致排查过程反复试错、定位效率极低，本文梳理了WireGuard Endpoint排查时应记录的信息清单，覆盖从底层网络到配置细节的全维度内容，帮助运维人员快速缩小故障范围，避免无意义的重复操作。
端点基础网络连通性原始记录
首先要记录的是故障发生时刻，WireGuard两端节点的公网IP、内网虚拟IP的对应状态，不要事后凭记忆补写IP地址，很多动态IP场景下故障恢复后地址会发生变动，直接干扰后续路由规则校验。
运维人员在故障现场逐一记录WireGuard端点排查所需的各项网络状态原始数据
接下来要留存两端节点到对端WireGuard监听端口的连通性测试原始输出，包括ICMP ping的返回结果、UDP端口探测的返回状态，注意WireGuard默认使用UDP协议，不要用TCP端口的探测结果直接判定端口不通，这是很多新手排查时的常见误区。
还要记录故障发生时两端节点的本地网络出口状态，比如是否存在NAT四层转发、运营商层面的UDP协议限制、中间防火墙的会话超时阈值调整，这些信息如果不在故障现场记录，等连接恢复后很难复现当时的网络环境特征。
WireGuard运行时日志与握手状态信息
WireGuard Endpoint排查时应记录的信息里，内核态或用户态进程的实时日志是核心内容，不要只截取最后几行报错，要留存故障触发前后完整的日志片段，芒果包括进程启动参数、接口初始化状态、密钥加载的返回结果。
要手动执行wg show命令获取完整的实时运行输出，不要只截图握手失败的提示，完整输出里包含最新握手时间、传输字节数、对端端点地址、预共享密钥状态等多个维度的参数，芒果VPN很多时候故障点就藏在被忽略的参数异常里。
这里要注意不要把wg-quick的配置文件内容直接等同于运行时状态，芒果很多场景下配置文件修改后没有执行wg syncconf刷新，实际运行的参数和磁盘上的配置并不一致，直接记录运行时输出的参数才具备排查参考价值。
系统路由与防火墙规则快照
很多WireGuard端点故障并非服务本身异常，而是系统层面的路由冲突、iptables/nftables规则拦截导致，排查时要留存故障时刻的系统路由表完整快照，包括主路由表和WireGuard生成的自定义策略路由表的全部条目。
还要记录本地防火墙针对WireGuard接口的入站、出站、转发规则，包括是否配置了基于源目的IP的流量限制、是否开启了数据包伪装规则，部分发行版的系统防火墙会在后台自动更新规则，故障恢复后规则可能已经被改写，事后核对很难找到当时的拦截逻辑。
故障复现的操作路径与边界特征
除了静态的配置和运行数据，还要记录触发故障的完整操作路径，比如是修改了哪条配置后立刻出现故障、还是设备重启后自动出现连接异常、或是切换了本地网络环境后端点才无法连通，这些场景信息可以直接排除大量无关的故障可能性。
最后要记录故障的影响边界，比如是单台客户端无法连接全部端点、还是全部客户端都无法连接同一个服务端端点，或是特定网段的流量走WireGuard隧道才出现异常，芒果VPN这些边界特征可以帮助快速区分是单节点配置错误、服务端全局故障还是路由转发规则的局部问题。
完成所有信息的现场记录后，排查人员就可以脱离故障环境逐步比对参数差异，不需要反复复现故障状态，也能避免不同人员排查时因为信息不对称得出矛盾的判断结论，大幅降低WireGuard端点故障的定位耗时。
