01先看流量怎样进入代理程序

客户端运行着，不代表所有应用已经使用它。

应用流量必须通过某种入口进入代理内核，内核才能根据规则转发。常见入口包括应用明确使用的代理端口、操作系统的代理设置，以及通过路由或系统接口接管的数据包。它们解决的是“怎样接收流量”，与后续选择哪条节点属于不同问题。

因此，一个客户端里可能同时存在“启动内核”“设置系统代理”“启用TUN”和“切换规则模式”等操作。它们名称相近，却作用在不同层面。把这些概念分开以后，就能理解为什么节点检测成功，而某个应用仍然直连；也能理解为什么开启更广泛的接管后，局域网服务反而需要额外处理。

02系统代理依赖应用是否采用设置

系统代理通常向应用提供代理服务器地址和端口等信息。

愿意遵循这些设置的程序，会把相应请求交给代理；使用自己网络实现或独立配置的程序，则可能不按系统设置行动。不同操作系统、应用框架与协议的支持范围各不相同，所以不能简单把系统代理理解成所有网络包都会经过的强制关卡。

浏览器能打开网页而某个命令行工具失败，就是常见例子之一。它可能没有读取同一套代理设置，也可能需要自己的配置。系统代理本身也不是对任意UDP流量的通用接管方式。此时需要先确认应用怎样联网，而不是立刻换机场或把节点重新导入多次，避免用服务选择去解决入口问题。

03TUN把部分网络流量交给虚拟接口

TUN是一类虚拟网络接口机制。

配合系统路由与代理内核，它可以让被纳入范围的数据包进入代理处理，而不要求每个应用都主动配置代理。实际覆盖范围仍取决于平台、权限、路由、排除项以及内核支持。它往往比单纯系统代理覆盖更广，但“更广”不是“无条件接管一切”。

TUN也不是加密协议。接收到数据以后，流量可能按规则直连，也可能通过不同出站方式发送；是否加密与如何保护通信，还要看实际出站协议。把TUN图标亮起等同于所有应用都隐藏真实出口，会忽略分流、IPv6、局域网例外及其他网络接口带来的差异。检查实际路径比看一个开关更可靠。

04透明代理强调应用不必主动配合

透明代理通常指应用无需显式知道代理存在，流量仍被网络或操作系统机制引导处理。

TUN可以参与实现这种效果，路由器上的转发规则也可能实现相关能力。这里的“透明”描述应用视角，并不是指没有配置、不需要权限或不存在兼容问题，更不意味着服务商不会看到任何网络信息。

在家庭路由器上运行与在单台电脑上运行，影响范围也不同。前者可能覆盖多台设备，错误规则会影响家人的打印、投屏或工作连接；后者通常局限于当前设备。理解部署位置有助于控制变更范围。对只需要浏览器访问的用户，复杂接管未必带来额外收益，反而可能增加维护成本。

05局域网、DNS与其他网络工具需要协作

局域网打印机、文件共享和投屏设备依赖本地可达性，有时还依赖广播或特殊发现机制。

如果把所有目标都不加区分地送往远端出口，应用可能再也找不到附近设备。合理的本地网络例外与目标识别因此很重要，但例外应有明确范围，不能为了修复一个应用就大面积放弃预期的流量管理。

另一类冲突来自同时运行的企业VPN、安全软件或其他虚拟网卡。它们可能都想调整路由和DNS，谁先建立、谁拥有优先级会影响结果。设备休眠、网络切换或软件异常退出，也可能留下与当前状态不一致的设置。问题出现时，了解有哪些组件参与，比盲目叠加更多接管工具更有意义。

06按需求选择范围最清楚的模式

选择入口模式时，可以从目标应用出发。

若需要的应用都能稳定遵循系统代理，较简单的方案通常更容易理解；若确实需要处理不支持显式代理的应用，再评估TUN的系统支持、权限与兼容性。这里不是给两种模式排高低，而是让工具范围与使用任务相匹配，减少不必要的复杂度。

验证也应围绕实际任务进行：网页、会议、文件下载与局域网访问分别是否正常，预期直连和代理的流量是否走向正确出口。客户端中的“全局”通常描述进入内核后的路由选择，而TUN描述接入方式，这两个维度可以组合。理解它们后，再参照统一教程操作，就不会把每一次连接问题都归结为少打开了一个开关。