本文以 Windows 桌面的 v2rayN 为操作对象。先用系统代理确认节点可用，再以管理员身份启用 TUN，最后分别验证路由、DNS 与应用连接。适合浏览器能联网、命令行工具或其他程序却不走代理的情况；TUN 接管流量后，最终直连还是代理仍由路由规则决定。
系统代理与 TUN：接管位置不同
系统代理把本地代理地址交给遵循系统设置的程序。应用主动把请求发给代理监听端口，客户端再转发。程序如果使用自己的网络栈、独立代理设置，或者直接建立 UDP 连接，就可能绕过这层设置。浏览器能打开网页，并不能证明其他程序也在走代理。
TUN 在网络层提供虚拟接口。系统路由把符合条件的 IP 数据包交给该接口，由 TUN 后端处理，再送到直连或代理出站。应用通常不必支持 HTTP 或 SOCKS 代理，但这也不代表任何网络协议、任何地址都会被完整转发。
这里要区分两个“全局”：TUN 的接管范围和路由的代理范围不是同一个开关。启用 TUN 后，局域网、私有地址或规则指定的目标仍可以直连。需要所有可接管的公网连接走代理时，还要检查当前路由模式与兜底出站，而不是只看 TUN 开关是否亮起。
开启前：记录端口、节点与路由基线
先在 v2rayN 中选择一个已导入的节点并设为活动服务器，使用系统代理完成一次真实网页访问。仅有延迟结果不够：测试成功只能说明对应探测路径可用，不代表 DNS、TLS 和业务流量全部正常。如果这个阶段就失败，应先检查节点地址、凭据、传输参数与服务端状态。
10808 只是下文的测试值。先打开「设置」→「参数设置」，查找本地监听端口相关项，以实际值替换命令中的端口。不同版本可能提供混合监听，或分别列出 SOCKS 与 HTTP 端口；只有确认该端口支持 HTTP 代理，才使用下文的 HTTP 代理测试命令。
- 记录当前活动节点、路由模式和系统代理状态，必要时备份客户端配置。
- 退出其他正在接管默认路由或 DNS 的 VPN、加速器与代理程序，保留一个接管者做基线测试。
- 确认当前发行包具备相应内核组件。日志若提示可执行文件缺失，应先补齐组件，不要反复切换 TUN。
- 在公司设备上先确认网络与终端安全策略允许创建虚拟接口；不要通过关闭安全软件来绕过管理策略。
Windows 开启步骤：管理员权限与 TUN 参数
以下按具有「启用 TUN」开关的 v2rayN 界面说明。桌面版与 WPF 版、不同版本的按钮位置可能不同；主界面通常提供 TUN 开关，参数集中在「设置」→「参数设置」中的 TUN 相关页。若当前界面没有这些选项，先核对客户端版本与发行包类型，不要在 Windows 网络设置里手工创建同名网卡。
- 完整退出再提权。从托盘菜单退出 v2rayN，确认原有实例已经结束，再右键程序选择「以管理员身份运行」。只重新打开窗口、托盘进程仍在运行时，可能继续使用旧实例权限。
- 确认活动节点。查看主界面当前服务器与路由模式。先沿用已经验证可用的节点，不要在首次启用 TUN 时同时更换订阅、传输方式和 DNS。
- 检查 TUN 参数。首次保留客户端提供的默认栈、MTU 与路由相关设置。自定义配置用户应确认自动路由没有被关闭，否则虚拟接口存在也未必接管目标连接。
- 清除系统代理。通过客户端的系统代理菜单清除系统代理，形成单独验证 TUN 的环境。两者并非绝对不能共存，但同时开启会让浏览器测试无法证明 TUN 是否生效。
- 启用 TUN 并观察日志。在主界面打开「启用 TUN」，查看是否出现权限不足、接口创建失败、内核退出或配置解析错误。出现错误时先关闭开关，再处理第一条明确报错。
路由与 DNS：保留局域网，避免出站回环
TUN 必须处理一个基本问题：应用流量要进入隧道，但代理内核连接服务端的流量不能再被自己无限接回。正常情况下，客户端与后端会通过路由排除、接口绑定等机制处理这个问题。多个接管程序并存、手动添加默认路由或自定义配置不完整，都可能破坏这一关系。
首次验证基线
- 接管方式
- 仅启用 TUN，清除系统代理
- 活动节点
- 沿用已通过实际访问测试的节点
- TUN 栈与 MTU
- 保留当前版本默认值
- DNS 配置
- 沿用客户端可用配置，不同时换解析器
先缩小变量，再根据日志定位接管、解析或出站问题。
基线通过后调整
- 局域网目标
- 按需直连 192.168.0.0/16 等私有网段
- 代理服务端
- 确认连接未被重复送回 TUN
- 公网目标
- 按当前路由规则选择出站
- DNS 路径
- 解析器可达性与对应出站一致
这些是检查目标，不是可直接导入的配置键；具体字段取决于后端版本。
局域网规则只列出 192.168.0.0/16 并不完整，还要结合实际网络检查 10.0.0.0/8、172.16.0.0/12 等地址，以及 IPv6 局域网范围。打印机、文件共享和网关管理页应按需求直连，不能只凭一个“绕过局域网”名称就认定全部覆盖。
DNS 同样需要验证。普通 UDP/TCP 53 查询与应用自带的加密 DNS 不是同一条路径；浏览器启用独立解析器时，结果可能与系统不同。如果启用了 FakeIP，合成地址也不自动意味着解析错误，应检查后端是否还能把该地址映射回域名。不要把清空缓存当成修复不可达解析器的方法。
验证接管：不要只刷新浏览器
验证时关闭浏览器里手动填写的代理，确认系统代理已清除。为避免旧连接沿用原有路径，关闭目标应用再重新打开。下面的命令用于区分显式代理连接与正常系统网络连接；测试域名只提供可重复的 HTTPS 请求，不用于判断具体网站是否命中代理规则。
# 在 Windows PowerShell 中执行
# 仅当 10808 确认支持 HTTP 代理时使用第一条
curl.exe -I --connect-timeout 10 --proxy http://127.0.0.1:10808 https://example.com
# 禁止 curl 使用显式代理，由系统路由处理
curl.exe -I --connect-timeout 10 --noproxy "*" https://example.com
# 查询当前接口与 IPv4、IPv6 路由
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
Get-NetRoute -AddressFamily IPv6
# 单独查看系统 DNS 查询结果
Resolve-DnsName example.com- 先比较开关前后。关闭 TUN 执行一次不使用显式代理的请求，再启用 TUN 重试；同时观察客户端是否记录到该应用的新连接。单次成功不能证明路径发生变化。
- 检查匹配出站。某个测试目标可能本来就被规则指定为直连。要验证代理路径，应选择已明确配置为代理的目标，并查看连接记录或相应级别的路由日志。
- 分开测试 IPv4 与 IPv6。必要时给请求分别添加
-4、-6。一种成功、另一种失败时，应核对地址族的接管与出站能力，而不是直接认定节点失效。 - 单测目标应用。网页和命令行通过后，再测试实际遇到问题的程序。UDP 是否可用取决于 TUN 后端、节点协议和服务端，不由 HTTPS 测试结果决定。
不要只查有没有一条指向虚拟接口的 0.0.0.0/0。自动路由可能使用更具体的分段路由；应结合目的地址、前缀长度和接口查看实际选择。日志只在需要时临时提高详细程度，分享前删除节点地址、凭据和包含私人访问记录的内容。
常见故障：按权限、接管、解析、出站排查
打开 TUN 就报错，开关又关了？
先从托盘完整退出，再以管理员身份运行。查看日志中最先出现的接口、权限或内核启动错误。如果是组件缺失或配置字段不兼容，应修复对应发行包或撤回自定义 TUN 配置；管理员权限不能解决配置解析错误。
系统代理能用，TUN 打开后全断网？
关闭其他 VPN 与加速器，保留单个接管程序。先关闭 TUN 恢复基线，再查看启用后的路由变化和服务端连接日志。若代理服务端连接也被重复接管，应检查自定义路由排除项，而不是不断切换节点。
能建立连接，但域名一直解析失败？
用 Resolve-DnsName example.com 单独检查系统解析，再检查客户端 DNS 日志和解析器出站。只有确定配置已修正后，才执行 ipconfig /flushdns 清理旧缓存。浏览器独立 DNS 需要另外检查。
开启后打印机或公司内网访问不了？
记录内网目标的实际地址，核对私有网段直连规则及网卡路由。公司专用域名还可能依赖内部 DNS；把它们交给公网解析器通常得不到正确结果。调整前保存原配置，不要把整个公司地址段盲目加入代理。
网页正常，游戏或语音还是不通？
先确认该程序没有独立绑定其他接口，再检查 UDP 连接日志与节点的 UDP 支持。持续小包能通、大包连接容易停住时，才进一步排查 MTU 或路径 MTU；没有证据时不应把修改 MTU 当成第一步。
关闭与回退：先撤销接管，再退出客户端
不再使用 TUN 时，先在 v2rayN 关闭「启用 TUN」，确认普通网络访问恢复，再退出客户端。如果要改回系统代理，先确认本地代理监听正常，然后通过客户端重新设置系统代理。这样可以明确区分虚拟网卡路径和应用代理路径，避免留下指向已退出进程的系统代理地址。
- 正常关闭 TUN，观察日志是否完成后端停止与路由清理。
- 清除不再使用的系统代理设置，重新打开目标应用测试。
- 异常退出后仍断网时，先重新启动客户端并正常开关一次 TUN，或重启系统，再检查残留路由。
- 不要直接删除不认识的虚拟网卡、批量清空路由表或重置所有网络接口；这些操作可能同时破坏其他工作网络配置。
TUN 解决的是应用流量如何进入客户端。节点是否可用、域名如何解析、规则匹配到哪个出站，仍是独立问题。按“系统代理基线、单独 TUN 验证、目标应用复测”的顺序记录结果，通常比同时修改多处设置更容易定位故障。有关规则与 DNS 的进一步说明可查阅进阶配置，术语含义可参照术语表。