很多用户在自行部署WireGuard实现远程办公接入、跨站点组网的过程中，遇到WireGuard Endpoint连接异常、握手超时、连通后丢包等故障时，经常直接反复修改配置参数，反而把原本正常的配置覆盖，拉长故障定位的时间。实际上WireGuard Endpoint排查时应记录的信息是一套成体系的验证依据，网络加速器不需要复杂的专业测试工具，只要按运行状态、链路连通性、路由规则的顺序留存对应数据，大部分常见故障都能在十几分钟内定位根因。
本地端WireGuard基础运行状态记录
首先要记录的不是配置文件的静态内容，而是本地WireGuard接口的实时运行状态，直接把wg show命令的完整输出复制留存，内容需要包含本地接口的公钥、监听端口、已加载的所有对等点配置、对应对等点标注的Endpoint地址，以及最新握手时间、双向传输的字节数。很多用户排查时只看wg-quick启动的终端输出，漏掉运行时的动态缓存数据，就会出现配置文件里明明填了新的对端公网IP，实际运行的进程还在调用之前缓存的旧Endpoint地址，导致配置修改后完全不生效的问题。
还要同步记录排查当下本地设备的实际公网出口IP，不要凭网络拓扑记忆填写，既可以通过公网IP查询网页获取，也可以用curl ifconfig.me这类命令行工具直接拉取返回结果。尤其是在多层NAT的家庭宽带、网络加速器企业多出口网关场景下，本地设备的实际出口IP和预设的公网地址可能完全不同，这个信息记录错误的话，后续所有端口映射、NAT穿透的排查方向都会出现偏差。
对端Endpoint侧的网络连通性记录
这部分是WireGuard Endpoint排查时应记录的信息里最核心的链路验证内容，首先要留存从本地到对端WireGuard监听端口的UDP连通性测试结果，不要用常规的tcping工具测试，要选用支持UDP探测的nc、nmap工具发起测试，把测试的全程输出完整保存。比如在本地执行nc -u 对端IP 监听端口后发送测试字符，记录是否收到ICMP端口不可达的返回报文，这个结果可以直接区分故障是中间运营商链路封禁了UDP协议，还是对端的WireGuard服务根本没有正常启动。
技术人员按规范留存WireGuard故障排查的关键运行数据，高效定位连接异常根因
还要记录对端侧的系统防火墙放行规则和内核转发配置，很多用户在云服务器上部署WireGuard作为远程接入Endpoint时，只单独放行WireGuard的UDP监听端口，如何挂梯子却漏配了IPv4/IPv6的转发许可规则，就会出现两端握手完全成功，却无法访问对端内网资源的异常情况。留存iptables或者firewalld的完整规则输出，不需要手动逐条核对，后续排查时可以直接排除规则漏配的可能性。
如果对端Endpoint部署在没有固定公网IP的家庭宽带、边缘办公路由场景下，还要记录排查当下DDNS域名的实时解析结果，把解析得到的IP和WireGuard配置文件里填写的Endpoint地址做对比。这类场景下的常见故障是DDNS服务更新延迟，域名解析出来的IP已经是几天前的旧公网地址，用户反复调整WireGuard配置也不可能建立正常握手。
跨节点转发的路径链路信息记录
不少站点到站点的WireGuard组网场景里，两端设备都处于多层NAT后方，需要借助公网中继节点转发加密报文，这时候要留存中继节点上针对WireGuard外层UDP报文的抓包结果。不要直接在两端的WireGuard终端上抓包，这类抓包结果会同时包含加密后的内层流量，很难区分外层的WireGuard封装报文有没有正常抵达中继节点。
还要记录两端设备的路由策略规则优先级，很多用户的本地设备上同时安装了其他商用VPN客户端，不同服务生成的路由规则优先级冲突，导致访问对端Endpoint的WireGuard UDP流量反而走了其他VPN隧道，形成路由环路。留存ip rule或者系统路由表的完整输出，就能快速定位这类隐蔽的路由冲突问题，不需要逐跳traceroute排查。
排查过程中的操作回溯记录
每次修改WireGuard配置之前，都要把当前运行的配置文件单独备份留存，不要直接覆盖原有配置。很多用户排查故障时反复修改对等点公钥、调整监听端口、变更预共享密钥，改到最后自己都忘了最初的可用配置参数，把原本只是连通性的小故障，演变成全量配置混乱的更严重问题。
还要把每次测试的时间点和对应的现象做对应记录，比如第一次测试时没有收到任何对端的握手响应，修改监听端口之后收到了对端的握手返回，但还是无法传输业务数据，这种时序化的记录能帮你快速确认哪一步操作解决了部分问题，如何挂梯子剩下的待排查故障出在哪个环节，避免重复做无效的测试操作。
