很多运维人员和个人用户在部署WireGuard站点到站点或者点对点VPN连接时，经常遇到Peer节点连通异常、虚拟网段无法互访的问题，排查过程中反复翻找配置、重复测试却遗漏关键信息，反而拉长了故障定位的周期。本文围绕WireGuard Peer配置排查时应记录的信息做全流程梳理，按照从底层网络到上层加密规则的排查顺序，列出所有需要留存的关键内容，帮助使用者快速缩小故障范围，尽量避免无意义的重复操作。
基础Peer身份标识与本地接口配置信息
排查第一步首先要记录两端的Peer公钥对应关系，很多新手配置时容易把本端私钥和对端公钥搞混，这一步要先分别导出本地WireGuard接口的私钥指纹，和配置文件里标注的对端Peer公钥做比对，确认没有出现密钥填反的低级错误。
接下来要记录本地WireGuard接口的监听端口、分配的虚拟网段IP地址，还有路由表中指向这个虚拟网段的规则是否生效，很多时候连通异常不是Peer配置出错，樱花猫VPN是本地虚拟接口没有正常启动，虚拟IP没绑定成功，直接导致发往对端的数据包根本没有进入WireGuard加密栈。
运维人员逐项核对WireGuard Peer配置关键信息，高效缩小VPN故障范围
这里要注意不要只看wg show命令的输出就判定接口状态正常，还要用ip类系统命令确认虚拟网卡的运行状态是UP，没有被本地防火墙规则拦截虚拟网卡的转发权限，这部分信息如果不提前记录，后续排查到传输层的时候很容易回头返工，浪费不必要的时间。
对端Peer的网络可达性基础信息
接下来要记录的是配置文件里填写的Peer端点地址，也就是对端设备的公网IP或者域名、配置的监听端口，先在不启用WireGuard的前提下，用普通的UDP端口探测工具确认这个地址和端口是可达的，没有被中间运营商防火墙或者安全组规则拦截。
很多用户配置Peer的时候会把端点域名写错，或者域名解析出来的IP和实际对端设备的公网IP不匹配，这一步要把当前本地解析得到的Peer端点IP、探测得到的UDP连通状态都记录下来，樱花猫避免后续误以为是WireGuard加密层的问题，实际上底层传输网络根本没有连通。
还要同步记录本地和对端两端的公网出口IP，确认两端的网络环境属性，如果其中一端处于NAT后面，配置里又没写对应的保活参数，大概率会出现连接空闲一段时间后主动断连的情况，这部分参数的原始配置值也要同步留存，方便后续比对参数合理性。
Peer路由与预共享密钥校验信息
接下来要记录Peer配置里设置的AllowedIPs参数的完整内容，很多连通异常的问题本质是AllowedIPs配置范围不对，要么是把本端虚拟IP段也写进了对端的AllowedIPs里导致路由冲突，要么是需要访问的后端业务网段没有被加入规则，数据包被WireGuard直接静默丢弃。
如果配置中开启了预共享密钥，排查时要分别导出两端配置的预共享密钥做比对，确认两端的密钥是完全一致的，没有出现一端填了另一端没填，或者密钥复制的时候多了空格换行的情况，这类问题WireGuard不会返回明确的报错提示，只会静默丢弃不匹配的数据包，定位难度很高。
运行时Peer流量统计与日志关联信息
最后要记录wg show输出的最新Peer流量统计，包括最近一次收到对端数据包的时间、累计收发的字节数，如果只有发出去的字节数没有收到的返回流量，说明数据包要么没到达对端节点，要么对端返回的路径上存在拦截规则。
还要同步记录系统内核日志里和WireGuard接口相关的报错信息，比如有没有出现密钥校验失败、数据包来源IP不符合Peer规则的提示，樱花猫VPN这类日志信息往往能直接定位到是不是有其他非法节点尝试接入，或者Peer的公网端点地址发生了非预期的变动。
整个WireGuard Peer配置排查过程中不要随意修改原有配置，先把所有原始信息记录完成之后再逐项比对校验，避免改了配置之后丢失故障现场，反而找不到最初的异常点，所有记录的信息后续遇到同类Peer配置故障的时候也可以作为参照，大幅降低后续的排查成本。
