WireGuard的AllowedIPs是决定VPN路由转发逻辑的核心配置项，科学上网绝大多数连通性故障、路由冲突、流量分流异常问题都和这个参数的配置偏差直接相关，排查过程中如果漏记关键信息很容易反复走弯路，梳理排查时必须留存的核心记录项，能快速定位绝大多数AllowedIPs相关路由异常，避免无意义的重复调试操作。
故障发生时的原始路由表快照
排查的第一步要第一时间记录故障节点的系统全量路由表，不能只提取WireGuard生成的虚拟接口路由，要把物理网卡的默认路由、手动配置的静态路由、其他VPN软件生成的路由条目全部完整留存。
排查WireGuard路由连通故障时，第一时间留存全量路由快照与两端原始配置可快速定位路由冲突问题
记录时要同时标记每个路由条目的下一跳出接口，很多时候AllowedIPs配置的网段和本地局域网的现有网段重叠，系统会优先走物理网卡的直连路由，狗狗导致VPN隧道内的目标地址完全无法访问，没有原始快照的话很容易忽略这种路由优先级冲突的问题。
两端WireGuard配置文件的AllowedIPs原始值
很多用户排查时会直接临时修改配置测试，忘记留存故障发生时两端的原始AllowedIPs配置，后续回溯的时候根本不知道最初的配置偏差在哪里，反复调整参数也找不到问题根源。
记录的时候要区分客户端和服务端的配置差异，不能只核对一端的参数，比如服务端AllowedIPs只填了虚拟隧道接口的单地址，客户端就无法把指定内网网段的流量导入隧道，反过来如果客户端AllowedIPs填了全量公网地址，服务端没有配置对应的IP转发规则，就会出现流量出隧道后无法回包的问题。
虚拟接口的当前流量统计记录
要调用WireGuard自带的状态查询命令，记录故障发生时虚拟接口的收发字节数、错误包数量、最新握手时间，这些数据能直接反映AllowedIPs配置的实际生效状态，不需要额外抓包就能缩小排查范围。
如果发往目标网段的流量没有出现在WireGuard接口的发送统计里，说明系统根本没把对应流量导入隧道，问题出在本地路由生成环节，大概率是AllowedIPs配置的网段写法不符合系统路由解析规则；如果流量已经从接口发出但没有任何回包统计，说明配置已经生效，问题出在隧道对端的AllowedIPs没有包含客户端虚拟地址，导致对端不知道回包要走隧道返回。
目标地址的traceroute逐跳路径记录
排查AllowedIPs相关的分流异常时，必须留存从故障节点访问目标地址的完整traceroute路径，不能只靠ping的连通性判断问题，很多时候ping能通但业务流量走的是本地物理网关，完全没有进入VPN隧道。
如果路径第一跳就走了本地物理网关，说明AllowedIPs里根本没有包含这个目标地址所属的网段，系统直接走默认路由把流量发去了公网；如果路径第一跳是WireGuard的虚拟隧道网关，后续跳数在隧道对端的内网网关处中断，说明AllowedIPs配置的网段范围不全，对端内网的部分子网没有被纳入转发规则。
本地防火墙的规则快照
很多时候AllowedIPs的配置本身没有问题，但本地系统的防火墙规则拦截了虚拟接口的转发流量，排查时如果没有提前记录防火墙的原始规则，很容易误以为是AllowedIPs配置写错了反复修改参数，浪费大量调试时间。
记录时要重点标记针对WireGuard虚拟接口的入站、出站策略，以及针对AllowedIPs指定网段的NAT规则，不少用户会在配置全量流量走隧道的AllowedIPs之后，忘记添加虚拟接口的IP转发放行规则，导致所有导入隧道的流量都被本地防火墙丢弃。
所有记录的信息最好统一留存为纯文本格式，不要只靠临时记忆判断问题，后续遇到同类AllowedIPs故障时，还可以对照之前的记录快速匹配相似场景，大幅降低故障定位的时间成本，也能避免排查过程中修改的临时配置没有回滚，引发后续的网络连通性异常。
