不少运维人员在处理WireGuard连接异常故障时，第一反应多是重启服务或者重新生成密钥对，反而忽略了故障发生第一时间的现场信息留存，导致后续排查公钥相关问题时反复试错，消耗数小时都找不到根源。这份排查时应记录的信息清单，覆盖从磁盘配置到运行时状态、从生成环节到网络侧特征的全维度内容，能帮你快速锁定WireGuard公钥相关故障的根因，避免无意义的重复操作。
两端WireGuard接口的公钥原始配置快照
排查的第一时间不要修改任何配置，先分别记录服务端和客户端磁盘上存储的WireGuard配置文件里的公钥字段内容，比如常见部署中服务端/etc/wireguard/wg0.conf内，[Interface]段的自身公钥、所有[Peer]段内存储的对端客户端公钥，以及客户端本地wg0.conf里[Interface]段的自身公钥、[Peer]段内存储的服务端公钥。很多家用场景下用户在树莓派上搭建WireGuard网关，用手机扫码导入配置时经常出现公钥末尾多带空格、换行符的问题，要是排查时直接覆盖原有配置，根本找不到最初的异常字符。
记录完成后可以逐字符对比两端的对向公钥是否完全匹配，WireGuard公钥是固定长度的Base64编码串，大小写严格敏感，哪怕只有一个字符的差异，都会直接导致公钥校验失败，常见误区是不少用户误以为公钥只是近似匹配，手动输入公钥时把大小写字母写错，没有留存原始配置快照的话，很难发现这类肉眼难以分辨的字符错误。
运行时状态的公钥关联映射记录
光留存磁盘配置的公钥信息还不够，还需要立刻执行wg show命令，记录输出结果里所有Peer条目对应的公钥、最新握手时间、收发字节数，很多场景下运维人员刚修改完磁盘配置里的Peer公钥，还没执行wg syncconf命令把新配置刷入内核运行态，此时内核里加载的还是旧的公钥列表，新客户端发起连接时服务端会直接丢弃握手包，要是只核对磁盘配置的公钥完全正常，根本想不到故障出在配置没有同步到运行态。
还要同步记录内核网络栈中，每个公钥条目绑定的虚拟IP段信息，比如服务端配置里给某客户端公钥分配的虚拟IP是10.0.0.12，但是运行态里这个公钥绑定的虚拟IP是之前残留的旧地址10.0.0.34，就会出现公钥校验通过但路由转发异常的问题，这类残留条目大多是之前删除旧Peer时没有完全清理内核态配置导致的，没有运行时映射记录的话很容易把故障误判为公钥不匹配。
公钥生成环节的原始操作日志
接下来要记录两端生成当前使用的密钥对的完整操作流程，确认是不是通过wg genkey、wg pubkey的标准流程生成，有没有出现生成过程中断、密钥文件复制混淆的情况，新手部署WireGuard时最容易犯的错误，就是把自身的私钥填到对端配置的公钥字段里，二者的字符串长度完全一致，肉眼很难第一时间分辨，没有生成环节的操作记录的话，很容易反复核对公钥都找不到问题。
还要记录公钥、私钥存储文件的系统权限和修改时间，比如多用户共用的私有服务器场景下，其他运维人员可能误操作覆盖了公钥文件的内容，你排查时如果只看当前配置里的公钥，根本想不到原始生成的公钥已经被篡改，这类场景下对比修改时间和最初部署时的记录，就能快速定位异常。
公钥校验阶段的抓包特征记录
在WireGuard服务端的公网网关上，针对WireGuard使用的UDP端口做抓包，记录故障客户端发起的握手包的到达情况，如果抓包结果里完全看不到来自客户端IP的WireGuard握手包，那公钥校验失败的问题根源根本不在WireGuard配置本身，而是中间链路的防火墙、云服务商安全组拦截了UDP数据包，不需要再花费时间核对公钥内容。
如果抓包能看到服务端已经返回了WireGuard类型为2的握手响应包，就说明公钥校验流程已经执行通过，后续出现的连接不通、无法访问内网资源的故障，和公钥配置没有任何关系，可以直接把排查方向转向路由规则、后端服务ACL等其他环节，不用再反复调整公钥配置做无用功。
第三方系统的公钥绑定规则信息
不少企业级的WireGuard部署场景中，会搭配额外的接入控制系统，把公钥和用户身份、访问权限做绑定，排查时需要记录故障公钥对应的ACL规则、用户状态信息，确认这个公钥有没有被运维人员误拉黑、有没有超出有效期被系统自动禁用，这类场景下两端本地的公钥配置完全正确，但是第三方系统会直接拒绝公钥的接入请求，表现出来的现象和公钥不匹配几乎完全一致，没有绑定规则记录的话很容易走偏排查方向。
把上述所有维度的信息整理留存后，你就可以按照从配置到运行态、从本地到网络侧的顺序逐层排查，绝大多数WireGuard公钥相关的故障都能快速定位，不会出现反复重新生成密钥对、修改配置最后才发现只是复制时多了个不可见字符的低级失误。
