本文以 Windows 上的 v2rayN 为操作基准，适合系统代理已能使用、但终端或其他应用仍无法按规则联网的用户。先验证节点，再以管理员权限启用 TUN，最后分别检查接管范围、路由结果与 DNS。TUN 负责把流量送入处理链，不等于所有连接都必须走代理；macOS、Linux 的权限与网络管理方式需按平台处理。
TUN 虚拟网卡与系统代理的区别
系统代理把本机代理地址交给支持该设置的应用。浏览器通常能够使用，部分终端程序、游戏或自行建立连接的应用则不会读取它。TUN 创建三层虚拟网络接口，配合系统路由把 IP 数据包交给本地网络处理组件，因此可以覆盖更多不支持 HTTP 或 SOCKS 代理设置的程序。
“接管全局流量”描述入口范围，“全局代理”描述出口策略，两者不是同一个开关。TUN 接到的连接仍可按域名、目标 IP 或其他受支持条件分到直连、代理、阻断。局域网、回环地址以及明确排除的路由，也可能不进入 TUN；不能仅凭开关亮起就认定所有流量已经被接管。
| 比较项 | 系统代理 | TUN 模式 |
|---|---|---|
| 入口机制 | 应用连接本地代理端口 | 系统路由将 IP 数据包送到虚拟接口 |
| 应用要求 | 应用支持系统代理或单独填写代理 | 通常不必逐个应用配置代理地址 |
| 权限要求 | 修改当前用户代理通常不需提权 | 创建接口、调整路由通常需要提权 |
| UDP 能力 | HTTP 系统代理不能覆盖普通 UDP | 仍取决于 TUN 组件、协议和服务端支持 |
| 排查重点 | 监听端口、应用代理设置 | 接口、路由、DNS 与出站链路 |
启用前：先确认节点与本机端口
先关闭 TUN，以系统代理或应用手动代理测试节点。订阅导入成功只说明配置被读取，不代表远端地址可达。VMess、VLESS 等连接参数、传输方式与 TLS 设置仍须匹配服务端。如果普通代理已经连接失败，应先修复节点，避免把节点故障与虚拟网卡问题混在一起。
以上是协议端口与测试示例，不是性能实测，也不是对 v2rayN 默认监听值的承诺。在「设置」→「参数设置」中核对本地监听端口；界面分组随版本变化。只有确认该端口接受 HTTP 代理后，才执行下面的命令。示例假定监听地址为 127.0.0.1、端口为 10808。
curl.exe --proxy http://127.0.0.1:10808 --head --connect-timeout 10 https://www.example.com/- 收到 HTTP 响应头，说明这一次请求的代理链路已建立；不代表所有网站和 UDP 都可用。
- 提示连接本机端口失败，先检查核心是否启动、监听端口是否一致，以及端口是否被其他进程占用。
- 提示握手或远端连接失败，查看核心日志，核对节点、系统时间和服务端参数。
- 记录当前系统代理、路由模式与 DNS 设置，关闭其他正在接管网络的工具，保留可恢复的基线。
Windows 开启 v2rayN TUN 的操作顺序
v2rayN 是配置与进程管理界面，TUN 的实际处理由配套组件完成。不同版本的开关位置、网络栈选项和启动方式可能不同，不能把桌面界面的某个选项当作 V2Fly 或 Xray 通用字段。先确认当前安装包包含该版本需要的 TUN 组件，再进行权限提升。
- 退出并提权启动。从托盘退出 v2rayN，确认旧实例结束。右键程序或快捷方式，选择「以管理员身份运行」。若当前版本提供提权重启入口，也可以使用该入口。
- 选定可用节点。在服务器列表选择已通过普通代理测试的节点，核对当前路由模式。首次测试沿用现有规则，不同时更换节点、DNS 和网络栈。
- 清除系统代理。在主窗口或托盘的系统代理菜单中选择「清除系统代理」。这一步用于减少双重入口带来的排查变量，并非所有版本启用 TUN 的强制前提。
- 开启 TUN。在主界面找到「启用 Tun」或同义的 TUN 开关并开启。不同界面大小写可能不同；若没有该入口，先核对平台、安装包与当前版本文档，不要安装来源不明的网卡驱动。
- 观察启动日志。确认没有权限不足、接口创建失败或路由写入失败。随后检查系统网络接口与路由，再发起一次不指定代理的请求。
路由分流与 DNS：接管之后怎么走
稳定配置需要同时回答两个问题：连接匹配哪个出口，域名通过哪个解析路径获得地址。TUN 接管到连接后，路由策略仍需保留本地网络访问，并防止代理服务器自身的连接重新进入代理入口形成回环。优先使用客户端为当前 TUN 方案生成的配置，不要把另一种核心的 JSON 直接粘贴进去。
首次接管基线
- 系统代理
- 清除，便于隔离测试
- TUN 开关
- 开启后检查启动日志
- 本地地址
- 保留回环与局域网访问
- 代理节点
- 沿用已验证的节点
这是客户端操作检查表，不是可导入的内核配置字段。
DNS 检查基线
- 传统查询
- 检查 UDP/TCP 53 的处理路径
- 加密查询
- 单独核对应用内 DoH 设置
- 解析出口
- 确保 DNS 上游能够经所选路径访问
- IPv6
- 同时核对 IPv6 路由和解析结果
只接管传统 DNS，并不意味着应用内加密 DNS 已按相同策略处理。
局域网地址应按实际网络规划处理。例如 192.168.1.0/24 可能是家用路由器所在网段，但企业网络可能使用其他网段。不要只添加一个示例网段就认定全部内网已被覆盖；应根据路由表确认打印机、文件服务器和内部 DNS 的目标范围。
- 域名规则优先考虑信息来源。应用可能先自行解析再发起 IP 连接。若规则依赖域名，需要确认当前 TUN 方案如何保留或恢复域名信息，不能假定每条连接都带有域名。
- DNS 上游不能依赖无法建立的连接。代理节点地址本身需要域名解析时，应避免“先连节点才能解析节点”的启动依赖。
- IPv4 与 IPv6 分别验证。网页可用并不证明两种地址族都进入预期路径。IPv6 缺少接管路由时，应用可能走另一条出口。
- 规则改动后重新加载。通过客户端保存并重新加载配置，再用新连接测试。已有长连接可能继续使用此前建立的路径。
验证 TUN：接口、路由与实际连接
不要仅看任务栏图标或虚拟网卡名称。有效验证需要把三个证据对齐：接口已创建、目标路径经过预期路由、连接日志显示正确出站。接口名称由组件和版本决定，不能要求所有机器都出现同一个名字；路由也可能使用比默认路由更具体的网段，不能只找一条 0.0.0.0/0。
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
Get-NetRoute -AddressFamily IPv6
curl.exe --noproxy "*" --head --connect-timeout 10 https://www.example.com/前三条命令在 PowerShell 中运行。最后一条通过 --noproxy "*" 避开 curl 的显式代理入口，让请求交给系统路由；它不会绕过 TUN。请求成功只能证明该目标当前可达，还需结合日志确认它走的是直连还是代理。
| 测试对象 | 操作 | 判定依据 |
|---|---|---|
| 不设置代理的程序 | 清除其独立代理设置，再发起新请求 | 核心日志出现对应连接及预期出站 |
| 局域网服务 | 访问实际网关、打印机或内部站点 | 本地服务可达，未误送远端代理 |
| 域名解析 | 清理应用缓存后访问测试域名 | DNS 日志、连接目标与策略一致 |
| UDP 应用 | 使用实际需要的语音或其他 UDP 功能 | 服务端及所选协议支持，日志无连续失败 |
ping 使用 ICMP，不等同于 TCP 或 UDP 代理测试。某个目标无法响应 ping，不足以判断 TUN 失效；浏览器打开网页也不足以证明语音、游戏和所有 UDP 请求都正常。应按真实应用的传输协议分别测试。
TUN 开启失败、断网与网卡冲突排查
按“权限与组件、接口与路由、DNS、远端链路”的顺序排查。每次只改一个变量，并保存故障时间点附近的日志。虚拟机网络、企业远程接入软件和其他虚拟网卡可能合法共存，出现问题时先停用相互竞争的接管功能，不要批量卸载所有网络适配器。
开关一打开就自动关闭，怎么处理？
先检查是否以管理员权限启动，再查日志中的接口创建、文件缺失或权限错误。确认当前包包含所需组件，且没有被安全策略隔离。不要仅凭失败现象反复切换网络栈；应先定位第一条启动错误。
开启后所有网页都打不开，是 DNS 问题吗？
不一定。先关闭 TUN，复测原来的本地代理链路；若仍失败，先查节点。若普通代理正常，再对照 TUN 路由与 DNS 日志。出现解析超时后才重点检查 DNS 上游可达性、查询出口以及节点域名的启动解析。
网页正常，但语音或游戏连不上怎么办？
确认应用实际使用 UDP，并核对当前代理协议和服务端是否支持该流量。查看日志是否有对应目标，再检查防火墙。TCP 网页成功不能替代 UDP 测试，单纯换一个本地监听端口也不会补齐服务端能力。
公司内网、打印机在开启后失联了？
先关闭 TUN 验证是否恢复，再查看目标内网网段与当前路由是否重叠。按实际网段补充直连或绕过规则。企业远程接入仍需使用时，应遵循组织网络策略协调路由，不要覆盖受管网络设置。
关闭窗口后仍然断网，怎么恢复？
先区分关闭窗口与退出程序：托盘进程可能仍在运行。重新打开主窗口关闭 TUN，再清除系统代理并从托盘退出。若进程异常终止，恢复启动后正常关闭一次；仍有残留时保存路由信息，再重启系统确认。
退出 TUN 与保留可复现配置
测试完成后保留一份最小记录：操作系统、客户端版本、当前节点协议、TUN 开关、路由模式、DNS 上游，以及出现故障时的第一条错误。不要公开订阅地址、连接凭据或带有用户标识的完整配置。记录应能说明哪一步改变了行为，而不是只写“开启后不能用”。
- 先关闭 TUN，等待日志显示相关进程或接口停止，确认普通网络恢复。
- 若继续使用系统代理，再单独设置系统代理模式；若退出客户端，则保持系统代理已清除。
- 重新测试局域网与常用站点，检查是否仍有其他工具持有默认路由。
- 确认基线稳定后，再逐项启用自定义分流或其他高级选项，避免一次导入多套互相覆盖的规则。
TUN 的价值是扩大流量入口的覆盖范围，最终行为仍由路由、DNS 与出站能力共同决定。需要进一步核对字段时，可阅读配置字段说明；不要把客户端生成的 TUN 配置误当作适用于所有核心的通用 config.json。