很多初次接触WireGuard的用户都会遇到这类诡异的故障：服务端已经正常启动、密钥配置也完全对应，但要么连接后只有小部分流量走隧道，要么本地局域网完全断连，甚至出现IP地址意外泄露的问题，这类问题九成以上都和AllowedIPs字段的错误填写有关。作为WireGuard配置里最容易被误解的参数，AllowedIPs的规则逻辑和普通VPN的路由配置有明显差异，很多用户按照惯性思维填写很容易踩坑，我们汇总了实际部署场景里最常见的几类填写错误，帮大家快速定位故障。
仅填写服务端虚拟IP导致的全局路由失效问题
这类错误是新手用户最常犯的问题，典型现象是WireGuard连接状态显示正常，但用户访问外网网站的时候，公网IP还是本地运营商的地址，完全没有走VPN隧道，只有ping服务端分配的WireGuard虚拟内网IP的时候才能通。
很多用户误以为AllowedIPs只需要填写WireGuard服务端的虚拟接口IP就行，实际上这个字段的核心作用是生成系统侧的路由匹配规则，只有目标IP地址落在AllowedIPs声明的网段范围内的流量，才会被系统转发到WireGuard虚拟接口处理。
排查这类错误的方式非常简单，打开本地的WireGuard客户端配置文件，找到AllowedIPs字段，如果后面的内容只有类似10.0.0.1/32这样的单条服务端虚拟IP记录，就可以确认是这类配置错误。如果需要让所有流量都走WireGuard隧道，火箭代理VPN正确的配置至少要包含0.0.0.0/0和::/0两个条目，分别覆盖全部IPv4和IPv6地址段。
不少新手配置WireGuard时很容易因AllowedIPs参数填写错误出现各类路由异常问题。
网段掩码配置错误引发的路由冲突
这类错误的典型现象是WireGuard连接成功之后，本地局域网的打印机、NAS、智能家居设备全部无法访问，断开WireGuard连接之后本地网络立刻恢复正常，很多用户会误以为是WireGuard本身不支持本地局域网共存。
绝大多数出现这类问题的用户，都是填写AllowedIPs的时候写错了子网掩码，比如原本只想把192.168.1.0/24段的远端内网资源走隧道，不小心写成了192.168.0.0/16，直接把几乎所有家庭常用的本地内网段都纳入了隧道路由范围，本地访问内网设备的流量被强制转发到远端VPN节点，自然无法连通本地设备。
排查这类问题的时候可以先打开操作系统的路由表，查看WireGuard接口对应的路由条目，对照自己填写的AllowedIPs网段范围，确认有没有把本地正在使用的内网网段包含进去，如果有这类冲突，就需要调整AllowedIPs的掩码长度，或者把本地内网段从隧道路由规则里单独排除。
漏写IPv6网段导致的分流异常
这类错误的隐蔽性很强，火箭代理很多用户配置完WireGuard之后测试IPv4的网站访问都正常，但是部分APP或者浏览器站点会优先使用IPv6协议连接，这部分流量会直接绕过WireGuard隧道，出现实际公网IP和VPN节点IP不匹配的泄露问题。
现在国内绝大多数运营商都已经默认给家庭宽带分配IPv6地址，很多用户配置AllowedIPs的时候只记得填写覆盖全量IPv4的0.0.0.0/0，完全没有添加对应的IPv6全量网段::/0，系统默认的IPv6流量走本地物理网卡，这部分流量自然不会被WireGuard处理。
排查这类问题的时候，可以在连接WireGuard之后打开支持多协议IP检测的查询网站，查看返回的公网IP列表，如果同时出现本地运营商的IPv6地址和VPN节点的IPv4地址，基本就可以确认是AllowedIPs漏写IPv6网段的问题，补上对应的::/0条目就能解决。
重复网段叠加引发的路由优先级混乱
不少有一定配置经验的用户会用WireGuard做自定义分流，只把特定站点的流量走隧道，其余流量直接走本地网卡，这时候很容易出现的错误就是往AllowedIPs里重复添加重叠网段，最终分流效果和预期完全不符。
WireGuard的AllowedIPs会自动按照最长匹配规则排序路由条目，如果用户同时添加了1.1.1.1/32和1.1.1.0/24这类重叠网段，很容易覆盖原本想要保留的本地路由规则，导致部分原本预期走本地的流量意外进入隧道，出现访问卡顿或者不通的问题。
处理这类分流场景的配置错误时，建议先整理好所有需要走隧道的站点对应的公网网段，去重之后再填入AllowedIPs字段，不要随意把整段大段公网IP纳入隧道路由，就能避免绝大多数不必要的路由冲突。
最后需要注意的是，每次修改完AllowedIPs字段之后，不要直接点击连接测试业务，先在本地系统的路由表界面核对WireGuard接口生成的路由条目是否和自己的预期一致，再分别测试内网访问、普通外网访问等不同场景的连通性，就能避开绝大多数AllowedIPs相关的配置故障。
