v2rayN 虚拟网卡接管全局流量:TUN 模式原理、开启步骤与系统代理的区别

本文速览

浏览器可以连接，但命令行工具或其他程序仍然直连时，需要先分清系统代理与 TUN 的接管范围。本文以 Windows 上的 v2rayN 为例，按“验证节点、取得权限、开启虚拟网卡、检查路由与 DNS、测试并回退”的顺序操作。重点是让需要代理的流量进入正确出口，同时保留局域网访问，不把“接管流量”误当成“所有连接必须走代理”。

系统代理与 TUN：入口不同，出口仍由路由决定

系统代理是在操作系统中登记一个本地代理地址。遵循这项设置的应用，会把请求交给 v2rayN 的本地监听端口；忽略系统代理的程序则仍然自己建立连接。浏览器能打开网页，并不能证明终端工具、游戏或后台服务也经过了代理。

TUN 是网络层入口。客户端创建虚拟网络接口，并通过系统路由让匹配的 IP 流量进入这个接口，再由相关内核处理 TCP、UDP、DNS 与出口选择。应用通常不需要自行填写代理地址，但已有 VPN、特殊绑定网卡的程序以及其他更优先的路由，仍可能改变接管结果。

系统代理：先做基线验证

TUN：接管不读代理设置的程序

通过虚拟网卡与路由接收流量。需要额外检查权限、DNS、UDP 能力和局域网例外，不能只看开关是否亮起。

适合：终端工具、部分桌面程序、需要统一网络分流的环境

判断：先选入口，再选路由策略

系统代理能满足需求时先保留它；确有程序绕过代理，再开启 TUN。开启 TUN 后依然可以分流，只有选择相应的全局代理规则，匹配流量才会统一走代理出口。

开启前检查：节点、权限与三个端口角色

先在 v2rayN 中更新订阅、选中一个节点并设为活动服务器。通过系统代理访问实际需要使用的网站，确认节点不仅能建立连接，也能完成真实请求。延迟测试有结果不等于所有目标都可达，更不能证明 UDP 已经正常。

以下数字用于识别端口角色，不是要求把所有配置改成同一组值。v2rayN 的本地监听以「设置」→「参数设置」中的实际值为准；订阅节点的远端端口由服务提供方决定，不应为了匹配示例而修改。

10808

本地代理监听示例，以参数设置为准

传统 DNS 查询常用端口

443

HTTPS 与 DoH 常用端口

管理员权限：Windows 创建虚拟网卡、写入路由时通常需要提升权限。退出 v2rayN 后，以「以管理员身份运行」重新启动，并确认系统授权提示。
运行组件：检查安装包是否包含 TUN 所需组件。常见 v2rayN 版本使用 sing-box 承担 TUN 入口；节点使用 Xray，并不意味着 TUN 一定由 Xray 直接创建。
网络冲突：先关闭其他 VPN 或同类虚拟网卡接管功能。不要一开始就叠加多个默认路由，再猜测哪个程序在接收流量。
回退记录：记下当前系统代理状态、路由模式和 DNS 设置。首次测试只改一组配置，便于恢复。

v2rayN 开启 TUN：按顺序操作并验证

确认普通代理可用后，再启用 TUN。首次调试建议清除系统代理，让测试程序只走 TUN 这一个入口，避免系统代理仍在生效时误判“虚拟网卡已经接管成功”。这是一种排查方法，并非要求两种入口永远不能同时开启。

退出并提升权限：从托盘退出 v2rayN，再右键启动程序，选择「以管理员身份运行」。只关闭主窗口可能仍会保留后台进程。
核对活动节点：确认服务器列表中的活动服务器没有改变。需要重新添加订阅时，使用「订阅分组」→「订阅分组设置」，保存地址后执行更新。
查看本地参数：进入「设置」→「参数设置」，记录本地监听端口；若当前版本提供 TUN 设置页，先使用默认栈和默认 MTU，不要同时修改多个实验参数。
清除系统代理：在主界面或托盘的「系统代理」菜单中选择「清除系统代理」。同时确认测试程序没有单独配置代理地址或代理环境变量。
启用 TUN：打开主界面的「启用 TUN」开关。若所在版本入口位于设置菜单，以该版本显示的 TUN 项为准。观察日志是否出现网卡创建、内核启动或路由配置错误。
验证实际请求：用不配置应用代理的程序访问目标，结合路由、DNS 与访问日志判断出口。完成后再决定是否保留系统代理。

在 PowerShell 中，下面两条只读命令可以查看适配器和 IPv4 路由，不会修改系统设置。虚拟接口名称不一定包含固定字样，应比较启用前后的变化；部分 TUN 实现会使用两条更具体的路由，而不是替换原有默认路由。

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object DestinationPrefix, RouteMetric |
  Format-Table DestinationPrefix, InterfaceAlias, NextHop, RouteMetric

出现虚拟接口只是第一步。若日志显示接口正常，而应用请求没有进入对应处理链，还要检查路由优先级、应用是否绑定物理网卡，以及请求是否被规则设为直连。

路由分流：保留局域网，避免代理连接绕回自身

“TUN 接管全局流量”描述的是入口范围；“全局代理”描述的是出口策略。启用 TUN 后，家庭存储、打印机和内网服务仍可直连，其他目标再按域名、IP 或规则集进入代理。直接把所有目标强制送往远端，反而可能让局域网设备无法访问。

配置方案：日常分流与短时诊断分开

日常分流

局域网和私有地址按需要直连。
需要代理的目标明确匹配代理出口。
直连 DNS 与代理 DNS 分别配置。
保留节点服务器连接的防回环机制。

短时诊断

