很多用户在遇到WireGuard隧道连通异常、路由转发失效的问题时，第一反应是直接修改私钥、监听端口等参数，完全忽略了WireGuard接口地址相关的现场信息留档，往往排查到一半就丢失了关键线索，反而拉长了故障定位的周期。这份核心信息清单完全围绕WireGuard接口地址：排查时应记录的信息展开，覆盖从本地配置到对端映射的全链路排查留档要求，适合个人用户和运维人员在故障出现的第一时间对照记录，避免后续排查无据可依。
本地WireGuard接口的实时配置快照
排查的第一步绝对不要修改任何现有配置，优先把当前系统中WireGuard对应虚拟接口的全量地址状态完整导出记录，不要只参考之前保存的wg-quick配置文件，不少用户会在调试过程中临时通过ip addr命令给接口新增额外地址，这类临时配置不会写入静态配置文件，很容易被后续排查过程遗漏。
这里需要记录的核心内容包括接口当前绑定的所有IPv4、IPv6地址段，对应地址的子网前缀长度，以及每个地址的作用域标识，明确区分该地址是全局公网地址、内网私网地址还是链路本地地址，不少新手会误把链路本地地址当成可用隧道地址配置给对端，后续出现无规律丢包的问题时很难溯源。
本地路由与同网段地址占用记录
相当高比例的WireGuard连通性故障，根源都是隧道接口配置的地址段，和本地物理网卡的现有内网段出现了重叠，或是和系统中其他VPN服务的虚拟接口地址段产生冲突，排查时必须把当前系统全量路由表中所有指向WireGuard接口的路由规则全部摘出记录，不能只看隧道相关的自定义路由。
还要同步记录当前本地局域网内同网段的存活主机地址清单，确认你分配给WireGuard接口的所有地址都没有被其他物理设备占用，很多用户习惯直接用常见的10.0.0.0/24作为隧道专用段，刚好部分品牌路由器的默认内网段也是这个地址池，最终出现隧道流量根本走不到对端，直接被本地路由转发到内网网关的反常现象。
对端节点的接口地址映射校验信息
WireGuard本身没有内置的地址合法性校验机制，对端节点配置的AllowedIPs字段，直接决定了哪些流量会被导入隧道完成转发，排查时要把两端配置里的接口地址互相对照记录，确认本地WireGuard接口的地址已经被完整写入对端节点的AllowedIPs规则中，没有出现地址段漏写、前缀长度配置错误的低级问题。
还要同步记录两端节点上针对WireGuard接口设置的iptables或nftables转发规则，确认没有规则把隧道接口的入站出站流量直接丢弃，不少用户配置了全局默认拒绝的防火墙规则，忘记给WireGuard接口单独放行对应地址段的转发权限，最终出现隧道显示握手成功，但完全无法ping通对端接口地址的情况。
动态网络场景下的状态留档信息
很多移动场景下的WireGuard客户端本身没有固定的公网地址，处于多层NAT的内网环境中，排查时要记录故障发生瞬间WireGuard接口的实时地址状态，包括最近一次握手的时间戳、对端节点上报的最新接口地址，避免后续排查时客户端已经切换了WiFi或者移动网络，之前的故障现场完全消失。
还要记录故障发生时，系统ARP表或者ND表中，和WireGuard接口地址对应的映射条目，确认没有出现地址冲突导致的MAC地址漂移，把隧道流量错误转发到了本地其他无关设备上，这类隐性冲突很难在静态配置里直接发现，必须留存故障瞬间的动态表项才能定位。
不少用户排查故障时习惯边改配置边调试，完全不记录之前的接口地址状态，最后调整到一半连最初的原始配置是什么都记不清，反而引入更多新的地址冲突问题，按照这份清单完整记录所有核心信息之后，哪怕故障暂时没有完全解决，后续回溯排查时也能快速复现当时的网络环境，不用从头开始重新梳理所有配置项。
