很多用户在遇到WireGuard连接中断、握手失败、免费梯子推荐路由异常等故障时，往往第一时间就修改配置、重启服务甚至重装程序，反而把故障现场的关键信息覆盖，导致后续排查完全没有参考依据。这份汇总清单梳理了WireGuard Endpoint：排查时应记录的信息全流程节点，不需要额外的第三方工具，只需要在故障刚发生时按顺序留存对应内容，就能把绝大多数常见故障的定位时长压缩到很短，避免无意义的试错操作。
端点基础连通性原始状态记录
故障发生后首先要留存的是两端的当前公网IP地址、WireGuard服务监听的UDP端口号，不要先尝试更换端口、切换网络环境，一旦原始的端点地址被修改，原本的网络拦截、地址映射类故障的现场就会被破坏。接下来要在客户端侧用系统自带的mtr、ping工具测试到对端WireGuard端点公网IP的连通状态，完整记录往返链路的丢包和延迟分布情况，如果链路层就无法连通，说明故障出在中间网络传输环节，不需要优先排查WireGuard本身的配置。
紧接着要记录两端系统防火墙的当前生效规则，包括入站方向对WireGuard监听端口的放行策略、出站方向对WireGuard进程的限制规则，很多新手排查故障时习惯直接临时关闭防火墙，反而漏掉了原本存在的端口冲突、IP段封禁规则，就算临时恢复连接也不知道问题根源，后续故障复发还是无法快速处理。
故障刚触发时优先留存原始网络状态信息，可避免破坏故障现场，大幅缩短WireGuard故障定位耗时
WireGuard核心配置一致性校验记录
这部分是WireGuard Endpoint：排查时应记录的信息里最核心的配置类内容，首先要逐行抄录两端的节点公钥、私钥、预共享密钥内容，再比对服务端配置文件Peer条目里绑定的对端公钥、客户端配置里的Endpoint字段地址，大量的握手失败故障都来自于公钥复制错误、客户端填错了服务端的端点地址和端口，提前把这些信息完整留存，就可以直接做文本比对快速定位错误。
接下来要完整记录两端配置里的AllowedIPs字段的全部内容，很多用户遇到WireGuard显示握手成功但是无法访问对端内网资源的问题，本质就是AllowedIPs配置漏写了目标网段，导致路由指向异常，把故障时刻的AllowedIPs条目全部导出，网络加速器就可以直接对照路由规则判断是不是网段范围配置错误。
还要留存故障发生时刻的WireGuard运行日志，不要先重启WireGuard服务，重启后缓存的旧握手失败记录会被清空，日志里会直接输出端点地址不可达、密钥校验失败、端口绑定冲突这类明确的报错信息，不需要再反复做连通性测试就能直接定位故障点。
路由与转发规则关联信息记录
要记录WireGuard服务端当前的IP转发开关状态，以及系统内的iptables或者nftables的SNAT规则生效情况，很多部署教程里的临时转发配置会在系统重启后失效，不少用户排查故障时反复调整WireGuard配置，最后才发现是系统转发开关没有正常开启，提前把sysctl参数的输出结果存下来，就能直接排除这类系统层配置问题。
还要导出故障时刻客户端侧的完整路由表，重点关注WireGuard虚拟接口生成的路由条目，很多部分流量无法走VPN隧道的故障，都是本地原有路由的优先级高于WireGuard生成的路由，导致指定网段的流量没有被导入隧道，把故障时刻的路由表和正常连通时的路由表做对比，就能快速找到冲突的路由条目。
特殊网络场景下的补充状态记录
如果两端都处于NAT网关后方，还要记录故障时刻两端WireGuard配置里的PersistentKeepalive保活参数数值，运营商级NAT的端口映射表会在长时间没有流量的情况下自动过期，不合适的保活间隔会导致WireGuard端点的映射地址失效，无法接收对端的握手报文。
最后还要记录同一网络环境下其他WireGuard客户端的连接状态，如果多个不同设备的客户端都无法连接同一个WireGuard端点，大概率是中间网络运营商或者防火墙拦截了UDP协议流量，不需要反复修改本地配置做无用功。
所有信息记录完成之后再逐项对照排查，不要上来就替换密钥、重装WireGuard程序，很多时候原始现场里的一个小细节就能直接定位故障根源，留存的历史记录也可以作为后续同类故障排查的参考，逐步搭建符合自己网络环境的故障排查知识库。
