不少运维和个人用户在部署WireGuard站点到站点隧道或者点对点VPN链路时，经常遇到接口地址无法ping通、同网段Peer互访丢包、地址配置后不生效等异常，排查时如果零散调取信息很容易遗漏关键线索，拉长故障定位时间。本文结合实际部署场景，梳理WireGuard接口地址排查时应记录的核心信息，帮使用者快速区分配置错误、内核状态异常、路由冲突、地址占用等不同类型的问题。
节点本地的WireGuard持久化配置信息
排查的第一步首先要记录磁盘存储的WireGuard配置文件中Interface段的原始Address字段内容，不能只参考ip命令查到的运行时地址，不少新手修改配置后没有完整重载服务，会出现持久化配置和实际运行参数不一致的情况，后续重启服务后故障会直接复现。记录时要把完整的带子网前缀的地址全部留存，比如10.0.0.1/24，不能只记IP地址本身，很多配置错误是把子网前缀误写为/32，直接导致同隧道内的其他WireGuard节点地址不在同一二层域，完全无法互访。
还要同步记录同配置段内的PrivateKey和ListenPort参数的对应关系，多WireGuard实例批量部署的场景下，经常出现复制配置脚本时的参数错位，导致接口地址和节点私钥不匹配，对端校验通过后转发逻辑异常，加速器这类问题如果没有留存原始配置信息，很难通过运行时状态反向追溯。
运维人员排查WireGuard隧道故障时逐项记录关键配置信息
系统内核层面的接口运行时状态信息
接下来要执行ip addr show 你的WireGuard接口名（通常默认是wg0），把完整的输出内容全部记录，重点对比运行时加载的接口地址和持久化配置里的地址是否完全一致。部分场景下管理员临时用wg set命令修改接口参数，没有同步更新配置文件，运行时的地址和规划的地址段不匹配，后续重载服务后就会出现链路中断。
还要记录ip link show对应WireGuard接口的输出，确认接口的物理状态是UP还是DOWN，不少场景下配置文件里的接口地址完全正确，但管理员之前调试网络时手动把接口设为DOWN状态，地址虽然在内核路由表中存在，但完全没有收发流量的能力，这类问题很容易被误判为地址冲突或者对端配置错误。
额外要留存系统全量路由表中所有和WireGuard接口地址段相关的条目，执行ip route show table all筛选出关联路由，很多时候系统内的其他VPN客户端、自定义静态路由规则，会把发往WireGuard接口段的流量导向物理公网网卡，直接出现本地都无法ping通自身WireGuard接口地址的异常。
对端Peer的关联配置校验信息
要逐一记录所有已配置Peer条目里的AllowedIPs字段内容，确认有没有把本端的WireGuard接口地址排除在允许转发的网段之外。不少用户为了实现全流量走隧道，直接把AllowedIPs设置为0.0.0.0/0，却没有预留本地WireGuard接口段的排除规则，导致隧道内的回包被错误转发到公网，出现能完成握手但接口地址完全不通的现象。
还要用wg show命令输出所有Peer的最新握手时间戳并记录，如果接口地址配置完全正确但长时间没有握手记录，说明底层UDP连通性先出现了问题，不需要优先排查地址段冲突类的问题，先放通两端的WireGuard服务端口即可。
网络环境内的地址冲突校验信息
在WireGuard接口处于启动状态时，用arping（IPv4场景）或者对应邻居发现命令（IPv6场景）扫描整个接口所在的子网段，把扫描到的和WireGuard接口地址重复的设备MAC地址记录下来。不少内网部署场景下，已有其他服务器或者终端占用了提前规划的WireGuard接口地址，两个设备同时响应ARP请求，就会出现隧道内流量随机丢包、时通时断的异常。
还要留存系统dmesg日志中最近和WireGuard模块相关的报错内容，部分低版本内核检测到局域网内存在重复IP地址时，网络加速器会直接自动移除WireGuard接口上配置的地址，这类报错不会出现在WireGuard服务的普通日志里，如果没有专门筛选内核日志很容易被遗漏。
把以上几类信息完整留存后，基本可以覆盖绝大多数WireGuard接口地址相关的故障场景，不需要反复重启服务或者盲目修改配置试错，对照记录的信息逐行比对，就能快速定位配置错误、路由冲突、地址占用三类常见问题，大幅降低故障排查的耗时。
