误区一：将“全模式”等同于流量绝对隔离
许多用户误以为启用网络加速器的“全模式”或“全局模式”后，所有出网流量必然强制经过加速器隧道，且本地设备不再产生任何直连请求。事实上，是否进入VPN或隧道由操作系统的路由表、流量选择器（如Windows下的TAP驱动规则或macOS/ Linux下的iptables/nftables链）以及客户端自身策略共同决定。分隧道架构天然允许部分流量直连本地网络或默认网关。因此，“全模式”并非一个保证所有敏感流量入隧道的物理开关，而是一个优先级较高的策略集。若需确认实际流向，应观察本地路由表指向及加速器控制台的状态指示灯，VPN下载而非仅依赖模式名称判断流量去向。
误区二：混淆中继节点与直接出口IP
在排查目的站点访问异常时，常有人断定加速器本身不会改变目的站点看到的源IP，从而排除代理侧配置问题。这种认知忽略了加速器底层实现的可能性。商业加速服务可能采用中继、隧道封装或NAT出口等不同技术架构。若服务采用NAT出口或IP中继，目的站点看到的源IP将是加速器出口服务器的IP，而非用户本地公网IP。因此，VPN下载不能断言加速技术在协议层面“绝不可能”改变目的站点所见的出口IP。在故障排查时，需查阅所用加速器官方文档中关于出口IP策略的说明，确认其是否支持静态出口IP或动态NAT映射，避免基于“隧道即透明”的错误假设定位错误。
误区三：仅凭单次延迟测试判断分流有效性
用户常通过Ping特定IP或访问测试页面来判断分流规则是否生效，若延迟低则认为规则匹配正确。然而，单次测试的通过或失败通常不能单独证明全部原因。分流规则匹配取决于域名解析结果、IP地址段范围及协议类型。例如，即使规则指定加速某域名，若该域名解析出的IP落在直连白名单内，或客户端策略中存在更高优先级的直连规则，流量仍会绕过加速器。此外，网络波动、DNS缓存或防火墙拦截都可能导致测试结果偏差。建议在修改规则前后，使用网络抓包工具或加速器提供的连接日志，对比特定域名的实际路由路径，以验证流量选择器是否按预期工作，好用的梯子软件而非仅依赖延迟数值作为唯一判据。
在排查网络异常时，仅依赖模式名称可能误导判断，深入观察路由表与实际流向才是准确分流的关键。
