很多使用VPN的用户都会配置排除局域网规则，避免VPN接管内网流量后无法访问本地NAS、内网打印机、办公共享服务器等资源，但切换VPN节点后经常出现规则静默失效的问题，用户很难第一时间发现，轻则内网资源访问卡顿，VPN加速器重则原本只应该走本地局域网的设备流量意外进入VPN隧道，带来不必要的连接风险。本文围绕VPN排除局域网规则切换节点后的检查需求，从配置前提、路由校验、实机验证到故障定位给出可落地的操作方法，帮用户快速确认规则生效状态。
配置前提确认
首先要提前确认你之前设置的排除局域网规则，是在VPN客户端的全局配置层面开启，而非绑定在单个旧节点的专属配置里。不少VPN客户端的规则体系做了分层，单节点专属的规则只会在连接对应节点时生效，切换到其他节点后不会自动同步，这也是很多用户遇到规则失效的初始原因。
网络连接与设备配置场景示意
正式检查前你可以先整理当前局域网内的典型资源地址，包括内网网关IP、内网共享存储的固定地址、内部办公系统的专属域名、内网IoT设备的访问地址，把这些信息提前记录下来，后续验证环节可以直接调用，不用临时查询地址打断检查流程。
第一层：系统路由表校验
切换VPN节点完成连接后，先不要急着打开内网应用尝试访问，先打开系统自带的命令行工具，火箭代理Windows系统启动命令提示符后输入route print指令，macOS或者Linux系统在终端输入route -n指令，调取当前系统所有活跃的路由条目。
正常生效的排除局域网规则，会把所有常见的私网地址段，包括192.168.x.x、10.x.x.x、172.16.x.x到172.31.x.x这些私网网段的路由，指向你本机物理网卡对应的本地网关，而不是VPN连接后生成的虚拟网卡网关。如果查询到私网网段的下一跳地址指向了VPN虚拟网卡的分配地址，就说明排除规则没有成功加载。
校验路由表的时候不要只检查常用的192.168私网段，不少企业内网会划分多个独立网段，分别对应办公终端、服务器集群、监控系统等不同分区，漏掉任何一个网段的路由校验，都可能出现部分内网资源能访问、部分资源异常的情况。
第二层：连通性实机验证
路由表校验确认所有私网段路由都指向本地物理网卡后，先尝试ping之前记录的内网网关IP，如果能正常收到网关的响应包，没有出现丢包或者超时的情况，就说明基础网络层面的排除规则已经正常生效。
接下来尝试访问对路由路径敏感度更高的内网应用，比如打开内网共享文件夹、触发打印机的内网打印任务、访问内网部署的非公开服务，这类基于SMB、专有内网协议的应用，对流量的传输路径校验比ICMP的ping请求严格很多，不少路由表显示正常但流量实际走VPN隧道的异常，都会在这一步直接暴露出来。
如果当前局域网部署了内部专属的DNS服务器，还可以尝试解析只有内网环境才能识别的专属域名，要是最终返回的解析结果是内网IP，而非VPN远端DNS服务器返回的公网地址，就说明DNS层面的排除规则也处于正常生效状态。
常见失效场景定位
如果检查过程中发现规则没有生效，首先排查是不是当前连接的新节点默认启用了全隧道模式，全隧道模式的优先级高于全局排除规则，会强制把所有流量都导入VPN隧道，只要把节点的连接模式调整为分离隧道模式，排除规则就能正常加载。
还有一类常见的临时异常是VPN客户端切换节点的过程中，虚拟网卡抢占系统路由的优先级过高，覆盖了之前配置的排除规则，VPN加速器这种情况不需要修改系统配置，只需要手动断开当前VPN节点连接，重新触发一次节点连接流程，大部分临时的规则加载异常都能自动恢复。
整个检查过程中不要随意手动修改系统的默认路由条目，错误的手动配置反而可能导致本地网络和VPN网络同时出现连接异常，如果多次重试后规则依然无法正常生效，可以查看VPN客户端的官方说明，确认当前版本的客户端是否存在切换节点后排除规则不同步的已知问题。
