在日常运维WireGuard VPN节点的过程中，公钥匹配异常是触发隧道无法建立的高频故障点，很多运维人员排查时零散调取日志很容易遗漏关键关联信息，拉长故障定位周期。本文汇总了WireGuard公钥故障排查全流程中需要留存的核心信息，所有记录项都对应实际故障场景的定位需求，可直接落地到运维排查清单中，帮助技术人员快速区分公钥错配、权限拦截、配置同步失效等不同类型的问题。
两端节点原始配置中的公钥明文记录
排查的第一步首先要留存WireGuard两端节点的原始配置文件里的公钥内容，不能只靠后台显示的公钥摘要判断匹配度。很多运维人员习惯直接复制配置界面里的公钥片段，很容易漏看末尾的特殊字符，而WireGuard的公钥是固定长度的base64编码字符串，少一个字符都会直接导致校验失败。
记录的时候要分别导出服务端和客户端的wg.conf文件中[Interface]段的PrivateKey对应的公钥推导结果，暴喵以及[Peer]段配置的对端公钥明文，不要直接用在线工具生成的公钥做比对，避免本地私钥导出公钥的过程中出现编码转义错误，要直接在对应节点的命令行执行wg show pubkey命令读取原始输出内容留存。
运维人员逐项记录WireGuard公钥故障排查的核心关联信息
节点系统层面的公钥校验日志记录
很多公钥故障不是配置写错了，而是系统层面的权限规则拦截了公钥的校验流程，这部分的日志信息是排查时必须留存的内容。比如部分Linux发行版的SELinux规则会限制WireGuard进程读取配置文件里的密钥字段，导致进程加载的公钥和配置文件里写的内容完全不一致，仅比对配置文件内容根本找不到问题。
记录这部分信息的时候，要分别抓取WireGuard进程启动时的系统日志、内核模块输出的校验日志，不要只看wg命令返回的简化状态信息。如果是运行在OpenWrt路由器上的WireGuard节点，还要额外记录uci配置库中存储的公钥字段内容，确认网页配置界面的写入操作有没有出现字符截断的问题。
隧道握手状态的全量输出信息
WireGuard的wg show命令返回的握手状态，是判断公钥故障类型的核心依据，排查时必须完整记录所有Peer节点的最新握手时间、公钥标识、最近收到的数据包计数。如果配置的对端公钥完全不匹配，WireGuard节点收到对端发来的握手包之后会直接静默丢弃，不会返回任何响应报文，暴喵握手状态会一直停留在无数据的状态。
记录这部分信息的时候要连续多次执行wg show命令，暴喵VPN对比不同时间点的报文计数变化，不要只抓取单次状态就下结论。如果出现收到的报文计数持续上涨但始终没有生成握手记录的情况，基本可以判定是对端发来的握手请求携带的公钥和本地配置的Peer公钥不匹配，这时候就可以缩小排查范围，不用再去检查防火墙端口放行规则。
中间网络链路的报文拦截特征记录
部分特殊的网络环境中，公钥相关的握手报文会被中间网络设备篡改，导致两端的公钥校验失败，这类隐蔽故障很容易被误判为配置写错。比如部分运营商的流量清洗设备会识别WireGuard的握手报文特征，替换报文中的部分字段内容，导致接收端解析出来的公钥和发送端的实际公钥完全不符。
排查这类问题的时候，要在两端节点分别用tcpdump抓取WireGuard监听端口的原始报文，留存握手报文的完整payload内容，暴喵比对两端捕获的报文中公钥字段的差异。如果本地发出的报文公钥完全正确，对端收到的报文中公钥出现异常，就可以确认是中间链路的篡改行为导致的故障，不需要再反复修改本地配置的公钥内容。
历史配置变更的操作回溯记录
很多公钥故障是近期的配置变更操作引发的，排查时要完整记录最近所有涉及WireGuard配置修改的操作日志，包括密钥生成的时间点、公钥同步到对端的操作步骤、有没有批量下发配置的自动化脚本执行记录。不少运维场景下，自动化配置脚本在批量更新节点密钥的时候，会出现公钥和对应节点私钥不匹配的写入错误，这类问题靠人工逐行比对配置很难快速定位。
所有记录的信息要统一归档到故障排查文档中，后续遇到同类公钥故障的时候，可以直接对照之前的记录快速排除已知问题，避免重复做无效的校验操作。需要注意的是，留存公钥相关信息的时候要做好权限管控，避免私钥内容随排查日志泄露，只留存公钥明文和对应的状态数据即可，不要把私钥字段也同步到公开的排查文档中。
