全隧道模式的核心判断依据
全隧道模式（Full Tunnel）的本质是将设备上所有IPv4流量都引导至VPN客户端网络接口进行转发。切换节点后，判断连接是否处于全隧道状态，核心依据并非看图标是否显示“已连接”，而是检查系统默认网关是否已指向该VPN接口。在大多数操作系统中，如果默认路由被修改为指向虚拟网卡（如TAP或WireGuard接口），且该接口的状态为Up，且存在指向0.0.0.0/0的下一跳条目，则全隧道生效。仅查看软件界面状态是不够的，因为部分客户端可能在节点切换瞬间出现路由残留或默认网关未正确更新的情况。
使用命令行验证默认路由
最可靠且低影响的只读检查方式是查询操作系统的路由表。在Windows系统中，可执行`route print`命令；在macOS或Linux系统中，可执行`netstat -rn`或`ip route`命令。观察输出结果中默认网关（Destination为0.0.0.0/0或default）所对应的接口名称。如果该接口是VPN客户端创建的虚拟网卡（例如Wintun、飞鲨TAP-Windows或wg0），而非物理网卡（如Ethernet或Wi-Fi），则说明流量正通过全隧道转发。若默认网关仍指向物理网卡，说明全隧道未生效或路由未正确接管。
检查流量实际走向
除了检查路由表，还可以验证实际数据包的路径。在Linux系统中，可以使用`tcpdump`监听虚拟网卡接口，观察是否有非VPN服务器的业务流量经过该接口。在Windows中，飞鲨由于命令行工具支持有限，更简单的方法是使用网络监视器或第三方抓包工具，监控虚拟网卡的流量。如果观察到访问日常网站（如百度、GitHub）的DNS请求和TCP握手数据包都出现在虚拟网卡上，而非物理网卡上，则进一步证实全隧道正在工作。这种方法能直观反映流量去向，避免仅依赖路由表的静态配置判断。
在终端中验证默认路由指向，是判断全隧道模式是否生效的关键步骤。
节点切换后的常见异常状态
在切换节点过程中，常出现“路由残留”或“网关冲突”。例如，旧节点的虚拟网卡未完全释放，或新节点的默认路由未正确添加，导致系统同时存在两个默认网关，或仍使用旧网关。此时，飞鲨加速器官网部分流量可能走旧隧道（若旧隧道未断开）或回落到物理网卡。检查时，如果发现路由表中存在多条默认路由，且度量值（Metric）不一致，需确认主默认路由指向的是当前活跃的新节点接口。此外，部分客户端在快速切换节点时，虚拟网卡可能短暂处于Disconnected状态，此时路由表中默认网关会暂时指向物理网卡，属于正常过渡现象，待隧道建立完成后会自动切换。
适用边界与注意事项
上述检查方法适用于基于路由表修改实现全隧道的客户端，如WireGuard、OpenVPN在配置了`route push`或`default route`选项时的行为。对于采用TUN/TAP驱动并配合透明代理或用户态路由（如部分Android或iOS系统下的Split Tunnel反向实现）的场景，路由表检查可能不适用，需通过客户端提供的状态接口或抓包工具判断。此外，检查路由表和抓包均为只读操作，不影响现有连接。若发现路由未正确接管，请勿手动修改路由或卸载驱动，而是应重新建立VPN连接，让客户端自动修复路由表。确保系统时间同步正常，以免因证书验证失败导致隧道建立异常。
