日常运维WireGuard VPN隧道的过程中，不少管理员遇到连通性故障时只会反复重启两端服务、临时修改配置试错，没有留存现场关键信息，导致相同故障反复出现也找不到根因。WireGuard Endpoint排查时应记录的信息是整个故障定位链路的核心依据，完整的现场记录清单能帮你跳过不必要的重复复现步骤，快速区分是配置参数不匹配、公网链路拦截还是底层路由规则冲突类的问题，大幅降低跨站点隧道的排查耗时。
故障发生时的两端基础运行状态记录
排查的第一步不要上来就修改任何配置，优先在两端分别执行系统对应的服务状态查询命令，把输出的服务运行时长、最近的内核日志报错片段直接完整复制留存，不要只模糊记录“服务处于运行状态”这类没有参考价值的结论。
接下来要完整留存两端执行wg show命令得到的全部输出内容，包括当前WireGuard接口的监听端口、已导入的所有对等端公钥、分配给本地接口的虚拟网段IP、预设的对端WireGuard Endpoint地址和端口，哪怕你确定之前的配置完全正确，也要把现场实际查询到的结果原封不动记录下来。
这个环节的常见误区是用记忆里的旧配置代替实际查询结果，很多时候你之前做端口冲突排查时临时修改过监听端口，后续忘记复原，没有现场记录的话，你会花大量时间去排查公网链路问题，完全想不到本地服务的监听端口已经和预设配置不一致。
公网链路可达性相关的现场记录
接下来要记录从本地端到对端WireGuard Endpoint的三层连通性测试结果，测试不能只做普通ICMP ping，要同时留存普通ping的返回结果、指定对端Endpoint对应UDP端口的连通性探测结果，因为WireGuard默认使用UDP协议传输，很多中间网络节点会拦截非知名端口的UDP包，普通ping能通完全不代表WireGuard的传输通道可用。
还要记录故障发生瞬间两端的公网出口IP地址，和配置文件里预设的对端WireGuard Endpoint地址做比对，在动态IP场景下，很多故障都是因为其中一端的公网IP发生变动，而DDNS同步更新不及时，导致配置里的旧Endpoint地址根本指向不到正确的设备。
如果WireGuard运行在内网设备上，前端经过NAT网关做端口映射，还要记录网关侧的端口映射规则状态，确认你配置的UDP端口有没有被正确映射到WireGuard运行的内网设备上，有没有被网关的出站入站防火墙规则拦截，不少管理员配置映射时误选了TCP协议而非UDP，就会出现两端完全收不到握手包的情况。
WireGuard握手与流量传输的特征记录
你要把wg show输出里的最新握手时间、最近接收的字节数、最近发送的字节数完整记录下来，如果完全没有任何握手记录，说明两端的WireGuard数据包根本没有抵达对端的WireGuard服务进程，故障范围可以直接缩小到链路连通性异常、两端对等端公钥不匹配两类问题，不需要去排查虚拟网段的路由配置问题。
如果有正常的握手记录，但是两端的虚拟网段IP之间无法互访，就要完整留存两端虚拟网卡对应的路由表配置，确认你预设的AllowedIPs规则有没有把需要走WireGuard隧道的网段全部包含进去，有没有出现本地路由优先级更高，把隧道流量导向本地公网接口的冲突问题，这类问题没有原始路由表记录的话，反复修改AllowedIPs规则也很难找到根因。
最后还要记录故障发生前后的网络环境变动信息，比如最近有没有升级过系统内核、有没有新增过全局防火墙规则、有没有更换过运营商接入的网络设备，很多故障本身不是WireGuard服务的问题，是周边环境改动之后没有同步调整隧道配置，完整的环境变动记录能帮你快速定位到触发故障的时间点，不需要做全量的配置回溯。