清除系统代理，隔离 TUN 入口。
对测试目标临时指定代理规则。
检查日志中的规则命中与出口。
测试结束恢复日常分流配置。

先证明指定目标能走代理，再扩展规则范围；不要用一次出口查询代替全部应用的验证。

目标或地址	配置方向	原因
`192.168.0.0/16`	按内网需求直连	常用于家庭路由器、打印机与存储设备。
`10.0.0.0/8`	先核对公司网络或 VPN	私有网段可能由企业隧道提供，不能盲目改走物理网卡。
当前节点服务器	保留正确的物理出口或排除机制	代理自身的连接若再次被送回同一隧道，会造成连接回环。
需要代理的业务目标	明确匹配代理出口	避免被更靠前的直连规则提前命中。

VMess 与 VLESS 是节点协议，不是“是否经过虚拟网卡”的开关。TUN 接管 UDP 后，后续链路还需要支持相应转发；游戏或语音应用失败时，应检查节点协议、服务端策略与防火墙，而不是只反复切换虚拟网卡。

DNS 配合：解析路径与连接路径一起检查

DNS 决定域名被解析成什么地址，路由决定随后连接从哪里出去。只配置远程 DNS 地址，不保证查询已经走代理；只看到网页出口变了，也不能证明浏览器自己的加密 DNS、系统 DNS 和其他应用的解析都使用同一路径。

直连目标：使用适合当前网络的解析器，并确保查询路径与直连策略一致。内网域名可能需要路由器或企业 DNS，公共解析器未必能回答。
代理目标：让相关解析请求通过代理出口发送。若使用 DoH，除了填写 HTTPS 地址，还要检查该解析器连接实际命中的出口。
启动解析：节点或 DoH 服务器本身使用域名时，需要能完成初始解析，避免“代理需要 DNS、DNS 又必须等待代理”的循环依赖。
DNS 劫持：把进入 TUN 的传统 DNS 查询交给内核处理。它主要针对匹配的 DNS 流量，不等于自动接管应用自行建立的所有加密 DNS 连接。
FakeDNS：通过虚拟地址映射保留域名信息，须由兼容的入口和规则共同处理。首次开启 TUN 时不必同时启用；若启用，退出后注意清理残留缓存。

例如，应用向局域网路由器的 53 端口查询域名，而私有地址规则又把该连接直连，解析就可能绕开代理。是否属于不符合预期的泄漏，要对照目标的分流设计判断：内网域名使用内网 DNS 是正常需求，代理目标使用本地网络解析则值得进一步检查。

操作：把失败拆成解析失败与连接失败

先看日志是否获得目标地址，再看连接命中了哪个出口。解析没有结果时排查 DNS；已有地址但连接超时时排查规则、节点和传输链路，不要把两种问题都归因于 TUN。

开启失败、断网或部分程序不通：按症状排查

先保存错误信息，再调整配置。日志中的“权限不足”“创建接口失败”“端口占用”和“连接超时”分别指向不同环节；一次性更换节点、DNS、MTU 和网络栈，会丢失判断依据。

打开 TUN 就提示创建网卡失败，怎么办？

先从托盘完全退出，以管理员身份重新运行。检查安全软件是否拦截相关组件，并确认安装包组件完整。仍失败时记录日志中的具体错误，不要直接删除物理网卡或批量清空路由。

开关亮着，但所有网站都打不开？

先关闭 TUN，验证原来的系统代理是否仍可用。若普通代理正常，重点检查 TUN 日志、节点出口防回环以及 DNS 启动解析。若普通代理也失败，优先处理节点或网络问题。

网页能用，游戏或语音还是连不上？

确认程序没有绑定其他网卡，再查看 UDP 请求是否进入内核。检查节点是否支持 UDP、服务端是否允许转发，以及目标是否命中错误规则；TCP 网页成功不能代替 UDP 测试。

开启后打印机和内网存储找不到了？

先检查目标私有网段的直连规则。网络发现还可能依赖广播或多播，不能仅靠远端代理恢复；可先用设备的实际局域网地址测试访问，再判断是否只是发现功能受影响。

关闭 TUN 后还是无法上网？

先清除系统代理，检查虚拟接口和路由是否已撤销，再清理 DNS 缓存。若进程异常退出留下网络状态，保存工作后重启系统；不要先手动删除不认识的路由条目。

Windows 清理 DNS 缓存可在终端执行以下命令。它只清理系统缓存，不会修复错误路由，也不会自动清除所有应用自身的 DNS 缓存；浏览器或其他测试应用必要时需要重新启动。

ipconfig /flushdns

验收与回退：确认接管成功，不只看开关

一套可保留的配置，应同时满足代理目标可达、直连目标正常、DNS 路径符合设计以及关闭后能恢复。测试时选取真实使用的程序，至少覆盖一个不读系统代理的应用，而不是只重复打开浏览器。

入口确认：清除系统代理和应用手动代理后，指定程序仍能通过 TUN 访问需要代理的目标。
出口确认：结合出口查询与日志，确认测试目标命中预期规则；不同分流目标可能得到不同出口，这并不矛盾。
局域网确认：访问路由器管理页、存储设备或工作所需内网服务，确认例外规则有效。
DNS 确认：分别检查系统与应用的解析设置；检测结果应与分流方案一致，不能仅凭解析器名称作判断。
回退确认：关闭 TUN 后，检查普通网络恢复，再按需要重新设置系统代理。若恢复失败，先处理残留状态，再继续调试。

TUN 的作用是扩大客户端能处理的流量范围，不是自动消除所有网络限制。按入口、解析、规则、出口四个环节逐项核对，通常比不断切换内核或反复导入订阅更容易找到问题。基础订阅与系统代理配置可先阅读入门指南；需要核对路由和 DNS 概念时，可查看完整文档。