在日常运维WireGuard站点到站点、远程访问VPN的故障时，很多管理员会跳过关键信息留存步骤，直接反复修改配置试错，反而拉长故障定位周期，甚至误改正常运行的peer配置引发连锁网络问题。WireGuard Endpoint排查时应记录的信息覆盖从底层网络连通性到上层隧道状态的全链路节点，所有记录内容都可以通过系统自带工具和WireGuard原生命令直接获取，不需要额外部署第三方探针，能帮助运维人员快速缩小故障范围，避免无意义的重复测试。
初始Endpoint配置原始快照
排查故障的第一步不能直接修改wg0接口的配置文件，首先要导出当前运行态的完整WireGuard配置快照，包括所有peer的Endpoint字段原始值、公钥、预共享密钥标识、允许的IP段列表，以及本地接口的监听端口、私钥信息。很多故障的诱因其实是之前的运维人员临时修改了Endpoint的IP或端口，没有同步更新配置文件，重启服务后配置回滚引发隧道断开，留存原始快照可以直接对比配置变更前后的差异，排除人为误改的可能性。
排查WireGuard隧道故障前先留存原始配置快照，可大幅缩小故障范围、缩短定位周期
这里的记录不能只截图wg show命令的输出，要把输出内容重定向到单独的日志文件中，同时标注记录的精确时间，避免后续排查时混淆不同时间点的配置状态。如果是动态域名解析的Endpoint场景，还要同步记录当时解析得到的IP地址，排除DDNS更新不及时导致的Endpoint指向错误问题。
底层网络连通性基础状态
很多WireGuard隧道不通的故障本质和VPN配置无关，只是两端的底层公网连通性出现异常，这部分需要记录的信息包括从本地节点到对端Endpoint IP的ICMP连通性、UDP端口可达性测试结果，不能只靠ping通就判定链路正常，因为WireGuard完全基于UDP传输，很多运营商或防火墙会放行ICMP报文，但拦截对应端口的UDP流量。
记录UDP连通性状态时，可以用nc命令在两端分别做端口监听和发测试包，同时用tcpdump在本地公网网卡抓包，确认发往对端Endpoint端口的UDP报文是否正常发出，有没有被本地防火墙拦截，返回的ICMP端口不可达报文的源IP是哪一侧的设备，以此判断拦截动作发生在链路的哪个节点。这部分记录可以直接排除运营商中间节点拦截UDP、对端节点防火墙未放行WireGuard端口的常见故障。
WireGuard隧道运行时实时状态
WireGuard本身提供的wg show命令输出的实时运行参数，是排查Endpoint故障的核心依据，需要记录的内容包括对应peer的最新握手时间、最近一次从对端接收字节数、往对端发送字节数、当前的Endpoint字段实际生效值。如果最新握手时间远大于预期的保活间隔，就说明两端的握手报文没有成功送达对端。
很多管理员容易忽略记录的一个细节是Endpoint字段的自动更新状态，当WireGuard节点开启了动态端点自动更新功能后，收到任意来自对端公钥的报文，就会自动把对应peer的Endpoint值更新为报文的源IP和端口，这个自动变更的过程不会同步写入/etc/wireguard目录下的配置文件，飞鸟VPN版本更新指南一旦隧道断开，管理员很难回溯之前自动更新后的正确Endpoint地址，提前记录运行时的实时状态就能避免这个问题。
两端节点的路由与防火墙规则状态
不少WireGuard Endpoint故障的表象是隧道显示握手成功，但两端内网网段完全无法互通，这部分需要记录本地节点的公网网卡路由表、WireGuard接口的路由规则、iptables或nftables的转发规则，确认发往对端允许IP段的流量确实被路由到了wg接口，没有被其他优先级更高的路由规则抢占转发路径。
同时还要记录两端节点的源NAT规则状态，很多部署在云服务器上的WireGuard节点，公网IP是映射到内网网卡的浮动IP，如果没有正确配置UDP报文的源地址转换规则，WireGuard发出的握手报文源地址会使用内网网卡的私网IP，飞鸟对端返回的报文无法正常路由回本地节点，直接导致Endpoint对应的peer始终无法完成握手。
所有记录的信息不需要做额外的加工整理，只需要按时间顺序归档，后续遇到同类故障时可以直接对比历史正常状态的参数，飞鸟VPN版本更新指南快速定位异常节点，不需要每次排查都从零开始重复所有测试步骤，大幅降低WireGuard VPN运维的时间成本。
