TUN/TAP 虚拟网卡
百科词条 · VPS 术语 · 亦称 TUN 模式 / TUN / TAP / 虚拟网络设备 / Wintun
TUN 与 TAP 是操作系统内核提供的用户空间虚拟网络接口驱动：TUN 工作在网络层（L3，处理纯原始 IP 数据包），TAP 工作在数据链路层（L2，处理带 MAC 头的以太网帧）；代理客户端通过创建 TUN 虚拟网卡（Linux tun0、macOS utun、Windows Wintun）并接管系统路由表，结合用户态网络协议栈（如 gVisor、lwIP）实现全机全局流量的透明拦截与分流。
TUN（L3）与 TAP（L2）的内核机制差异
Linux 内核驱动官方文档（tuntap.rst）明确划分了两种虚拟模式：TAP 对应标志 IFF_TAP，模拟真实以太网适配器，收发完整的第二层数据链路层帧（包含源/目的 MAC 地址与 VLAN 标签），广泛用于 KVM/QEMU 虚拟机桥接与容器局域网组网；TUN 对应标志 IFF_TUN，是点对点的第三层网络层设备，直接收发原始 IPv4/IPv6 数据包，没有以太网帧报头开销，是 VPN 隧道与透明代理的首选形态。
查看来源跨平台驱动实现：Linux、macOS 与 Windows Wintun
在类 Unix 系统中，程序通过打开字符设备 /dev/net/tun 并调用 ioctl(TUNSETIFF) 实例化虚拟网卡；macOS 提供了原生内核级 utun 接口；而在 Windows 平台上，早期 OpenVPN 依赖较重且老旧的 TAP-Windows NDIS 驱动，现代代理与 WireGuard 普遍迁移至专为高性能 L3 设计的 Wintun 驱动，大幅减少内存拷贝与中断上下文开销。
查看来源用户态协议栈（gVisor 与 lwIP）的核心角色
当 TUN 设备从系统网络栈接收到原始 IP 数据包后，用户空间代理软件无法直接当成标准 Socket 读取。为此，Clash.Meta/Mihomo、sing-box 等现代客户端深度集成了用户态协议栈（如 Google gVisor 的 Netstack 模块或 lwIP），在用户进程中重新实现 TCP 握手重组、窗口滑动与 UDP 状态表，将原始 IP 包优雅转换为可被代理分流引擎识别的 Socket 流。
系统路由表接管与全局流量拦截
传统 HTTP/Socks5 代理仅对遵循系统环境变量或主动配置代理的应用生效，对终端命令、游戏客户端及自建网络工具往往失效。TUN 模式通过动态改写操作系统路由表（如将默认网关 0.0.0.0/0 绑定至 TUN 虚拟接口，或利用 Linux policy routing 与 fwmark），无死角强制捕获全机所有出站流量，杜绝非代理软件的公网直连泄露。
容器与 VPS 虚拟化环境配置规范
在 Docker 容器或 LXC 虚拟化中运行依赖 TUN 的代理核心（如 WireGuard、Tailscale、Sing-box）时，容器默认因安全隔离被禁止直接访问内核设备节点。必须在启动时授予 --cap-add=NET_ADMIN 权限，并将宿主机 /dev/net/tun 设备挂载进容器内部，否则会导致驱动打开失败并报出「operation not permitted」错误。