在桌面与移动端代理客户端中，“TUN 模式”（TUN Mode）被视为实现全局代理、接管无法配置系统代理解析的应用（如终端 CLI、UWP 应用、游戏客户端）的终极武器。用户只需在客户端界面上轻轻点击开启开关，系统所有的出站流量就会无缝流经代理核心。然而，很多用户并不清楚，在这简单开关的背后，操作系统内核网络协议栈正在经历一场激烈的路由表重构。更为惊险的是，代理客户端在接管“全网所有流量”的同时，必须绝对精准地把自己发出的代理加密流量从接管范围中豁免出去，否则系统会在微秒之内陷入灾难性的“路由回环死锁”。本文将系统解密 TUN 网卡接管默认路由的底层原理与防回环工程方案。
一、TUN 虚拟网卡与操作系统的网络交互模型
要理解 TUN 接管，首先必须理清 TUN（Network TUNnel）在操作系统中的角色定位。
普通的网络适配器（物理网卡）一端连接着操作系统内核网络协议栈，另一端连接着物理介质（网线或 Wi-Fi 射频芯片）。物理网卡在硬件层收发以太网数据帧（二层链路层）。
而 TUN 是一种纯软件实现的“三层（网络层）虚拟网络设备”。它在操作系统内核中注册为一个标准的网络接口（如 Windows 下的 Wintun 驱动，Linux/macOS 下的 tun0）。对于操作系统内核而言，TUN 网卡与普通物理网卡没有任何区别，内核可以像对待真实硬件一样向 TUN 接口分配 IP 地址、配置子网掩码并绑定路由表。
然而，TUN 网卡的另一端并没有任何物理光纤或天线，而是通过一个字符设备文件描述符（File Descriptor）直接连接到了用户态的代理进程（如 Clash 或 sing-box）。当操作系统内核根据路由表将一个纯原生的 IP 数据报（Layer 3 Packet）写入 TUN 设备时，代理进程能够立即通过系统调用将其完整读取到自己的内存缓冲区中；反之，代理进程也可以将处理后的 IP 数据报写回 TUN 设备，由操作系统内核重新送回协议栈完成解包交付。
二、接管默认网关的两大经典技术流派
当代理客户端启动 TUN 模式后，它的首要任务是修改操作系统的全局路由表，确保所有应用程序发出的数据包优先投递给 TUN 接口。业界主要通过两种截然不同的策略实现接管：
第一种流派是“精细化更长前缀匹配”（Longest Prefix Match，俗称 0/1 和 128/1 技巧）。根据 IP 路由选择的基本法则，当数据包的目的 IP 能够匹配路由表中的多条规则时，操作系统会严格优先选用子网掩码最长（即前缀匹配精度最高）的那条路由。基于这一铁律，代理客户端并不需要删除系统原有的默认网关（0.0.0.0/0），而是在路由表中新增两条特殊的超网路由：
0.0.0.0/1指向 TUN 网卡网关128.0.0.0/1指向 TUN 网卡网关 这两条路由巧妙地将全球所有的 IPv4 地址空间（从 0.0.0.0 到 255.255.255.255）均分为两半。由于/1的前缀长度严格大于系统原生默认路由的/0，因此全网所有的互联网流量在路由决策时都会被这两条高精度规则全部截获并引流至 TUN 接口，而完全不需要破坏或修改底层的物理默认路由。当 TUN 模式关闭时，只需将这两条/1路由安全删除，系统网络立刻无损恢复。
第二种流派是“路由跃点（Metric）强制降级”。在 Windows 和特定 Linux 系统中，客户端直接在路由表中添加一条通向 TUN 接口的 0.0.0.0/0 路由，并为其赋予一个极低的跃点数（Metric，例如 1 或 5），同时将物理网卡原有默认路由的 Metric 调大（例如 50 或 100）。根据路由规则，相同前缀下 Metric 越小优先级越高，从而实现全量接管。
三、致命的路由回环与三大防回环解法
当 TUN 网卡成功接管了全网所有的 0.0.0.0/0 流量后，一个致命的死锁逻辑立刻浮出水面：
代理客户端在从 TUN 网卡读取到用户的原始数据包后，必须对数据进行加密封装，并通过物理网卡向海外的代理服务器（例如位于洛杉矶的 VPS，IP 为 203.0.113.50）发送代理流量。然而，此时操作系统的全局路由已被 TUN 全面接管。如果代理客户端发出的这个加密数据包也被路由到了 TUN 网卡中，代理进程就会在 TUN 接口中再次读到自己刚才发出的加密数据包。如此循环往复，数据包在代理程序和 TUN 网卡之间无限死循环，CPU 核心负载瞬间飙升至满载，物理网卡发不出任何有效字节，操作系统网络在瞬间失去响应。这种灾难被称为“代理回环”（Routing Loop）。
为了打破死锁，现代代理内核实现了极其精密的防回环架构：
第一种解法是“目的代理服务器静态主机路由”。在启动 TUN 之前，代理客户端首先解析出海外代理节点的公网 IP 地址（例如 203.0.113.50）。随后在系统路由表中添加一条精准的 /32 主机路由（如 203.0.113.50/32），将其下一跳显式绑定为物理网卡的真实默认网关。由于 /32 拥有全网最高的匹配精度，代理客户端发往该节点的所有加密流量会完美绕过 TUN 接口，直接从物理网卡出站。
第二种解法是基于“套接字标记与策略路由”（SO_MARK / Fwmark，Linux/Android 核心机制）。代理进程在创建与海外节点通信的原始 Socket 套接字时，通过系统调用为该套接字打上一个特殊的十六进制标记（例如 0xff）。在 Linux 内核策略路由规则（ip rule）中配置：所有带有该标记的数据包，强制走专用的直连物理路由表，而忽略 TUN 路由表。
第三种解法是“进程白名单豁免”（Windows Wintun 核心机制）。利用 Windows 内核提供的过滤驱动或自研虚拟网卡技术，驱动层能够识别发起网络连接的具体系统进程 PID。只要检测到数据包是由代理客户端自身的二进制主程序生成，驱动层直接予以放行，绝不将其重定向至 TUN 虚拟队列中。
四、日常使用中的 TUN 冲突与故障自查
在配置 TUN 模式时，如果遇到网络异常中断或 DNS 解析失败，建议按以下步骤排查：
第一步是检查路由表是否存在悬空路由。在终端运行 route print（Windows）或 ip route show（Linux），确认是否存在多条指向失效网关的 0.0.0.0/0 路由。如果客户端非正常退出，残留的 TUN 路由往往会导致网络断开，需要手动清理或重启网络适配器。
第二步是结合 Fake-IP与Redir-Host模式全方位深度对比 与 彻底排查与消除DNS泄漏：从系统解析器到WebRTC的完整加固，确认 TUN 模式下的 DNS 劫持是否生效。TUN 模式必须配合严格的本地 DNS 劫持（Strict Route），确保 53 端口的所有流量绝对不会泄露至物理接口。
第三步是排查与第三方 VPN 软件的权限争夺。如果系统中同时安装了多个虚拟网卡驱动（如企业办公 VPN 客户端与个人代理客户端同时开启 TUN），两者会针对默认网关的 Metric 展开剧烈竞争，导致不可预知的断流，此时应参考场景指南关闭冲突驱动，维持单一虚拟网关控制权。