tun模式下为什么把本该直接访问的地址给代理了，路由规则不起作用了吗

作者
691 次阅读

本文最后更新于 2026年5月7日。

我按照下面的方法解决了

在设置中的tun设置中把严格路由关闭

修改 TUN 模式的“堆栈（Stack）”设置

在 v2rayN 的 TUN 模式设置中：

  1. 找到 “启用严格路由 (Strict Route)” -> 关闭它。

  2. 将 “Stack” 从 gvisor 改为 System（或者反过来尝试）。System 栈有时能更好地处理本地局域网流量的排除。

然后重启v2rayN，重启很重要。

这是一个非常敏锐的观察。在 TUN 模式下，流量的接管逻辑与普通的“系统代理（HTTP/Socks5）”完全不同，这正是导致你路由规则看似“失效”的原因。

我们可以从以下几个维度来拆解这个技术“黑盒”：

1. 接管层级的不同 (OSI 模型层级)

  • 普通代理模式： 作用于应用层。浏览器等软件会主动询问系统：“代理服务器在哪？”然后把数据包发给 v2rayN。此时，你设置的“排除列表（localhost; 172.18.*）”由操作系统（Windows 网络设置）直接生效。

  • TUN 模式： 作用于网络层（三层）。它创建了一张虚拟网卡，强制接管所有经过 CPU 处理的数据包。

    • 问题所在： 当流量进入 TUN 网卡后，它就脱离了 Windows 系统代理白名单的控制。此时，流量去哪儿，完全由代理内核（xray/sing-box）的内部路由规则决定，而不是 Windows 设置里的那个排除列表。

2. 为什么你的路由规则没起作用？

你在 v2rayN 界面设置的“系统代理设置”里的排除列表，只对 HTTP 代理有效。针对 TUN 模式，你需要调整的是内核路由（Routing）。

如果你的日志里依然出现 outbound/direct -> i/o timeout，说明发生了以下逻辑：

  1. 路由命中了： 内核确实识别到了这是 172.18.0.2，并尝试执行 direct（直连）。

  2. 物理路径被劫持： 在 TUN 模式下，如果你没有配置“路由直连（Bypass）”或者是内核的 stack 设置有问题，直连的数据包发出去后，可能再次被 TUN 网卡自己抓回来。

  3. 无限递归： 请求在虚拟网卡和内核之间反复横跳，根本没能跳出“虚拟环境”进入真正的物理网卡，最终导致 5 秒超时。

3. 如何修正（让路由规则生效）

要解决这个问题，你需要在 v2rayN 的核心路由配置 中做文章，而不是 Windows 的设置里：

A. 在 v2rayN 路由设置中添加私有网段

  1. 进入 设置 -> 路由设置 -> 用户自定义路由。

  2. 点击 添加规则：

    • 代理方案 (Outbound tag): 选择 direct (直连)。

    • IP: 输入 172.18.0.0/16。

  3. 确保这条规则的优先级最高（通常放在列表最上方）。

B. 检查 sing-box 的“严格路由 (Strict Route)”

如果你使用的是 sing-box 内核，它有一个特性叫 strict_route。

  • 如果开启了它，所有的流量都会被强制拉进 TUN，有时会导致本地局域网（LAN）流量无法跳出。

  • 解决： 在 v2rayN 的 TUN 模式设置中，找到 “启用严格路由”，尝试将其关闭。

C. 设置“绕过局域网”

在 v2rayN 主界面底部的“路由”下拉框中，确保你选择的是 “绕过大陆及其它 (202x-xx-xx)” 或者 “绕过局域网及大陆”。这会自动在内核级别下发直连 172.x.x.x 的指令。

4. 为什么会指向 853 端口？

最后解释一下那个 853 端口。在 TUN 模式下，sing-box 等内核通常会开启 DNS 劫持。

它会拦截所有发往 53 端口的请求，并根据自己的 DNS 配置重新转发。如果你的配置里隐式地包含了某个 DoT 服务，或者尝试将 DNS 请求分流到 172.18.0.2，在 TUN 模式的强力控制下，如果分流逻辑不清晰，就会产生你看到的那个报错。

简单总结：

TUN 模式就像一个强力漏斗，把所有水都吸走了。你之前在 Windows 代理设置里打的“补丁”只挡得住小水流，挡不住 TUN 这个大漏斗。你需要在 v2rayN 的路由规则里明确告诉这个漏斗：看到 172.18.* 的流量请直接排出去。

你需要我帮你确认一下你目前的“路由模式”选的是哪一个吗？