适合已经能用 VMess、VLESS 或订阅节点正常连接，但仍遇到部分程序不走代理的用户。正文从流量接管层级讲起，依次说明 v2rayN 7.x 与 v2rayNG 1.10.x 的开启路径、路由配置、DNS 处理、验证方法以及关闭后的恢复步骤。
TUN 模式与系统代理的链路差异
系统代理和 TUN 模式解决的是两个层级的问题。系统代理通常只是在操作系统里写入 HTTP 或 SOCKS 代理地址，例如 v2rayN 常见的本地 HTTP 端口 10809。浏览器、下载工具或聊天程序只有主动读取这项设置，流量才会进入客户端。忽略系统代理的程序、固定直连的启动器以及部分命令行工具，仍可能直接访问网络。
TUN 模式会创建一张虚拟网卡，并调整系统路由，让目标 IP 流量先进入虚拟接口。客户端读取数据包后，再交给 Xray 或 v2fly 内核执行域名嗅探、DNS 解析和路由分流。应用不需要认识 HTTP 代理，也不需要单独填写 127.0.0.1 与端口号，因此它更适合需要统一接管多个进程的场景。
“接管全局流量”不等于“所有连接都必须走代理节点”。TUN 负责把数据包交给客户端，最终选择代理、直连还是阻断，仍由路由规则决定。例如局域网地址、打印机地址和国内站点可以保持直连，只有命中代理规则的请求才进入 VMess 或 VLESS 出站。接管范围与出站策略是两个独立概念。
- 系统代理：配置简单，适合明确支持 HTTP 或 SOCKS 代理的桌面程序。
- TUN 模式：覆盖不读取系统代理的进程，并能统一处理 TCP、UDP 与 DNS 请求。
- 全局代理：是一种路由决策，表示被接管的外部流量优先使用代理出站。
- 规则分流：根据域名、IP、端口或进程等条件选择不同出站。
Windows 上开启 v2rayN TUN 模式
以下步骤以 v2rayN 7.x 为基线。不同小版本的按钮位置可能在主窗口顶部或托盘菜单中变化，但核心配置项仍是 TUN、路由与 DNS。首次创建虚拟网卡需要管理员权限；没有提升权限时，界面可能显示已切换，日志却会出现创建接口失败或路由写入失败。
- 打开 v2rayN，先更新订阅并选择一个已测试可用的节点。
- 进入「设置」→「参数设置」→「TUN 模式」，确认启用 TUN 使用的内核与堆栈选项。
- 保存设置，完全退出客户端，再通过系统的“以管理员身份运行”重新启动。
- 在主窗口或托盘菜单打开「TUN 模式」。等待状态栏显示运行，并观察日志中是否完成虚拟接口与路由初始化。
- 将路由模式设为规则分流，先保留局域网直连，再测试浏览器和原先无法读取系统代理的程序。
v2rayN 基础参数
- 版本基线
- 7.x
- SOCKS 端口
- 10808
- HTTP 端口
- 10809
- 权限
- 管理员运行
- 路由方式
- 规则分流
本地代理端口用于普通系统代理；TUN 的数据包由虚拟接口接管，不应把两者当成同一个监听入口。
TUN 建议起始配置
- 局域网
- 直连
- DNS
- 随 TUN 处理
- IPv4
- 优先验证
- UDP
- 按节点能力
- 系统代理
- 避免重复切换
先用最少变量确认链路，再逐项加入自定义 DNS、进程规则和更细的域名分组。
启动后先看日志，而不是只看按钮颜色。正常过程应包含 TUN 接口创建、路由规则应用和核心启动成功。若日志在端口监听阶段停止，检查 10808、10809 是否被另一个 v2rayN 实例占用；若停在接口创建阶段，则重点检查管理员权限和残留虚拟网卡。
系统代理可以在测试 TUN 时暂时关闭，以便确认请求确实来自虚拟网卡接管。若关闭系统代理后浏览器仍能按规则访问，而局域网设备也能直连，说明 TUN 与路由规则基本工作正常。测试结束后不要同时频繁切换两套接管方式，否则排查时很难判断流量究竟从哪个入口进入。
判断标准:关闭系统代理后再验证
只在系统代理开启时测试，无法证明 TUN 已经接管流量。关闭系统代理、保留 TUN，再分别测试浏览器、命令行程序和局域网地址，结果更容易定位。
Android 上配置 v2rayNG 的 VPN 接管
v2rayNG 在 Android 上通过系统 VPN 服务创建虚拟网络接口，其工作位置与桌面端 TUN 接近。用户点击连接后，系统会显示 VPN 授权确认；授权通过后，符合接管范围的应用流量进入 v2rayNG，再由 Xray 内核根据节点配置和路由规则处理。
以 v2rayNG 1.10.x 为配置基线，先导入订阅并完成节点延迟测试。进入「设置」→「VPN 设置」，检查 VPN 模式、应用代理范围、绕过局域网与本地 DNS 相关选项。返回主界面选择节点后点击连接，首次运行时接受系统 VPN 连接请求。
- 在「订阅设置」中保存完整订阅地址，执行更新并选择可用节点。
- 进入「设置」→「VPN 设置」，保持 VPN 接管开启。
- 需要全设备接管时，不启用仅代理指定应用；需要缩小范围时，再建立应用列表。
- 开启绕过局域网，避免访问路由器管理页或局域网服务时绕远路。
- 返回主界面连接，确认状态栏出现系统 VPN 标识，再执行 DNS 与网页访问测试。
v2rayNG 全设备接管
- 版本基线
- 1.10.x
- 运行内核
- Xray
- 接管方式
- 系统 VPN
- 应用范围
- 全部应用
- 局域网
- 建议绕过
适合先验证整体链路，确认稳定后再缩小应用范围。
按应用分配
- 入口
- VPN 设置
- 模式
- 应用代理
- 选择方式
- 指定或排除
- DNS
- 跟随核心
- UDP
- 节点需支持
列表方向必须确认清楚：指定应用与排除应用的结果正好相反。
如果使用 v2flyNG，接管方式同样依赖系统 VPN 服务，但运行内核是 v2fly。订阅中的 VMess、VLESS 与传输参数必须由客户端和内核共同支持；TUN 或 VPN 接管只改变流量入口，不会自动改写服务器地址、UUID、传输层或 TLS 参数。
DNS、路由与 UDP 的配置重点
TUN 已成功创建但域名打不开，常见原因不是节点断开，而是 DNS 请求仍从另一条路径发出。应用先获得错误地址，后续连接即使进入代理也会失败。配置时应让域名解析和实际流量遵循相同的分流逻辑，避免系统 DNS、客户端 DNS 与浏览器独立 DNS 同时竞争。
在 v2rayN 中，进入「设置」→「参数设置」检查 DNS 与路由配置。若使用域名规则，应保留域名信息供内核匹配；若过早只得到 IP，部分基于域名的分流规则可能无法命中。启用嗅探可以从部分 TCP 或 HTTP 流量中恢复目标域名，但它不是修复所有 DNS 问题的替代品。
| 检查对象 | 正常表现 | 异常表现 | 处理方向 |
|---|---|---|---|
| DNS 请求 | 由核心按规则解析 | 解析超时或返回不可达地址 | 统一客户端 DNS 路径 |
| 局域网地址 | 直接访问网关与设备 | 路由器管理页打不开 | 加入私有地址直连 |
| UDP 流量 | 节点与出站均支持 | 语音或实时连接失败 | 检查节点 UDP 能力 |
| 域名规则 | 日志显示预期出站 | 所有请求落入默认规则 | 检查顺序与嗅探结果 |
路由规则按顺序匹配时，应把明确条件放在默认规则之前。常见起始顺序是：私有 IP 直连、局域网域名直连、明确需要代理的域名走代理，最后由默认规则承接未命中的请求。规则越多，越需要通过日志确认实际命中项，而不是凭网页是否打开推断。
UDP 能否使用取决于应用、客户端、运行内核、协议配置和服务端能力。TUN 可以捕获 UDP 数据包，但不代表所选 VMess 或 VLESS 节点一定能完整转发。出现网页正常、实时语音或游戏连接异常时，应单独检查 UDP 日志，并用另一个已知支持 UDP 的节点交叉测试。
配置顺序:先统一 DNS，再扩展分流
首次开启 TUN 时只保留局域网直连与一条默认代理规则。确认 DNS、TCP 和 UDP 基本链路后，再增加域名组、进程条件与自定义出站，能显著减少变量。
常见故障与恢复步骤
TUN 故障应从“虚拟网卡是否创建”开始排查，再看路由、DNS、核心与节点。直接更换订阅往往会跳过真正问题。尤其是客户端异常退出后，残留路由可能让系统表现为所有网络都不可用，此时应先关闭 TUN 并完全退出客户端。
开启 TUN 后立刻断网怎么办？
先关闭 TUN 并退出 v2rayN，再重新打开网络适配器。随后以管理员身份启动客户端，查看日志是否在创建接口或写入路由时失败；不要在断网状态下连续叠加多次启动。
浏览器能用，某个程序仍然直连怎么办？
关闭系统代理，只保留 TUN 后重试，并检查该程序是否使用独立网络服务、固定网卡或特殊 UDP 通道。Android 端还要进入「设置」→「VPN 设置」确认应用没有被排除。
连接成功但域名全部超时怎么办？
先直接测试一个确定可达的 IP，再检查客户端 DNS 日志。关闭浏览器单独设置的 DNS，统一由核心处理解析，并确认 53 端口请求没有被其他网络工具截获。
局域网打印机和路由器页面打不开怎么办？
在路由配置中让私有地址段与局域网域名直连，并启用绕过局域网。修改后重新连接 TUN，再分别测试网关地址和设备地址。
关闭客户端后网络没有恢复怎么办？
确认进程已完全退出，禁用后重新启用物理网络适配器，然后检查系统代理是否仍指向 127.0.0.1:10809。必要时重启系统，让残留虚拟接口和临时路由被清理。
端口占用主要影响本地 HTTP、SOCKS 或控制接口。Windows 可先在终端查看 10808 与 10809 的监听进程，再决定关闭旧实例还是修改端口。修改端口后，还要同步更新系统代理设置；否则系统仍会把请求送到旧端口，看起来就像 TUN 或节点失效。
netstat -ano | findstr :10808
netstat -ano | findstr :10809
tasklist | findstr <PID>执行关闭操作时，应先在客户端内关闭 TUN，再退出程序，不要直接结束核心进程。正常关闭会撤销临时路由并释放虚拟接口。若需要在 TUN 与系统代理之间切换，也应完成一次关闭和网络验证后再启用另一种模式。
- 关闭 TUN 或 Android 系统 VPN 连接。
- 完全退出 v2rayN、v2rayNG 或 v2flyNG。
- 确认系统代理没有残留 127.0.0.1:10809。
- 测试直连网络、局域网网关与 DNS 解析。
- 重新启动客户端，只启用一种接管方式进行复测。
验证 TUN 是否真正接管流量
验证不能只看“已连接”状态。完整测试应覆盖一个支持系统代理的程序、一个不读取系统代理的程序、一个局域网地址以及一项 UDP 功能。四类结果能分别反映虚拟网卡接管、规则分流、局域网绕过和 UDP 转发是否正常。
- 关闭系统代理，只保留 TUN，确认普通网页仍能访问。
- 运行原先不走系统代理的程序，观察核心日志是否出现对应目标。
- 访问路由器网关或局域网设备，确认请求命中直连规则。
- 执行 DNS 检测，确认解析请求与代理流量采用预期路径。
- 测试实时语音或其他 UDP 场景，确认没有持续超时。
日志是最终判断依据。v2rayN 可从主界面的运行日志查看入站、目标地址与出站标签；v2rayNG 可在日志页面观察连接建立和路由结果。若目标请求根本没有出现，问题在接管范围或系统路由；若请求出现但出站错误，问题在规则；若出站正确仍连接失败，再检查节点与目标网络。
TUN 适合解决“应用不遵循代理设置”这一类入口问题。配置稳定后，应保留一份清晰的基线：客户端版本、订阅更新时间、当前节点、路由模式、DNS 设置和本地端口。后续故障只改一个变量，并记录改动前后的日志结果，比反复重装更容易定位。