v2rayN 升级后 TUN 未接管全部应用：Windows 诊断顺序

真实错误签名与边界

v2rayN 的公开 Issue #9905 报告了 Windows 10 上“7.23.3 之后，TUN 没有将全部应用流量送入隧道”的现象。报告本身没有提供可泛化的根治结论，因此本文不把它写成“升级必坏”，而是将它作为版本变化后 TUN 范围缩小的真实检索入口。

开始前记录客户端版本、核心版本、TUN 开关状态与可复现的两个应用。不要上传订阅地址、UUID、节点地址或完整日志。

先验证路由与适配器，而非只看 UI

在管理员 PowerShell 中执行以下只读命令，并保存脱敏输出：

Get-NetAdapter | Sort-Object Status, Name |
  Format-Table -Auto Name, Status, InterfaceDescription, ifIndex
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Select-Object -First 30 DestinationPrefix, NextHop, InterfaceAlias, RouteMetric
Get-DnsClientServerAddress -AddressFamily IPv4 |
  Format-Table -Auto InterfaceAlias, ServerAddresses

观察点是：虚拟适配器是否存在、默认路由是否在启用 TUN 前后改变、DNS 是否被意外改写。它们只能证明本机状态，不能证明节点可用性。

最小复现与恢复路径

1. 导出当前配置，退出其他 VPN、代理和抓包工具，避免多个虚拟网卡竞争默认路由。
2. 以一个可验证的桌面应用和一个浏览器标签复现；记录“都不通 / 仅某应用不通 / 仅当前 Wi-Fi 不通”。
3. 关闭 TUN 后复测同一目标。若立即恢复，收集前后路由表并在对应 Issue 或维护者渠道提交版本、复现步骤和脱敏日志。
4. 不要直接执行网上的注册表“网络重置”脚本；它会抹掉定位所需的状态并影响其他网络软件。

何时才考虑线路侧因素

只有 TUN 路由、DNS 与客户端版本状态可解释地正常，而且跨本地网络仍同样失败，才应检查服务端或出口路径。此时可透明比较服务商提供的多客户端兼容说明、支持政策与网络范围；不要将某一服务宣传为对所有 TUN 故障的保证。

诊断范围

“v2rayN 升级后 TUN 未接管全部应用：Windows 诊断顺序”应先按可观察现象缩小范围：基于 v2rayN #9905 的真实 Windows 10 报告，定位升级后 TUN 未转发全部应用的范围与证据。 记录发生时间、使用的客户端与系统版本、是否仅在某个网络或某个配置下发生。不要从单次测速、单个节点或一次重试直接推断根因，也不要在未备份配置时同时修改多个开关。

操作步骤

1. 保留错误提示的非敏感部分，并记下当前客户端、系统、网络类型和最近一次成功时间；订阅链接、账号、令牌和个人网络标识不得写入截图或工单。
2. 在受控条件下只改变一个变量，例如切换已知可用的网络、恢复一份已导出的配置，或暂时停用可能重复接管流量的另一个客户端；每次改动后回到同一个操作复测。
3. 将结果归为“现象消失、现象不变、出现新错误”之一。前两类分别保留变更前后记录；出现新错误时立即恢复上一步，而不是继续叠加 DNS、代理模式、内核或系统权限改动。

验证与回退

完成调整后，以原始失败动作连续复测，并确认目标功能恢复而不是只看到界面状态改变。若复测失败，回退到已导出的配置或原先已知可用的客户端状态，再依据记录选择下一项检查。任何无法解释的证书、权限、路由或账户提示都应停止扩大改动范围并转交产品或网络管理员。

来源与适用边界

本页的“证据与参考”只用于说明已公开的配置说明或个案范围；它不能证明你的网络、账号、节点或服务端当前处于同一状态。将日志中的令牌、订阅地址、账户资料和网络标识删除后再用于比对。