很多用户在遇到WireGuard连接中断、握手失败、流量不通的故障时，往往第一时间反复修改配置参数、重启服务，反而把原始故障状态覆盖，导致后续排查完全找不到头绪，WireGuard Endpoint：排查时应记录的信息是整个故障定位过程的核心依据，提前按规范留存关键数据，能避免大量无效操作，大幅缩短排障周期。
Endpoint基础配置属性记录
首先要记录的是两端配置文件里的原始Endpoint属性，包括配置文本里填写的对端IP/域名和对应端口，不要直接依赖记忆或者当前界面显示的参数，很多用户配置时用了动态域名，后续域名解析结果发生变化，自己却完全没有察觉，导致本地发送的WireGuard数据包根本找不到正确的对端地址。
除了地址端口之外，还要同步记录本地和对端接口的公钥值，WireGuard的握手过程完全依赖公钥身份校验，哪怕一个字符输入错误都不可能完成握手，不少用户排查时随手重新生成密钥对，却没有同步更新两端的配置，最后把原本只是端口不匹配的小问题，变成全链路密钥错乱的复杂故障。
链路层连通性原始状态记录
接下来需要留存排查初始阶段的系统路由表完整快照，飞鱼重点标注WireGuard接口生成的专属路由条目，以及系统默认路由的指向规则，很多用户之前安装过其他VPN服务，卸载后残留了未清理的路由条目，导致WireGuard生成的流量根本没有从物理网卡发往公网，要是没有记录初始路由状态，后续修改完路由之后根本找不到当初的异常残留条目。
排查WireGuard连接故障时优先留存原始核心配置数据，可避免覆盖故障现场大幅缩短排障周期
还要同步记录本地和对端两端的防火墙规则原始状态，包括本地系统防火墙的UDP出站放行规则，飞鱼加速器对端服务器的UDP入站放行规则，尤其是WireGuard所用端口的放行状态，不少用户排查故障时为了快速连通直接临时放开所有端口的入站权限，故障修复后也不知道哪条规则是多余的，反而留下不必要的安全隐患，提前记录原始规则就能精准定位是不是端口被默认策略拦截。
针对WireGuard使用的UDP传输协议，还要记录初始的连通性探测结果，不要用常规的TCP端口探测工具测试WireGuard端口状态，要使用UDP专属的探测工具验证数据包是否能正常抵达对端，这些初始探测结果能直接区分故障出在链路连通性层面，还是WireGuard本身的配置层面。
运行时日志与统计信息留存
WireGuard接口运行时的实时统计数据是非常重要的排查依据，要在重启服务之前记录最新的握手时间、已收发的字节数、最近收到数据包的来源IP，很多用户遇到握手失败的第一反应就是重启WireGuard服务，直接把之前的运行统计清空，根本看不到此前有没有收到过来自非配置Endpoint地址的数据包，无法判断链路中是否存在异常的路由跳转。
还要同步提取留存对应时间段的系统内核网络日志，WireGuard本身的日志输出非常精简，很多底层网络相关的报错只会出现在内核日志里，比如UDP分片包被防火墙拦截、加密模块加载异常这类问题，都只能在内核日志里找到相关记录，要是等系统日志自动轮转覆盖之后再找，就完全丢失了关键线索。
配置修改过程的全链路记录
很多用户排查WireGuard故障的常见误区是边改配置边测试，改完一个参数没看到效果就立刻修改下一个，最后根本记不清自己调整过哪些参数，哪怕故障后续恢复了，也不知道到底是哪一步修改解决了问题，甚至可能把原本正常的配置改出更多隐性问题。
在每一次修改配置之前，都要先把当前的完整配置文件备份留存，修改之后也要记录对应的测试结果，比如调整了Endpoint的监听端口之后，有没有新的握手日志生成，路由表有没有出现新的相关条目，所有操作步骤和对应结果都记录完整之后，就算自己无法定位故障，把这些完整资料提交给技术支持人员，也能让对方跳过基础排查步骤，直接定位核心问题。
