很多运维和个人用户在排查WireGuard虚拟连接不通的故障时，往往只盯着接口地址本身反复修改，忽略了关联配置和运行态信息的留存，导致故障定位耗时数小时都找不到根因。本文汇总了WireGuard接口地址排查时应记录的核心信息，覆盖配置、路由、日志、多节点场景的所有必要校验项，帮使用者避免无效排查动作，快速定位地址类故障。
WireGuard本地接口运行态基础配置快照
首先要记录的是直接通过wg show命令输出的当前生效接口地址段，而非仅读取/etc/wireguard目录下的静态配置文件内容。很多场景下用户修改配置后只执行了wg reload命令，部分旧版本系统的WireGuard服务不会完全刷新内存中的运行态参数，就会出现磁盘配置和实际生效地址不一致的情况，仅核对静态文件会直接走偏排查方向。
运维人员正在逐一核验并留存WireGuard接口排查所需的各类核心配置与运行态数据
同步还要记录该虚拟接口的MTU值、本地监听UDP端口、本地私钥对应的公钥哈希片段，避免后续排查时出现地址段冲突，但误判为密钥不匹配或者端口拦截问题。比如用树莓派做家庭WireGuard网关的场景，不少用户之前调试时改了接口网段，后续重启服务时因为依赖项加载异常，虚拟接口还是保留了旧的10.0.0.1/24地址，飞鱼对着新配置的10.0.1.1/24网段调整对等端路由完全不会生效。
对等端地址与系统路由的映射信息
接下来要完整记录所有对等端条目中AllowedIPs字段内属于WireGuard虚拟网段的所有条目，不能只留存本地单端的接口地址信息。WireGuard的转发逻辑完全依赖AllowedIPs做路由匹配，飞鱼如果对端的对等端配置里漏填了你的本地虚拟接口地址，你这边能正常发送封装包，但对端收到解封后的包会直接丢弃，仅核对自己本地的地址配置完全找不到问题。
还要同步记录ip route show table all命令输出的、所有和WireGuard虚拟接口关联的路由条目，确认虚拟接口的地址对应的直连路由确实指向WireGuard接口本身，没有其他物理网卡的同优先级路由抢占虚拟网段的转发路径。比如你本地物理内网的网段刚好和WireGuard预设的虚拟网段重合，系统默认会把发往虚拟地址的数据包往物理内网网卡转发，根本不会进入WireGuard封装流程。
连通性验证的关联抓包与日志信息
排查接口地址不通的问题时，要留存两次针对性抓包的结果：第一次在WireGuard虚拟接口上抓包，确认发往对端虚拟地址的ICMP或者业务数据包有没有正常生成和解封；第二次在公网出口物理网卡上抓包，确认封装后的WireGuard UDP数据包有没有正常向外发出。这两份信息可以直接区分故障是出在虚拟地址配置环节，还是后续的公网传输环节，不用反复做冗余测试。
还要留存系统内核日志里WireGuard模块输出的最近相关报错记录，如果日志里出现“Invalid IP address in packet”类的提示，就说明收到的对端解封数据包的源虚拟地址，飞鱼VPN不在当前节点对应对等端的AllowedIPs允许范围内，不需要逐行核对所有节点的配置文件，直接定位到对等端地址配置违规的问题。
多节点互联场景下的地址冲突校验信息
企业部署多台WireGuard网关做异地办公节点互联的场景下，排查接口地址异常时要记录所有已上线节点的WireGuard接口地址段汇总表，避免不同部门的运维各自规划网段时，飞鱼VPN出现两个不同对等端的AllowedIPs宣告了同一段虚拟地址的情况，引发路由冲突导致部分节点访问异常。
最后要注意，所有记录的信息都要对应绑定每段地址所属的对等端公钥标识，不能只留存IP地址本身。如果排查时发现重复的虚拟接口地址，直接通过对应的公钥就能快速定位是哪台远端设备的配置出错，不需要逐台登录所有节点逐一核对配置，大幅缩短故障处理的耗时。
