很多运维人员或者自行部署WireGuard的个人用户，在遇到隧道接口地址不通、路由异常、地址冲突类故障时，经常东敲命令西翻日志，漏掉核心排查信息反而反复走弯路，本文梳理的所有排查阶段必须留存的关键信息，覆盖从本地配置到远端联动的全环节，能帮使用者快速缩小故障范围，避免无效的配置修改操作。
本地节点WireGuard配置文件内的接口段原始定义
排查时第一份要记录的信息，就是存储在/etc/wireguard目录下对应配置文件里，[Interface]区块下Address字段的完整原始内容，不要只凭记忆记录你以为的网段，要把完整的CIDR格式内容完整抄录或者截图留存，很多新手排查时容易把子网掩码位数写错，或者把IPv4和IPv6的地址段混写，没留存原始配置的话，回头核对的时候根本找不到最初的错误点。
这里还要同步记录配置文件里ListenPort的绑定地址参数，很多用户默认配置时写的是0.0.0.0，但如果之前手动修改过绑定到某个物理网卡的私网IP，后续物理网卡地址变动之后，WireGuard接口的监听服务会直接失效，连带接口地址也无法被系统路由识别，很多人排查时只会反复核对Address字段，完全忽略了监听地址和接口地址的联动关系。
系统内核层面识别到的WireGuard接口实时状态
接下来要完整记录ip addr show wg0（对应你实际使用的WireGuard接口名）命令输出的全部内容，不要只截取inet后面的地址段，要确认接口的状态标记是UP还是DOWN，很多时候配置文件里写了完全正确的地址，但之前手动执行过wg-quick down命令之后没有重启隧道服务，接口处于关闭状态，内核根本不会加载你配置的接口地址，这时候ping不通完全是接口未启用的问题，和地址配置本身没有关系。
还要同步记录ip route show table all命令里，对应WireGuard接口的所有路由条目，很多用户会自定义策略路由表，把WireGuard接口地址的路由放在非主表的位置，排查时只查询主路由表根本看不到对应条目，就会误以为接口地址没有被系统正确加载，后续反复修改配置反而把原本正常的路由规则搞乱。
对端节点的WireGuard对等体地址映射规则
接下来要记录对端配置文件[Peer]区块下的AllowedIPs字段里，和本端接口地址对应的匹配规则，很多人遇到的接口地址不通故障，根本不是本端配置出错，是对端的AllowedIPs里没有把本端的接口CIDR完整加进去，反而混入了之前测试时遗留的不相关公网IP段，导致返回数据包根本找不到正确的路由路径。
这里还要注意区分AllowedIPs的实际作用边界，它不是单纯的访问控制列表，同时也是WireGuard内核模块自动生成对端路由的依据，如果你记录的信息里发现对端的AllowedIPs把本端接口地址拆成了多个零散小网段，大概率是之前多人修改配置留下的冗余规则，很容易出现地址匹配冲突的问题。
跨节点连通性测试的原始反馈信息
最后要记录的是两端互ping对方WireGuard接口地址的完整输出内容，包括返回的具体错误类型，不要只简单记成通或者不通，如果返回的是Destination Host Unreachable，大概率是接口地址的路由配置存在问题，如果返回的是Permission Denied，就要排查系统防火墙有没有放行WireGuard接口的入站出站流量，很多人排查时漏掉了报错类型，反而要花大量时间去核对原本没问题的地址配置。
还要同步记录wg show命令输出的最新对端握手时间，如果握手时间一直停留在几分钟之前，说明两端的WireGuard隧道本身都没有成功建立，这时候根本到不了接口地址互访的阶段，反复修改接口地址的配置完全是无效操作。
很多新手排查WireGuard接口地址相关故障时，最常见的误区就是上来就直接修改配置，不做任何信息留存，往往改了三五次之后连最初的正确配置是什么都忘了，把所有关键信息按顺序记录下来之后，你甚至可以直接把这些信息同步给其他熟悉WireGuard的运维人员，不需要额外描述场景对方就能直接定位问题，大幅降低故障排查的沟通成本。
