TUN 适合接管不读取系统代理的应用，但开启 TUN 不等于所有连接都走代理。本文以 Windows 桌面版 v2rayN 为操作主线，说明虚拟网卡、管理员权限、DNS 与路由规则之间的关系，并给出开启前检查、连接验证和故障回退步骤。其他桌面系统的授权方式不同，不应照搬 Windows 的提权操作。
一、TUN 模式与系统代理的接管范围
结论是：浏览器能通过系统代理联网，不能证明其他应用也会使用代理。系统代理主要向应用提供代理地址，是否遵循这项设置取决于应用实现。TUN 则创建虚拟三层网络接口，通过操作系统路由把符合条件的 IP 数据包送入处理程序，再由规则决定直连、代理或拦截。
| 比较项 | 系统代理 | TUN 模式 |
|---|---|---|
| 接管入口 | 应用读取代理设置，连接本地代理端口 | 系统路由把数据包送到虚拟网卡 |
| 应用配合 | 通常需要应用支持并遵循代理设置 | 通常不需要应用单独配置代理 |
| UDP 流量 | 不能仅靠系统 HTTP 代理完整覆盖 | 可接管，但仍依赖内核、协议及服务端支持 |
| 权限需求 | 通常不需要创建网卡的权限 | 通常需要提升权限或已配置的服务机制 |
| 最终出口 | 由应用设置与客户端规则共同决定 | 由接管范围与客户端规则共同决定 |
“全局接管”描述的是入口覆盖面，“全局代理”描述的是出口策略，两者不是同一个开关。即使 TUN 已经运行，局域网地址、本地域名或者规则指定的目标仍可能直连。反过来，选择全局代理路由，也无法保证那些根本没有进入客户端的连接被处理。
TUN 不会自动提升节点带宽，也不会把服务端不支持的 UDP 连接变成可用连接。只有浏览器需要代理时，系统代理通常更容易配置和回退；确实存在应用绕过系统代理时，再考虑 TUN。
二、虚拟网卡怎样把数据交给代理内核
TUN 接收的是 IP 数据包，不是浏览器里的完整网址。客户端需要结合目标地址、可用的域名信息以及 DNS 处理结果匹配规则。域名信息能否保留，取决于 DNS 接管、嗅探和应用自身的解析方式，不能假定每条连接都能还原出域名。
v2rayN 是配置与管理界面，实际连接处理由配套内核完成。TUN 处理链与节点使用的代理内核可能不是同一个进程，具体实现随客户端版本变化。遇到故障时，应同时检查 TUN 相关启动日志和代理出站日志，不能只看界面上的开关状态。
- 网卡负责入口：出现虚拟网卡，只能说明接口可能已创建，不能证明路由和 DNS 都已生效。
- 路由负责分流：规则决定某个目的地址走直连还是代理，规则顺序同样会影响结果。
- 出站负责连接：VLESS、VMess 等节点参数仍需有效，TUN 不会修复过期订阅或错误凭据。
- 回环规避负责稳定：客户端自身到服务器的连接必须避免再次被自身接管，应优先使用客户端生成的配置，而不是随意手改系统默认路由。
三、开启前检查权限、端口与已有网络软件
先让系统代理模式正常工作，再切换到 TUN。这一步把“节点不可用”和“虚拟网卡接管失败”分开。导入订阅后选中一条可用服务器，完成一次实际网页访问；只看到延迟数字，不足以证明 DNS、TLS 连接和页面资源加载都正常。
在「设置」→「参数设置」核对本地监听地址和端口。本文用 127.0.0.1:10808 举例，不要求把现有配置改成这个值。TUN 不等于让每个应用都去连接 10808；该端口主要用于区分已有本地代理入口与虚拟网卡入口。
- 保存当前设置：记录当前服务器、路由模式、本地端口和 DNS 选项。备份配置应只保存在受控位置，分享截图前遮盖订阅地址与认证信息。
- 确认授权条件：Windows 创建接口和修改路由通常需要管理员权限。受组织管理的设备应先取得许可，不要绕过终端安全策略。
- 暂停重复接管：测试时先退出其他虚拟网卡代理或 VPN，避免两套程序同时修改默认路由。不要直接卸载公司网络组件。
- 检查安装完整性：使用与系统及处理器架构匹配的安装包，保留配套内核文件。日志若提示文件缺失，应先修复安装，而不是反复切换开关。
四、Windows 中开启 v2rayN TUN 的操作顺序
不同版本的控件位置可能不同，常见入口是主窗口底部的「启用 TUN」。如果界面提供服务模式，权限也可能由预先安装的服务承担；没有配置该机制时，优先使用管理员方式启动进行验证。不要把反复出现的授权提示当成已经授权成功。
- 退出并提权启动：先从托盘菜单退出 v2rayN，再对程序或快捷方式选择「以管理员身份运行」，确认系统授权提示。仅关闭主窗口可能只是最小化到托盘。
- 选择已验证的服务器：保留刚才在系统代理模式下可正常访问的节点，不要同时更换协议、订阅和路由规则。
- 固定路由策略：在「设置」→「路由设置」检查当前规则。测试期间保持已有可用策略，确认局域网是否需要直连。
- 隔离系统代理入口：将系统代理切换为「清除系统代理」，再启用「启用 TUN」。这样浏览器访问成功时，结果不容易与原来的系统代理入口混淆。
- 检查启动日志：确认没有权限不足、网卡创建失败、地址冲突或端口占用报错。出现错误时先处理第一条明确失败信息，不要连续开关多次。
- 验证并保留回退路径：访问同一个测试站点，再测试原本不读取系统代理的应用。失败时先关闭 TUN，恢复之前的系统代理设置，确认基础连接仍然可用。
不要通过长期关闭系统防火墙来排查 TUN。若安全软件阻止了配套进程，应核实程序路径、来源和组织策略，再按最小范围允许必要的网络访问。
五、DNS 与路由设置：接管成功后仍需核对
DNS 查询和业务连接是两条相关但不同的链路。查询成功不代表业务连接一定走代理；业务连接进入 TUN，也不代表域名一定由远端解析。按实际分流目标配置，比统一替换为某个解析地址更可靠。
应用连接入口
- 系统代理
- 验证 TUN 时先清除
- TUN 状态
- 启用并检查启动日志
- 本地端口
- 10808 仅为本文示例
- 路由策略
- 保留已验证的分流规则
每次只改一项，避免把节点故障误判为网卡故障。
域名解析链路
- 常规查询
- 通常涉及 UDP 或 TCP 53
- 加密解析
- 需另查其实际连接路径
- 内网域名
- 保留可访问的内网解析器
- IPv6
- 核对地址、路由与接管范围
DNS 接管选项应与当前内核配置一致，不要把其他内核字段直接粘贴进来。
浏览器开启加密 DNS 后，解析连接可能作为普通加密流量出现，不能只检查 53 端口来判断解析去向。公司内部域名如果依赖内网 DNS，全部交给公共解析器反而会失败。应保留内网域名的解析路径，同时确认解析器本身能够通过预期出口访问。
- 局域网访问：打印机、共享目录和网关管理页通常需要直连。优先使用现有私有地址规则，不要为了测试随意删除整组规则。
- IPv6 一致性：如果只接管了 IPv4，而应用优先使用 IPv6，两类连接可能走不同出口。先查看日志和系统路由，再决定调整哪一侧。
- 规则与内核：V2Ray、Xray 与其他配套内核的 DNS、路由字段不能默认互换。修改前先核对当前实际运行的内核与配置格式。
六、怎样确认 TUN 生效，而不是只看开关
有效验证需要同时检查接口、规则命中和实际应用。单次出口地址查询只反映那一次请求的结果，不能证明所有进程、所有目标都使用相同出口。若规则让该测试站点直连，显示本地网络出口也可能是正确行为。
- 查看接口：在 Windows 网络适配器列表中检查新增的虚拟接口，结合日志确认它属于本次启动。接口名称随版本变化，不要只按某个固定名称判断。
- 查看路由：在命令提示符执行下方只读命令，检查 IPv4 与 IPv6 路由。TUN 可能使用更具体的路由实现接管，不一定直接替换默认路由。
- 查看连接：运行目标应用，在客户端日志中观察目标地址、规则命中及出站结果。没有对应记录时，再排查应用是否使用独立隧道或绑定了其他接口。
- 做前后对照：保持系统代理清除，分别记录 TUN 开启与关闭时同一应用的访问结果；对照完成后恢复所需设置。
ipconfig /all
route print -4
route print -6这些命令用于查看网络状态，不会修改路由。输出可能包含本机地址和内部网络信息，不宜原样公开。即使日志显示命中代理出站，仍需确认请求实际成功；“规则命中”与“远端连接建立”是两个不同阶段。
七、TUN 失效与断网的常见问答
一开 TUN 就断网，先改 DNS 还是换节点？
先关闭 TUN，恢复此前可用的系统代理状态。如果原节点仍能访问，优先查 TUN 启动日志、管理员权限及其他虚拟网卡冲突。若系统代理也失败，再排查节点和基础网络。不要一次同时修改 DNS、节点与路由。
提示权限不足，勾上开关为什么没用？
先从托盘彻底退出程序，再以管理员身份启动并确认授权。若设备由组织管理，检查是否允许创建虚拟网卡。已经安装服务机制的版本还需确认服务正在运行；不要仅凭界面勾选状态认定权限已经生效。
网页能打开，游戏或语音还是连接失败？
先在日志中找该应用的连接，确认是否进入 TUN、命中哪条规则，再检查节点及服务端是否支持对应 UDP 流量。延迟测试成功通常不能覆盖这项验证。若应用绑定了特定网卡，还需检查应用自身网络设置。
公司内网和打印机在开启后找不到了？
核对局域网目标是否直连，并检查内部域名是否仍使用可访问的内网 DNS。先用已知内网地址区分解析故障与路由故障，不要把整个内网地址段强制送往代理服务器。涉及单位网络策略时，应由管理员确认调整范围。
关闭窗口以后仍受影响，怎样恢复？
关闭窗口可能只是隐藏到托盘。先在主界面关闭 TUN，再清除系统代理，最后从托盘退出并检查接口与路由是否恢复。若程序异常退出，重新打开后正常关闭一次；仍有残留时可重启系统，不要直接删除不明网络适配器。
稳定的配置顺序是：先验证节点，再验证 TUN 入口，最后调整 DNS 与分流。每次只变更一个环节，并保留恢复前一状态的方法。这样才能把“接管失败”“解析失败”和“出站失败”分别定位，减少反复重装或盲目改规则的时间。