很多用户在调试WireGuard VPN连通性的过程中，经常跳过基础信息留存步骤，反复修改配置却找不到故障根因，把WireGuard接口地址排查时应记录的信息按类别梳理清楚，能大幅降低接口地址冲突、网络加速器路由异常这类问题的定位效率，避免无意义的重复调试，也能减少不同运维人员交接排查工作时的信息差。
WireGuard本地端接口的基础配置快照
排查的第一步首先要记录的是wg show命令输出的本地接口地址段，不能只记录单个IP，要连带子网掩码长度一起留存，很多新手配置时会误把/24的虚拟网段写成/32，后续跨节点的路由转发会直接失效，记录时还要和/etc/wireguard目录下对应配置文件里的Address字段做比对，确认运行时的生效配置和持久化存储的配置没有偏差，避免之前的临时修改没有写入配置文件，重启服务后现场状态直接丢失。
运维人员正在逐项核对留存WireGuard接口排查所需的各类关键配置信息
还要同步记录本地WireGuard接口的监听端口、已经绑定的物理网卡地址，很多搭载多网卡的设备，WireGuard接口会默认绑定内网网卡地址，导致对外节点握手失败，这类信息如果不提前记录，排查中途重启服务或者切换网卡配置后，就很难复现最初的故障场景。
对端节点的接口地址映射信息
很多人排查时只记录对端的公网端点地址，忽略WireGuard协议层面的对端虚拟接口地址，排查时要把Peer配置段里AllowedIPs字段包含的所有虚拟网段逐一记录，确认本地侧路由指向的对端虚拟IP，和实际对端节点的WireGuard接口地址完全匹配，避免出现地址指向偏差导致的连通性故障。
还要记录对端节点侧配置的本地虚拟接口地址，避免出现两端把同一段虚拟网段分配给不同节点的情况，这类地址冲突不会触发系统层面的明确报错，只会出现部分网段能通、部分网段访问异常的现象，没有提前留存地址分配记录的话，小熊很难快速定位到是地址分配重叠的问题。
系统路由表中关联WireGuard接口的条目
排查接口地址连通性问题的时候，不能只查看WireGuard自身的配置，要把ip route命令输出的所有带WireGuard接口名的路由条目完整记录，包括路由的下一跳、优先级、所属的路由表ID，很多开启了策略路由的设备会把WireGuard的路由放到自定义路由表里，普通路由查询命令看不到对应条目，很容易直接误判为接口地址配置错误。
还要同步记录系统的iptables或者nftables中和WireGuard虚拟接口相关的转发规则、MASQUERADE规则，很多时候接口地址本身配置完全正确，但是防火墙规则没有放通虚拟网段的转发权限，导致两端虚拟IP之间无法正常访问，这类问题如果不提前记录防火墙规则，很容易浪费大量时间反复调整接口地址配置。
连通性测试过程中的现场状态信息
每次针对WireGuard接口地址做ping或者traceroute测试的时候，要把测试的源IP、目标IP、返回的结果完整记录，不能只简单标注“通”或者“不通”，比如源IP用物理网卡公网IP去ping对端虚拟接口地址，和用本地WireGuard虚拟接口地址去ping的返回结果完全不同，分开记录才能区分是三层路由问题还是WireGuard协议封装的问题。
还要记录测试期间wg show命令输出的最新握手时间、流量收发计数，如果接口地址配置完全正确但是一直没有新的握手记录，说明两端的公网端点连通性本身存在问题，和虚拟接口地址没有关联，不需要再花时间调整地址相关的配置。
很多运维人员排查时习惯边改配置边调试，不保留每一步的原始记录，最后改到配置面目全非，连最初的错误现象都无法复现，把上述几类信息按顺序记录完整，哪怕遇到跨节点的复杂组网问题，也能快速缩小故障范围，不需要反复在多个节点之间跳转核对配置，大幅提升WireGuard接口相关故障的排查效率。
