浏览器能连接，游戏或命令行工具却仍然直连时，可以检查应用是否遵循系统代理，再决定是否开启 TUN。本文以 Windows 桌面版 v2rayN 为操作对象，按权限准备、虚拟网卡启用、路由验证和故障回退展开。先区分“接管流量”和“全部走代理”，再通过日志与系统命令确认配置，而不是只看开关是否亮起。
区分系统代理、TUN 与全局路由
系统代理是在操作系统中登记代理地址，由支持该设置的应用主动连接本地代理入口。它不会自动改写所有程序的网络行为：某些命令行工具读取环境变量，某些游戏直接建立套接字，还有些应用使用自己的代理设置。浏览器可以访问，只能说明浏览器这条路径基本可用。
TUN 在网络层提供虚拟网卡，再配合路由把符合条件的 IP 流量送入处理链路。应用不必主动理解 HTTP 或 SOCKS 代理，但流量是否被捕获，仍取决于路由、接口绑定、地址族与排除项。被捕获之后，还要由规则决定直连、代理或阻断。
| 设置 | 作用位置 | 不能据此保证的事情 |
|---|---|---|
| 系统代理 | 让支持该设置的应用连接本地代理端口 | 不能保证接管游戏、UDP 或所有命令行请求 |
| TUN 模式 | 通过虚拟网卡和系统路由接收 IP 流量 | 不能保证所有流量最终都从远端节点出口发出 |
| 全局代理路由 | 把规则允许范围内的请求交给代理出站 | 不能代替 TUN，也不能修复失效节点 |
| 规则分流 | 按域名、IP 等条件选择不同出站 | 不能保证所有国内或局域网地址都已被规则覆盖 |
判断：先选接管方式，再选出站规则
只需要浏览器代理，先用系统代理；需要处理不读取代理设置的应用，再尝试 TUN。若目标是让这些应用经过节点出口，还必须检查当前路由策略，不能把“开启 TUN”直接当作“全局代理”。
准备权限、节点与可回退配置
先在系统代理模式下确认所选节点可连接，再引入 TUN。VMess、VLESS 是节点使用的协议，订阅地址负责提供和更新节点配置，它们本身不负责创建虚拟网卡。节点不可用时，切换接管方式通常只会增加排查变量。
v2rayN 是图形管理客户端，实际流量处理由其调用的内核完成。不同版本的 TUN 实现和内核组合可能变化，常见实现会涉及 sing-box；不要把“节点使用 Xray”理解成“TUN 必然也由同一内核独立完成”。排障时以启动日志里的进程、配置与错误信息为准。
- 保留完整程序目录：从客户端页面选择与 Windows 架构匹配的版本，按发布说明安装或解压，不要只拷贝主程序而遗漏运行依赖。
- 记录原有设置：记下当前节点、路由预设、本地监听端口和 DNS 设置；修改前保留客户端配置备份。
- 退出其他接管工具：先关闭其他 VPN、虚拟网卡接管或透明代理工具，避免同时争用默认路由。单位设备应先确认网络管理要求。
- 准备管理员权限：首次建立虚拟网卡或修改路由通常需要提升权限。服务模式是否可用、如何授权，要看所用版本的说明。
按顺序开启 v2rayN TUN 模式
以下按常见中文桌面界面说明。v2rayN 不同发行版本可能调整标签位置；看到“Tun 模式设置”或“TUN 设置”等近似名称时，应结合版本说明核对。不要把找不到某个标签当作需要手动新建网卡的依据。
-
验证节点
在主界面选择已有节点并设为活动服务器，通过系统代理访问一个已知可用的 HTTPS 网站。若此时已失败，先处理节点地址、端口、认证与设备时间问题。
-
提升权限
从托盘彻底退出 v2rayN，再右键程序选择「以管理员身份运行」，确认系统授权提示。不要只关窗口后再次启动，以免仍在操作未提升权限的旧进程。
-
检查参数
打开「设置」→「参数设置」，检查本地监听配置；在提供该页签的版本中进入「Tun 模式设置」。首次尝试保留客户端提供的默认值，不同时更换协议栈、MTU 和 DNS 策略。
-
选择路由
在主界面底部的路由选择处确认当前预设。日常使用可先选已有的分流规则；需要对照出口时再临时使用全局代理预设，并记录原选项以便恢复。
-
启用接管
打开主界面底部「启用 Tun」开关，查看日志中是否出现网卡创建、接口启动或路由设置错误。为单独验证 TUN，可把「系统代理」切换为「清除系统代理」，避免浏览器仍通过原入口连接而造成误判。
-
核对应用
先测试浏览器，再测试原本不走系统代理的目标程序。确认日志中的目标地址和实际出站；若出现断网，先关闭「启用 Tun」，再恢复先前的系统代理设置。
“清除系统代理”只用于减少验证时的变量，不表示两个功能永远不能一起使用。稳定后可按应用需要决定是否保留系统代理；但不要让核心自身的出站再次被接回代理入口，否则可能形成循环连接。
用端口、路由与日志验证接管结果
下面三个数字是排障时常见的观察点，不是要求照填的配置。尤其是本地代理端口，必须以「设置」→「参数设置」中的实际监听值为准；示例中的 10808 若与你的设置不同，应相应替换。
在 PowerShell 中运行下面的只读命令，对比开启前后的接口与路由。TUN 可能通过更具体的路由接管流量，不一定替换原来的默认路由；因此只看默认网关是否改变并不充分。端口监听存在也只能说明入口已启动，不能单独证明节点可用。
# 查看网络接口，比较启用 TUN 前后的变化
Get-NetAdapter -IncludeHidden
# 查看 IPv4 与 IPv6 路由
route print -4
route print -6
# 仅在本地监听端口确为 10808 时使用
Get-NetTCPConnection -State Listen -LocalPort 10808
# 不读取用户 curl 配置，也不通过显式 HTTP/SOCKS 代理
curl.exe -q --noproxy "*" --connect-timeout 10 -I https://example.com最后一条命令适合观察一个未显式使用应用层代理的请求。先关闭 TUN 执行一次，再开启执行一次，并同步查看客户端日志。出现 HTTP 响应说明该目标的连接取得进展，但不能只凭成功响应就断言已走代理：该站点本来可能直连可达，还要核对日志中的出站选择。
- 确认接口：找到新增或状态改变的虚拟接口，不依赖固定网卡名称判断。
- 确认规则：检查目标请求命中了直连还是代理，必要时临时切换路由做对照。
- 确认出口：使用可信的出口地址查询服务，对比预期节点出口；分流模式下，不同目标可能使用不同出口。
- 确认覆盖：分别检查 IPv4、IPv6 与目标应用。一个浏览器标签页成功，不代表所有地址族和传输方式都已覆盖。
处理 DNS、UDP 与局域网访问
TUN 能接收到数据包，并不代表域名解析一定正确。传统 DNS 常使用 UDP 或 TCP 的 53 端口，但浏览器也可能使用加密 DNS。若出现“域名打不开、已有连接还能继续”的现象，应先检查解析链路，而不是立即更换所有节点。
在「设置」→「参数设置」中检查当前版本提供的 DNS 相关页签，区分直连解析、代理解析与 TUN 的 DNS 处理设置。域名策略与分流规则需要配合；把所有 DNS 请求交给一个当前无法访问的解析器，可能使直连与代理同时表现为超时。
| 现象 | 优先检查 | 具体操作 |
|---|---|---|
| 域名连接失败 | DNS 服务可达性、解析路径与日志 | 运行 Resolve-DnsName example.com，同时观察日志；只修改一项 DNS 设置再重试 |
| 网页正常，语音失败 | UDP 支持、节点服务端和防火墙策略 | 检查目标程序的 UDP 连接日志，确认所用节点及其传输链路支持转发 |
| 打印机或共享失联 | 局域网地址是否误走代理 | 检查路由是否为实际局域网网段配置直连，并核对本地防火墙 |
| 部分目标仍直连 | IPv6 路由、应用接口绑定、规则排除项 | 对照 IPv4 与 IPv6 路由表，并查看该目标的实际命中规则 |
排查启动失败并恢复网络
排查时按“权限与接口 → 核心启动 → 节点连接 → DNS 与分流”的顺序推进。日志中最早出现的明确错误通常比后续一串超时更有价值。分享日志前，应遮盖订阅地址、节点认证信息和其他敏感内容。
打开 TUN 就提示权限不足，怎么处理？
先从托盘退出客户端，再用「以管理员身份运行」启动。若仍失败，检查安全软件或单位策略是否阻止创建虚拟接口、写入路由；不要通过关闭全部安全防护来试错。
开关打开了，日志却说核心启动失败？
检查程序目录是否完整，并查看第一条核心启动错误。若提示地址或端口已占用，可运行 Get-NetTCPConnection -State Listen 核对进程；不要直接结束不认识的系统进程。
开启后所有网页都超时，要先改哪里？
先关 TUN，恢复原系统代理并验证同一节点。原模式也失败就先修节点；只有 TUN 失败时，再检查路由冲突与 DNS。保留默认协议栈作为基线，一次只改变一个选项。
退出客户端后还是没网络，怎么办？
若程序异常退出，可重新以相同权限运行，先关闭 TUN，再「清除系统代理」并正常退出。仍未恢复时重启电脑，再检查 Windows 代理设置与网络连接；不要直接执行清空全部路由的命令。
完成验证后，恢复适合日常使用的分流预设，并再次测试局域网、浏览器和目标应用。系统代理已经满足需求时，可以保持 TUN 关闭；需要它时再启用。保留一套已验证的配置，比反复修改 MTU、DNS、协议栈和路由更容易定位问题。