本文速览
本文适合已经能在 v2rayN 中正常连接节点、但发现部分程序不读取系统代理的用户。内容依次说明 TUN 如何接管流量、开启前要检查什么、Windows、macOS 与 Linux 上怎样处理权限，以及如何用 Xray 路由规则保留直连、代理和阻断三类出站。
TUN 模式与系统代理的接管范围
系统代理本质上是向操作系统登记一个 HTTP 或 SOCKS 代理地址，例如 v2rayN 常见的本地混合端口
127.0.0.1:10808。浏览器和遵循系统代理设置的桌面程序会把请求交给该端口，但自行建立连接、固定使用直连或不读取系统代理的程序可能绕过它。因此，开启系统代理并不等于所有进程的网络流量都会进入 Xray 内核。TUN 模式会创建一块虚拟三层网卡，并通过系统路由把目标流量送入这块网卡。客户端读取 IP 数据包后恢复连接信息，再交给分流规则判断应该走代理、直连还是阻断。应用通常不需要单独填写代理地址，因此游戏平台、命令行工具、使用自定义网络栈的软件也更容易被统一接管。
应用发起请求TUN 网卡捕获规则匹配分流选择对应出站返回应用
两种模式不是简单的强弱关系
- 系统代理：改动范围小，开启和退出都较直接，适合浏览器、办公软件与明确支持代理设置的程序。
- TUN 模式：接管范围更完整，需要创建虚拟网卡、写入路由并获得提升权限，适合无法单独设置代理或需要统一分流的应用。
- 全局流量：表示流量先进入 TUN 接管链路，不代表所有目标都必须走远端代理；最终出站仍由路由规则决定。
- 本地回环：
127.0.0.0/8、局域网地址与客户端自身连接需要正确排除，避免形成代理套代理的循环。
判断 TUN 是否必要，可以先关闭系统代理并测试目标程序。如果程序完全不受系统代理开关影响，但业务又要求其流量接受统一规则，TUN 才是更合适的处理方式。日常只使用浏览器时，没有必要仅为了“全局”字样增加虚拟网卡和路由层。
开启前检查版本、节点与端口
排查顺序应从节点可用性开始，而不是直接反复切换 TUN。先在普通系统代理模式下选择一个节点，打开可访问的测试页面，并确认 v2rayN 核心日志里没有认证失败、TLS 握手失败或连接超时。节点本身不可用时，TUN 只会扩大故障范围。
下列数值可作为 v2rayN 7.15.x 桌面环境的检查基线。不同小版本可能调整菜单名称或自动生成的网段，但端口占用、默认路由和 DNS 接管的判断方法一致。
7.15.x
本文操作参考版本
10808
常见本地混合端口
53
DNS 标准端口
2 条
IPv4 默认路由常见拆分
- 在服务器列表中双击已验证可用的 VMess 或 VLESS 节点，使其成为活动服务器。
- 进入「设置」→「参数设置」，确认本地监听端口没有与其他代理程序重复。若日志出现 address already in use，应先退出占用端口的进程，或把本地端口改为未使用值。
- 校准系统日期、时间和时区。TLS 与 Reality 连接依赖合理的系统时间，明显偏差会导致握手阶段失败。
- 记录当前网络状态，包括正在使用的网卡、默认网关和 DNS 地址。这样在异常退出后，可以判断残留的是路由、DNS 还是虚拟网卡。
- 暂时退出其他会创建虚拟网卡或修改默认路由的网络工具，避免两套接管规则争抢优先级。
v2rayN TUN 设置中的关键参数
在 v2rayN 7.x 中，可从「设置」→「参数设置」进入 TUN 相关设置，保存后回到主界面启用「TUN 模式」。部分版本会把开关放在主窗口上方或托盘菜单中，但操作结果相同：启动具备 TUN 入站能力的核心、创建虚拟网卡并写入路由。
参数不宜一次改动过多。第一次测试建议保留自动路由与自动检测接口，只调整确实存在冲突的项目。成功建立基础链路后，再处理 MTU、严格路由和 DNS 策略，能更快定位是哪一项导致连接异常。
基础接管
- 自动路由
- 开启
- 自动检测接口
- 开启
- IPv4 网段
- 172.19.0.1/30
- MTU
- 9000 起测
网段仅为常见自动配置示例；如与公司内网重叠，应换到未占用的私有网段。
DNS 接管
- 远程解析
- 通过代理
- 直连解析
- 本地 DNS
- 查询端口
- 53
- 缓存
- 保持开启
代理域名与直连域名采用对应解析链路，避免解析结果与出站方向不一致。
严格路由
- Strict Route
- 按需开启
- 局域网绕过
- 保留
- 默认接口
- 自动检测
- 回环地址
- 不接管
严格路由可减少旁路流量，但在多网卡、虚拟机或企业网络中需要额外测试。
兼容性调整
- 初始 MTU
- 9000
- 故障测试值
- 1500
- 保守测试值
- 1400
- 修改步长
- 100 至 200
能连接但部分页面长时间加载时，再逐步降低 MTU，不要把它当作首个排查动作。
开启后的确认步骤
- 保存参数并返回主界面，保持一个可用节点处于选中状态。
- 开启 TUN 模式，接受系统权限请求，等待状态栏显示核心运行正常。
- 检查核心日志，应能看到 TUN 接口创建和路由写入信息，不应连续出现 permission denied 或 route add failed。
- 关闭浏览器中的手动代理设置，再访问测试目标，确认请求仍可按规则连通。
- 测试一个明确设为直连的域名和一个设为代理的域名，验证 TUN 接管与路由分流同时生效。
Windows、macOS 与 Linux 的权限差异
TUN 需要操作网络接口和系统路由，普通用户权限通常不足。三个桌面平台的目标一致，但授权方式不同。权限不足时，典型现象是开关自动回落、虚拟网卡未出现，或者日志在创建接口阶段直接报错。
| 平台 | 首次开启要点 | 正常结果 | 常见卡点 |
|---|---|---|---|
| Windows | 确认用户账户控制提示，并允许 v2rayN 以管理员权限完成网卡与路由操作 | 网络适配器中出现 TUN 虚拟接口，路由表增加指向该接口的条目 | 权限提示被取消、旧虚拟网卡残留、其他网络工具占用路由 |
| macOS | 按系统提示输入管理员凭据，允许创建 utun 接口和调整路由 | 系统中出现新的 utun 接口，默认流量按自动路由进入该接口 | 权限请求未完成、后台核心被终止、多条默认路由优先级冲突 |
| Linux | 确保运行用户具备 CAP_NET_ADMIN 能力，或以受控的提升权限启动相关核心 | 出现 tun 接口，并可从路由表看到对应默认路由或策略路由 | /dev/net/tun 不可用、能力未授予、网络管理服务覆盖 DNS |
Windows 的推荐操作顺序
- 完全退出旧版 v2rayN 进程，再启动当前版本，避免两个核心同时监听
10808。 - 先连接节点并测试系统代理，再启用 TUN，出现权限确认时完成授权。
- 若虚拟接口存在但没有流量，打开系统路由信息，检查是否存在指向物理网关的更高优先级默认路由。
- 退出 TUN 后确认虚拟接口和临时路由被清理，再决定是否重新安装或重置相关驱动。
macOS 与 Linux 的额外检查
- macOS 使用多个网络服务时，应确认当前实际出网的是无线网络还是有线网络，自动接口检测结果必须与实际出口一致。
- Linux 桌面环境可能由 NetworkManager 或 systemd-resolved 管理 DNS；TUN 已接管路由但域名失败时，应单独检查解析链路。
- 休眠、切换网络或从有线网络切到无线网络后，原默认接口可能失效。此时关闭再开启 TUN，让客户端重新检测出口。
- 容器和虚拟机网络常使用独立私有网段，若与 TUN 地址重叠，应先修改 TUN 网段，而不是添加更多默认路由。
TUN 开启后路由表发生了什么
直接用一条新的默认路由覆盖原网关，可能让代理核心自身也被送回 TUN，形成循环。实际实现通常会保留物理出口，并把 IPv4 默认空间拆成两个更具体的路由，例如
0.0.0.0/1 与 128.0.0.0/1。因为前缀更长，这两条路由会优先于原来的 0.0.0.0/0，普通应用流量进入 TUN，而核心到远端服务器的连接通过排除规则走真实网关。下面是用于理解结构的简化输出，不代表每台设备都会使用相同接口名和网关。重点是识别“原默认网关仍在”和“更具体的接管路由指向 TUN”这两个特征。
目标网络 网关或接口
0.0.0.0/0 192.168.1.1
0.0.0.0/1 tun0
128.0.0.0/1 tun0
192.168.1.0/24 本地物理网卡
127.0.0.0/8 本地回环DNS 也需要与路由方向配合。若域名先由本地网络解析，但连接随后通过代理出站，可能得到不适合该出口的地址；反过来，全部 DNS 都走代理，又可能让局域网主机名无法解析。更稳妥的做法是让代理域名使用远程解析，让局域网和明确直连的域名使用本地解析，并确保 DNS 查询本身不会绕开既定出站。
TUN 与 Xray 路由分流怎样配合
TUN 解决的是“流量怎样进入客户端”，Xray 路由解决的是“进入之后从哪个出站离开”。把 TUN 当作全代理开关，会忽略分流规则的作用。日常配置至少需要区分代理、直连和阻断三类结果，并把高优先级的特殊规则放在通用规则之前。
例如，局域网地址和设备管理页应先直连；需要代理的域名集合再指向代理出站；广告或明确不需要访问的域名可进入阻断出站；其余流量最后由默认策略兜底。规则按顺序匹配，前面已经命中的连接不会继续执行后面的规则。
TUN 接收流量识别域名地址路由规则匹配选择出站建立连接
建议的规则优先级
- 客户端自身与节点地址：必须通过真实物理出口连接，避免核心连接再次进入 TUN。
- 回环和局域网：
127.0.0.0/8、常用私有地址段及本地设备域名通常设为直连。 - 阻断规则：对明确需要拒绝的域名或协议使用 block 出站，减少无效连接。
- 代理规则：按域名集合、目标地址、端口或协议匹配，并发送到当前代理出站。
- 默认规则：最后决定未命中项目走 direct 还是 proxy，避免出现没有出站结果的连接。
修改规则后，应分别测试域名请求和直接 IP 请求。只有域名失败时，优先检查 DNS 与域名规则；域名和 IP 都失败时，优先检查节点、路由表和权限；只有某个局域网设备无法访问时，则检查私有地址段是否被误送到代理出站。
常见故障与逐项恢复方法
TUN 故障应按“权限与接口、路由、DNS、MTU、分流规则”的顺序处理。一次只改一项，并在每次调整后重新建立连接。若同时更换节点、修改 DNS、降低 MTU和重排规则，即使网络恢复，也无法确定真正原因。
开启 TUN 后立刻全部断网怎么办？
先关闭 TUN 并退出 v2rayN，再重新启用物理网卡。恢复后检查日志中的权限和 route add failed 信息，并确认没有其他虚拟网卡工具同时修改默认路由。
可以访问 IP，但输入域名打不开？
这通常是 DNS 链路问题。进入「设置」→「参数设置」检查 TUN 的 DNS 配置，让代理域名经代理解析，并确认本地的 53 端口没有被其他 DNS 服务独占。
普通网页能开，下载或登录一直卡住？
先把 MTU 从 9000 调到 1500 重试，仍有问题再测试 1400。若调整后恢复，说明当前接入网络或中间链路无法稳定承载较大的封装数据包。
开启后无法访问路由器管理页？
把路由器所在网段加入直连，例如网关为 192.168.1.1 时，将 192.168.1.0/24 指向 direct，并确保局域网绕过选项处于开启状态。
退出客户端后网络仍未恢复？
确认 v2rayN 与核心进程都已结束，然后禁用并重新启用当前物理网卡。若 DNS 仍异常，重新连接网络以获取 DHCP 下发的网关和 DNS，不要保留失效的手动地址。
最小化排错清单
- 系统代理模式下节点是否已经验证可用。
- TUN 虚拟接口是否成功创建，日志是否出现权限错误。
- 原物理默认网关是否保留，接管路由是否指向正确接口。
- 直接访问 IP 与通过域名访问的结果是否不同。
- 局域网、回环地址和节点服务器地址是否被正确排除。
- 将 MTU 调到 1500 后，大文件传输与登录请求是否恢复。
- 关闭 TUN 并退出客户端后，临时路由和 DNS 设置是否撤销。
确认基础链路稳定后，再逐步启用严格路由、细化 DNS 规则或增加分流条件。对于只需要浏览器代理的环境，系统代理通常更便于维护；对于多个不读取代理设置的桌面程序，TUN 配合清晰的 direct、proxy 与 block 规则，才能实现可控的全局流量接管。