很多WireGuard用户调整分流规则的时候，直接上手修改AllowedIPs参数，改完之后要么出现本地局域网设备访问失败、全量流量断流，要么预期的分流规则完全不生效，排查半天找不到问题根源。WireGuard AllowedIPs修改前的检查，本质上是提前对齐本地路由、对等端规则、系统网络策略的前置校验，避免不必要的网络故障，也能大幅降低后续配置调试的时间成本。
先确认当前路由表的基线状态
修改AllowedIPs之前，首先要在断开WireGuard连接的状态下，导出当前系统的完整路由表作为基线记录。Linux设备可以执行ip route show命令，Windows系统用route print指令，macOS设备调用netstat -rn，把当前的默认网关、所有直连内网段的路由条目全部留存下来。
很多新手忽略这一步，改完AllowedIPs之后不小心把整个本地内网段都推给了WireGuard虚拟接口，之后连家里的NAS、办公室的网络打印机都访问不了，却完全记不住原本的内网路由规则是什么，只能手动重置所有网络配置才能恢复。留存基线路由之后，哪怕后续出现路由冲突，也可以直接对照快速恢复原有规则，不需要盲目排查。
核对WireGuard对等端的预设路由规则
WireGuard的AllowedIPs不是只作用于本地的路由生成规则，它是双向生效的校验规则：本地配置的AllowedIPs决定系统把哪些网段的流量发往WireGuard接口，而服务端对应客户端Peer条目下的AllowedIPs，决定服务端会把哪些源IP的数据包转发出去。
不少用户直接在本地客户端修改AllowedIPs，完全没有提前查看服务端的配置，比如服务端的Peer规则里只给客户端放行192.168.9.0/24的网段，用户本地擅自把AllowedIPs改成包含大量未授权公网段的规则，结果所有不符合服务端校验的数据包都会被直接丢弃，改完之后直接出现部分流量完全断流的问题。修改前先登录服务端打开wg配置文件，确认两端的AllowedIPs规则可以对应匹配，是避免双向校验冲突的核心步骤。
排查本地已有的路由规则冲突
多数用户的设备上不会只运行WireGuard一款网络工具，不少人同时安装了公司IPsec VPN客户端、本地透明代理工具，这些软件都会在系统路由表里添加大量自定义路由条目。修改WireGuard的AllowedIPs之前，要先确认你打算新增的目标网段，没有被其他路由条目指向别的虚拟网卡。
比如你之前安装的公司IPsec VPN，已经把10.0.0.0/8的大段路由指向了公司VPN的虚拟网卡，你现在想给WireGuard的AllowedIPs新增10.0.5.0/24的细分网段，按照系统路由最长匹配规则，原本的大段路由优先级更高，你新增的WireGuard规则根本不会被系统调用，你预期走WireGuard通道的流量会全部走公司VPN的链路，完全达不到预设的分流效果，这类冲突如果没有提前排查，后续很难定位故障点。
验证目标网段的可达性基线
你打算加到AllowedIPs里的所有目标网段，先在断开WireGuard连接的状态下，直接从本地执行traceroute或者mtr测试，记录下流量原本的走线路径，确认这个网段在原生网络环境下是可以正常连通的，避免把原本就不通的网段连通性问题，错当成WireGuard配置故障。
等你修改完AllowedIPs、重启WireGuard连接之后，再对同一个目标网段执行完全相同的路由跟踪测试，如果路径的核心跳点变成了WireGuard服务端的对接地址，就说明新的AllowedIPs规则已经正常生效，不需要再去逐行核对系统路由表的所有条目，就能快速确认配置是否符合预期。
确认本地路由策略的优先级规则
Linux平台的WireGuard默认会创建独立的自定义路由表，不少发行版默认开启了严格的rp_filter反向路径过滤规则，如果你新增的AllowedIPs网段路由不在主路由表中，系统的反向路径校验会直接把返回的数据包丢弃，改之前要先检查对应WireGuard接口的rp_filter参数配置，避免新增网段的返回包被系统拦截。
Windows和macOS用户也要提前确认虚拟网卡的跃点优先级，WireGuard虚拟网卡的默认路由优先级通常低于物理网卡，如果新增的AllowedIPs网段和物理网卡的直连网段出现部分重合，系统会优先选用物理网卡的路由，导致你新增的分流规则完全不生效，提前调整WireGuard网卡的跃点数，就能避免这类优先级冲突问题。
WireGuard AllowedIPs修改前的检查不需要复杂的操作，所有步骤都是基于系统原生的网络工具就能完成，做完这些校验之后再调整参数，基本可以规避绝大多数改完配置之后出现的断网、分流失效、内网无法访问的常见故障，也能大幅降低后续调试的时间成本。
