外观
TUN 模式是什么、要不要开
TUN 模式 = 客户端创建一个虚拟网卡，接管系统的全部流量。
它解决的是一个具体问题：有些程序不读系统代理设置。
两种模式的区别
| 系统代理模式 | TUN 模式 | |
|---|---|---|
| 工作方式 | 设置系统的 HTTP / SOCKS 代理 | 创建虚拟网卡 + 改路由表 |
| 覆盖范围 | 只覆盖遵守系统代理设置的程序 | 全部程序 |
| 浏览器 | 覆盖 | 覆盖 |
| 游戏客户端 | 多数不覆盖 | 覆盖 |
| 桌面应用 | 部分不覆盖 | 覆盖 |
| 命令行工具 | 多数不覆盖 | 覆盖 |
| 非 TCP 流量 | 支持有限 | 支持更好 |
| 需要的权限 | 普通用户 | 管理员 / root |
| 配错的影响 | 浏览器上不了网 | 整个系统可能断网 |
| 配置复杂度 | 低 | 较高 |
| 速度 | 相同 | 相同 |
关键：TUN 改变的是覆盖范围，不是传输质量。 开 TUN 不会让速度变快——速度由线路类型、节点带宽、地区距离决定。
什么时候需要 TUN
需要的情况
| 情况 | 举例 |
|---|---|
| 游戏客户端 | 多数游戏不读系统代理 |
| 命令行工具 | 包管理器、代码仓库工具、下载工具 |
| 部分桌面应用 | 某些应用有自己的网络栈 |
| 需要覆盖 UDP 流量 | 部分游戏与实时应用 |
| 需要覆盖整个系统 | 不想逐个程序配置 |
不需要的情况
| 情况 | 为什么 |
|---|---|
| 需求都在浏览器里（网页、流媒体、AI） | 系统代理就够，更简单、风险更低 |
| 只用少数几个支持代理的程序 | 单独配这几个 |
| 设备性能较弱 | TUN 的处理开销略高 |
| 你还在调试规则 | 先在系统代理模式下调好再切 TUN |
本页最实用的一条建议：如果系统代理模式能满足你，就不要开 TUN。 它的额外能力只在特定场景下需要，而配错的代价更大。
怎么判断某个程序需不需要 TUN
| 步骤 | 操作 |
|---|---|
| 1 | 只开系统代理模式 |
| 2 | 打开那个程序，看它能不能正常访问境外服务 |
| 3 | 能 → 它遵守系统代理，不需要 TUN |
| 4 | 不能 → 看客户端的连接日志里有没有它的请求 |
| 5 | 日志里没有它的请求 → 它绕过了代理，需要 TUN |
| 6 | 日志里有但失败 → 是节点或规则问题，不是模式问题 |
第 5 步和第 6 步的区分很重要：前者需要开 TUN，后者开 TUN 也解决不了。
开 TUN 前必须配好的三条规则
TUN 接管全部流量，所以这三条不配会立刻出问题。
一、局域网 IP 段直连
| 网段 | 用途 |
|---|---|
192.168.0.0/16 | 最常见的家用网段 |
10.0.0.0/8 | 企业与部分家用 |
172.16.0.0/12 | 部分网络 |
127.0.0.0/8 | 本机回环 |
169.254.0.0/16 | 链路本地 |
不配这条的表现：
| 症状 | 原因 |
|---|---|
| 路由器管理界面打不开 | 访问 192.168.1.1 被送进了代理 |
| 局域网 NAS / 打印机访问不了 | 同上 |
| 本机服务（开发环境）访问不了 | 127.0.0.1 被拦 |
| 局域网投屏失败 | 同上 |
这是 TUN 模式下最常见的第一个问题。 多数客户端的默认配置已包含，但自定义配置时容易漏。
二、国内域名与 IP 直连
系统代理模式下这条已经重要；TUN 模式下它更重要，因为 TUN 会捕获所有程序的国内访问——包括那些原本绕过代理、反而正常工作的程序。
不配这条的表现：
| 症状 |
|---|
| 国内网站全面变慢 |
| 国内 App 提示异常 |
| 智能家居设备离线 |
| 流量消耗剧增 |
智能家居这一项在路由器上跑 TUN 时尤其明显——摄像头、音箱、扫地机只连国内服务器，走代理会让它们离线。建议按设备 IP 段直连。
三、客户端自身的流量排除
如果客户端更新订阅的请求也经过自己创建的虚拟网卡，而节点又依赖订阅——节点全部失效时你无法恢复。
| 要排除的 | 说明 |
|---|---|
| 订阅域名 | 设为直连或指定一个固定可用的出口 |
| 客户端的更新检查 | 同上 |
| 规则集的更新源 | 同上 |
多数客户端会自动处理自身流量，但订阅域名通常需要你自己加规则。
fake-ip：让域名规则在 TUN 下生效
问题是什么
域名规则需要知道域名。 但在 TUN 模式下：
程序先用本地 DNS 把 example.com 解析成 93.184.x.x
程序发起到 93.184.x.x 的连接
客户端只看到一个 IP，不知道这是 example.com
→ 你写的 "example.com → 新加坡节点" 规则不会命中fake-ip 怎么解决
程序请求解析 example.com
客户端返回一个假 IP（比如 198.18.0.5）
程序发起到 198.18.0.5 的连接
客户端识别出这是自己分配的假 IP，查到它对应 example.com
→ 域名规则正常命中fake-ip 让客户端在连接建立时仍然知道域名，这是 TUN 模式下域名规则能工作的前提。
配置要点
| 项目 | 说明 |
|---|---|
| fake-ip 网段 | 用一个不与真实网络冲突的段（常见 198.18.0.0/16） |
| 排除列表 | 某些域名不适合 fake-ip（本地服务发现、部分需要真实 IP 的协议） |
| 国内域名 | 通常用国内 DNS 真实解析，不走 fake-ip |
| 与规则的配合 | 域名规则要在 IP 规则之前 |
多数机场提供的 Clash / sing-box 配置已包含合理的 fake-ip 设置。 除非遇到具体问题，不建议自己改。
不开 fake-ip 的替代方案
部分客户端支持"嗅探"（sniffing）：从连接的握手数据里提取域名。
| fake-ip | 嗅探 | |
|---|---|---|
| 原理 | 返回假 IP 保留域名映射 | 从 TLS / HTTP 握手里读域名 |
| 对加密流量 | 有效 | 依赖握手里的明文域名字段 |
| 兼容性问题 | 部分协议不适应假 IP | 较少 |
| 常见程度 | 更常见 | 增长中 |
两者可以同时用。 具体配置以客户端文档为准。
详见 DNS 设置。
各平台的实现差异
| 平台 | 实现方式 | 特点 |
|---|---|---|
| Windows | 虚拟网卡驱动 | 需要管理员权限；部分安全软件会拦截 |
| macOS | 系统的 utun 接口 | 需要授权；较稳定 |
| Linux | TUN/TAP 设备 | 需要 root 或相应权能 |
| Android | 系统 VPN 服务接口 | 需要用户授权；与系统 VPN 互斥 |
| iOS | 网络扩展机制 | 权限受限最多；某些配置不适用 |
| 路由器 | 视固件 | 覆盖全家设备；配错影响最大 |
三个平台特有的注意
Windows：安全软件冲突。 部分安全软件会把虚拟网卡驱动视为可疑。如果开 TUN 后完全没有网络，检查安全软件的拦截记录。
Android / iOS：与系统 VPN 互斥。 系统同时只允许一个 VPN 类应用工作。如果你有公司的 VPN，两者不能同时开。
路由器：配错影响全家。 建议先在一台电脑上把规则调好验证，再搬到路由器。并且确保路由器管理界面有密码——订阅链接会保存在路由器上。
配错的表现与排查
| 症状 | 最可能的原因 | 怎么修 |
|---|---|---|
| 完全没有网络 | 路由表被改坏，或安全软件拦截 | 关闭 TUN 恢复，检查安全软件 |
| 路由器管理界面打不开 | 缺少局域网直连规则 | 加局域网 IP 段直连 |
| 本机服务（localhost）访问不了 | 缺少 127.0.0.0/8 直连 | 加回环直连 |
| 国内网站全面变慢 | 缺少国内域名 / IP 直连 | 加国内规则集 |
| 域名规则不生效 | 未启用 fake-ip 或嗅探 | 启用 fake-ip |
| 订阅无法更新 | 订阅域名走了失效节点 | 把订阅域名设为直连 |
| 智能家居设备离线 | 它们的流量走了代理 | 按设备 IP 段直连 |
| 公司 VPN 不能同时用 | 移动端系统限制 | 只能二选一 |
| 游戏还是不走代理 | TUN 未真正生效，或规则未命中 | 看日志确认 |
| 速度没变快 | TUN 不影响速度 | 这是预期行为 |
| 设备发热 / 耗电增加 | TUN 的处理开销 | 不需要时关闭 |
排查的通用顺序
开了 TUN 出问题了：
1. 完全没网？
→ 立刻关闭 TUN，确认恢复
→ 恢复了说明是 TUN 配置问题，继续
→ 没恢复说明是别的问题（本地网络、客户端）
2. 局域网访问不了？
→ 加局域网 IP 段 + 127.0.0.0/8 直连
3. 国内访问变慢？
→ 检查国内域名集合与国内 IP 段规则是否存在、是否在兜底之前
4. 域名规则不生效？
→ 检查 fake-ip 是否启用
→ 看日志里请求显示的是域名还是 IP
5. 订阅不能更新？
→ 把订阅域名设为直连
6. 某个程序还是绕过？
→ 看日志里有没有它的请求
→ 完全没有 → TUN 可能未真正接管（权限问题？）
→ 有但失败 → 是规则或节点问题第 1 步的"立刻关闭 TUN"很重要。 不要在断网状态下反复尝试修配置——先恢复网络，再慢慢改。
要不要开：决策流程
我该开 TUN 吗？
1. 我的需求都在浏览器里吗？（网页、流媒体、AI）
是 → **不要开**，系统代理模式够用且更安全
否 → 继续
2. 具体是哪个程序不走代理？
先在系统代理模式下测：看客户端日志里有没有它的请求
日志里有 → 不是模式问题，是规则或节点问题，**不用开 TUN**
日志里完全没有 → 它绕过了代理，继续
3. 这个程序有没有自己的代理设置？
有 → 单独给它配代理，比开 TUN 影响面小
没有 → 继续
4. 三条必备规则配好了吗？
局域网 IP 段直连？国内域名 + IP 直连？订阅域名直连？
没配好 → **先配好再开**
配好了 → 继续
5. fake-ip 启用了吗？
没有 → 启用，否则域名规则可能不生效
有 → 可以开 TUN
6. 开了以后逐项验证
路由器界面能打开？国内网站正常？订阅能更新？
目标程序走了代理？
7. 不需要时关闭
TUN 有处理开销，也增加配错的风险面TUN 模式的工作原理
理解原理能让排查更有方向。这一节可以跳过，但遇到奇怪问题时值得回来看。
流量是怎么被接管的
1. 客户端创建一个虚拟网卡（TUN 设备）
2. 客户端修改系统路由表，把默认路由指向这个虚拟网卡
3. 系统里任何程序发出的流量都被送到虚拟网卡
4. 客户端从虚拟网卡读取原始 IP 数据包
5. 客户端按规则决定：直连、走某个节点、还是拦截
6. 走节点的流量被封装进代理协议发出
7. 直连的流量从真实网卡发出第 2 步是关键，也是风险来源。 修改路由表意味着影响整个系统的网络。配置错误（比如把本该直连的流量也送进虚拟网卡，而虚拟网卡又没有可用节点）会导致全面断网。
第 7 步解释了为什么必须配国内直连规则：走"直连"的流量会从真实网卡发出，路径与不开 TUN 时相同。所以只要规则写对，国内访问不会有任何损失。
为什么会有域名信息丢失的问题
系统代理模式：
浏览器 → "我要连 example.com:443" → 客户端（看到域名）
TUN 模式：
程序 → 本地 DNS 解析 example.com → 93.184.x.x
程序 → 发送到 93.184.x.x 的 IP 包 → 虚拟网卡 → 客户端（只看到 IP）系统代理模式下客户端收到的是"连接到某域名"的请求；TUN 模式下收到的是原始 IP 数据包。 IP 数据包里没有域名。
fake-ip 的做法是在 DNS 环节介入：客户端自己充当 DNS 服务器，对境外域名返回一个自己保留的假 IP，并记住"这个假 IP 对应哪个域名"。程序连接假 IP 时，客户端查表就知道域名了。
嗅探的做法是在连接建立时读握手数据：TLS 握手的 SNI 字段、HTTP 请求的 Host 头里通常包含域名。
两者可以同时启用，互为补充。
为什么开 TUN 不会更快
| 影响速度的因素 | 与 TUN 的关系 |
|---|---|
| 线路类型（专线 / 中转 / 直连） | 无关 |
| 节点的落地出口带宽 | 无关 |
| 地区物理距离 | 无关 |
| 节点超卖程度 | 无关 |
| 协议与加密开销 | 无关（两种模式都要加密） |
| 本地处理开销 | TUN 略高（要处理原始 IP 包） |
唯一的差别是本地处理开销，而且 TUN 略高。 所以"开 TUN 提速"是误解——如果你观察到开 TUN 后变快了，更可能的原因是某些流量之前绕过了代理走了慢的直连路径，现在走了节点。
为什么 TUN 能处理游戏与 UDP
| 流量类型 | 系统代理模式 | TUN 模式 |
|---|---|---|
| HTTP / HTTPS（遵守代理设置的程序） | 覆盖 | 覆盖 |
| TCP（不读代理设置的程序） | 不覆盖 | 覆盖 |
| UDP | 支持有限（SOCKS5 的 UDP 转发需要程序支持） | 覆盖 |
| ICMP（ping） | 不覆盖 | 部分客户端支持 |
游戏大量使用 UDP（对局数据、语音），而且游戏客户端多数不读系统代理设置。这两点合起来就是游戏需要 TUN 的原因。
注意：TUN 覆盖了 UDP，但节点端是否转发 UDP 是另一回事。 如果节点不支持 UDP 转发，开 TUN 也解决不了游戏的 NAT 问题。见 节点怎么选。
按平台的具体配置步骤
逻辑一致：开启前配好三条规则、启用 fake-ip、开启后逐项验证。下面是各平台的路径与注意点。
Windows
| 步骤 | 操作 |
|---|---|
| 1 | 确认客户端以管理员权限运行（多数客户端会在开启 TUN 时请求提权） |
| 2 | 在客户端设置里找到「TUN 模式」开关 |
| 3 | 首次开启会安装虚拟网卡驱动，需要授权 |
| 4 | 开启后检查系统的网络适配器列表，应出现一个新的虚拟网卡 |
| 5 | 逐项验证（见下文验证清单） |
注意：
| 问题 | 说明 |
|---|---|
| 安全软件拦截 | 部分安全软件会把虚拟网卡驱动视为可疑，需要放行 |
| 开启后完全没网 | 先关闭 TUN 恢复，再检查安全软件的拦截记录 |
| 与其他 VPN 客户端冲突 | 同时运行多个接管流量的程序会导致路由混乱 |
| 关闭客户端时虚拟网卡残留 | 正常退出客户端，异常退出可能留下网卡，重启系统可清理 |
macOS
| 步骤 | 操作 |
|---|---|
| 1 | 客户端会请求安装辅助工具或系统扩展，需要输入密码授权 |
| 2 | 在设置里开启「TUN 模式」 |
| 3 | 首次可能需要在系统设置里允许该扩展 |
| 4 | 开启后 ifconfig 应能看到新的 utun 接口 |
| 5 | 逐项验证 |
注意： macOS 的系统更新后可能需要重新授权扩展。如果更新系统后 TUN 突然不工作，先检查授权状态。
Linux
| 步骤 | 操作 |
|---|---|
| 1 | 确认内核支持 TUN/TAP（绝大多数发行版默认支持） |
| 2 | 客户端需要 root 权限，或赋予相应的网络权能 |
| 3 | 开启后检查路由表 |
| 4 | 注意与系统已有的网络管理工具的冲突 |
注意： Linux 上手动配置的余地最大，但也最容易与系统的网络管理服务冲突。建议先了解自己发行版的网络管理方式。
Android
| 步骤 | 操作 |
|---|---|
| 1 | 客户端会请求 VPN 权限，系统弹窗授权 |
| 2 | 授权后状态栏出现 VPN 图标 |
| 3 | 逐项验证 |
注意：
| 问题 | 说明 |
|---|---|
| 与系统 VPN 互斥 | 系统同时只允许一个 VPN 类应用工作 |
| 电池优化可能杀掉后台 | 把客户端加入电池优化白名单 |
| 部分系统的省电策略更激进 | 可能导致连接中断 |
| 分应用代理 | Android 客户端通常支持按应用选择是否走代理，比全局 TUN 更精细 |
"分应用代理"值得单独说：Android 上你可以指定哪些应用走 TUN、哪些绕过。这比在规则里按域名配更直接，尤其适合"只想让某几个应用走代理"的场景。
iOS
| 步骤 | 操作 |
|---|---|
| 1 | 客户端（如 Shadowrocket、sing-box）会请求添加 VPN 配置 |
| 2 | 系统弹窗授权 |
| 3 | 在客户端里开启连接 |
| 4 | 逐项验证 |
注意：
| 限制 | 说明 |
|---|---|
| 权限受限最多 | 某些桌面端可用的配置在 iOS 上不适用 |
| 与系统 VPN 互斥 | 同上 |
| 后台运行受系统管理 | 长时间后台可能被回收 |
| 无法自行安装驱动 | 全部通过系统的网络扩展机制 |
iOS 上 TUN 与系统代理的区分不像桌面端那么明显——客户端通常就是以 VPN 形式工作的，所以"要不要开 TUN"这个问题在 iOS 上基本不存在（开启连接就是 TUN）。iOS 用户更需要关注的是规则配置，而不是模式选择。
路由器
在路由器上跑 TUN 能覆盖全家设备，但配错的影响最大。
| 步骤 | 操作 |
|---|---|
| 1 | 先在一台电脑上把规则调好并完整验证 |
| 2 | 确认路由器固件支持相应客户端 |
| 3 | 确认路由器性能足够（加密解密对 CPU 要求高） |
| 4 | 搬入配置，特别检查国内域名 / IP 直连与局域网直连 |
| 5 | 额外加一条：智能家居设备按 IP 段直连 |
| 6 | 确认路由器管理界面有强密码 |
第 5 条和第 6 条是路由器特有的：
智能家居设备（摄像头、音箱、扫地机）只连国内服务器，走代理会让它们离线或异常。按设备 IP 段直连比逐个找域名可靠。
管理界面密码：订阅链接会保存在路由器上。管理界面没有密码或用默认密码时，局域网内任何人都能看到你的订阅链接——而订阅链接等同于账号密码。见 订阅链接安全。
开启后的验证清单
不要假设配好了。逐项确认。
| 检查 | 怎么做 | 期望 |
|---|---|---|
| 路由器管理界面 | 浏览器打开 192.168.x.1 | 能打开 |
| 本机服务 | 访问 127.0.0.1 上的服务 | 能访问 |
| 局域网设备 | 访问 NAS / 打印机 | 能访问 |
| 国内网站 | 打开国内大站，看客户端日志 | 显示 DIRECT |
| 域名规则生效 | 打开 AI 服务，看日志 | 显示指定节点，且日志里是域名而非 IP |
| 订阅能更新 | 手动更新订阅 | 成功 |
| 目标程序走代理 | 打开那个程序，看日志 | 日志里出现它的请求 |
| 智能家居（路由器场景） | 检查设备在线状态 | 全部在线 |
| 整体网络正常 | 正常使用十分钟 | 无异常 |
前三项是 TUN 特有的必查项（系统代理模式下不会出问题）。第四、五项是规则的通用必查项。
常见误判
- TUN 模式更快。 不会，它只改变覆盖范围。
- 开了 TUN 就不用配规则了。 恰恰相反，TUN 下规则更重要，因为它接管全部流量。
- TUN 就是 VPN。 实现类似，但 TUN 模式下你保留完整的规则分流能力。
- 域名规则在 TUN 下自然生效。 需要 fake-ip 或嗅探。
- 局域网访问不受影响。 会受影响，必须加直连规则。
- 所有平台的 TUN 一样。 iOS 的权限限制最多。
- 开着不关没坏处。 有处理开销，也扩大了配错的影响面。
- 游戏开 TUN 就能降延迟。 延迟由地区与线路决定，与模式无关。
TUN 的替代方案
在开 TUN 之前，先看看有没有影响面更小的做法。
方案一：给那个程序单独配代理
很多程序有自己的代理设置，比起接管全系统，单独配它影响面小得多。
| 程序类型 | 常见的代理配置方式 |
|---|---|
| 命令行工具 | 环境变量（http_proxy / https_proxy / all_proxy） |
| 包管理器 | 自身的配置文件里有代理项 |
| 代码仓库工具 | 全局或按仓库的代理配置 |
| 下载工具 | 设置里通常有代理选项 |
| 部分桌面应用 | 设置里有网络 / 代理选项 |
优先试这个。 如果只是一两个命令行工具需要代理，设个环境变量比开 TUN 简单得多，也不会影响别的东西。
方案二：Android 的分应用代理
Android 客户端通常支持指定哪些应用走代理、哪些绕过。
| 优势 | 说明 |
|---|---|
| 精确 | 按应用而不是按域名 |
| 影响面小 | 不走代理的应用完全不受影响 |
| 配置简单 | 勾选列表，不用写规则 |
对"只想让某几个应用走代理"的需求，这比全局 TUN 加规则更直接。
方案三：只在需要时临时开启
| 做法 | 适合 |
|---|---|
| 平时用系统代理模式，玩游戏时才开 TUN | 游戏是唯一需要 TUN 的场景 |
| 用完就关 | 减少处理开销与配错风险面 |
多数客户端切换模式只需要一个开关。 没必要一直开着。
方案四：在路由器上跑（针对多设备）
如果你的需求是"让家里的电视、游戏机、智能设备都能走代理"，在路由器上配比在每台设备上配 TUN 更合理。
| 优势 | 代价 |
|---|---|
| 覆盖全部设备 | 配错影响全家 |
| 只占一个设备数 | 需要路由器性能足够 |
| 设备端零配置 | 排查更复杂 |
但要特别注意智能家居设备——它们只连国内服务器，必须按 IP 段直连。
四个方案的对比
| 方案 | 影响面 | 配置成本 | 适合 |
|---|---|---|---|
| 程序单独配代理 | 最小 | 低 | 一两个程序需要 |
| Android 分应用代理 | 小 | 最低 | Android 上的少数应用 |
| 临时开 TUN | 中 | 低 | 游戏等特定场景 |
| 常开 TUN | 最大 | 中 | 大量程序都需要 |
| 路由器 | 最大（全家） | 最高 | 多设备、非电脑设备 |
本站的建议顺序：程序单独配 → 分应用代理 → 临时开 TUN → 常开 TUN → 路由器。 从影响面最小的开始试。
安全与隐私的注意事项
TUN 模式接管全部流量，所以有几个额外的注意点。
客户端的可信度更重要
系统代理模式下，只有配置了代理的程序的流量经过客户端；TUN 模式下，系统里所有程序的流量都经过客户端。
| 风险 | 说明 |
|---|---|
| 来源不明的客户端 | 它能看到你的全部网络流量 |
| 第三方打包版 | 可能被植入后门 |
| 搜索引擎广告位下载的安装包 | 可能是仿冒 |
只从项目的官方仓库或官方渠道下载客户端。 这在系统代理模式下就重要，在 TUN 模式下更重要。
订阅链接的保存位置
客户端会保存你的订阅链接。TUN 模式常在路由器上使用，而路由器的管理界面往往缺乏保护。
| 检查 | 说明 |
|---|---|
| 路由器管理界面有强密码 | 否则局域网内任何人都能看到订阅链接 |
| 不使用默认密码 | 默认密码等于没有密码 |
| 管理界面不对公网开放 | 避免外部访问 |
订阅链接等同于账号密码。 见 订阅链接安全。
意外的流量走向
TUN 接管全部流量后，一些你没想到的流量也会走代理：
| 流量 | 后果 |
|---|---|
| 系统自动更新 | 消耗套餐流量（可能很大） |
| 云同步 / 备份 | 同上 |
| 应用商店下载 | 同上，且可能变慢 |
| 遥测与诊断数据 | 消耗流量 |
| 智能家居设备（路由器场景） | 设备可能离线 |
应对：把这些明确设为直连。 系统更新、云同步、应用商店的域名走直连既省流量又更快（它们通常有国内 CDN）。
这也是"开了 TUN 后流量消耗剧增"的常见原因——不是节点有问题，是原本不走代理的大流量现在走了。
一个实用的流量自查
开 TUN 后的前两天，留意流量消耗：
| 观察 | 结论 |
|---|---|
| 消耗与之前接近 | 规则配得对 |
| 消耗明显增加 | 有本该直连的流量走了代理 |
| 消耗剧增 | 检查系统更新、云同步、国内域名规则 |
看客户端的连接日志按流量排序（部分客户端支持），能直接看出哪些域名消耗最多。消耗榜前几名如果是国内域名或系统更新域名，就知道该加什么规则了。
名词速查
| 名词 | 含义 |
|---|---|
| TUN | 虚拟网卡设备，客户端用它接管系统流量 |
| 系统代理 | 设置系统的 HTTP / SOCKS 代理，只覆盖遵守设置的程序 |
| fake-ip | 返回假 IP 以保留域名映射，让域名规则在 TUN 下生效 |
| 嗅探 / sniffing | 从连接握手里提取域名，fake-ip 的替代 / 补充 |
| 路由表 | 系统决定流量走哪个网卡的表，TUN 会修改它 |
| 回环 / localhost | 127.0.0.0/8，本机服务 |
| 局域网 IP 段 | 192.168.*、10.*、172.16-31.* |
| 网络扩展 | iOS 上实现 TUN 的系统机制 |
| DNS 泄露 | 域名解析请求走了本地 DNS |
出问题时的应急步骤
TUN 配错最坏的情况是整个系统断网。先恢复，再排查。
| 顺序 | 操作 | 说明 |
|---|---|---|
| 1 | 关闭 TUN 模式 | 多数客户端在界面上有开关 |
| 2 | 如果客户端界面也打不开 | 直接退出客户端进程 |
| 3 | 如果退出后仍然没网 | 检查系统的网络适配器，禁用残留的虚拟网卡 |
| 4 | 仍然没网 | 重启系统，路由表会重置 |
| 5 | 恢复后再改配置 | 不要在断网状态下反复试 |
| 6 | 改完先在系统代理模式验证 | 确认规则正确后再开 TUN |
第 5 条最重要。 在断网状态下改配置，你无法更新订阅、无法查文档、无法验证——排查效率极低。先恢复网络是第一优先。
路由器场景的应急：如果在路由器上配错导致全家断网，通常需要通过有线直连路由器的管理口（或按重置键恢复出厂）。所以在路由器上改配置前一定要知道怎么恢复。
本页数据说明
| 内容 | 层级 | 含义 |
|---|---|---|
| TUN 原理、与系统代理的区别、各平台差异 | 一般性技术参考 | 非针对具体品牌 |
| 必备规则与配置建议 | editorial | 本站方法建议 |
| 具体配置语法 | — | 以各客户端文档为准 |
本页不提供任何规避服务方检测的方法。使用任何网络服务都应遵守所在地的法律法规与服务方的使用条款。规则见 免责声明。
一句话总结
TUN 模式让客户端创建虚拟网卡、接管系统全部流量，解决的是"有些程序不读系统代理设置"（游戏、命令行工具、部分桌面应用）。它改变覆盖范围，不改变速度——开 TUN 不会更快。如果你的需求都在浏览器里，不要开：系统代理模式更简单、风险更低，而 TUN 配错会让整个系统断网。开之前必须配好三条规则：局域网 IP 段直连（否则路由器管理界面都打不开）、国内域名与 IP 直连（否则国内访问全面变慢）、订阅域名直连（否则节点全失效时无法恢复）。还必须启用 fake-ip 或嗅探，否则程序自行解析后客户端只看到 IP，你的域名规则不会命中。出问题时第一个动作是关闭 TUN 恢复网络，再改配置。
给不同用户的建议
只用浏览器（网页 + AI + 流媒体）：不要开 TUN。 系统代理模式完全够用，更简单、风险更低。把精力放在规则配置上（尤其是 AI 域名指向验证通过的节点）。
远程工作 / 会议为主：通常不需要 TUN——主流会议应用都遵守系统代理设置。先在系统代理模式下测，看客户端日志里有没有会议应用的请求。有就不用开。
游戏玩家：需要 TUN（游戏客户端多数不读系统代理，且大量使用 UDP）。但建议临时开启——玩的时候开、平时关。同时注意：TUN 覆盖 UDP，但节点端是否转发 UDP 是另一回事，不支持 UDP 的节点开 TUN 也解决不了 NAT 问题。
开发者 / 命令行用户：先试环境变量（http_proxy / https_proxy / all_proxy），这比开 TUN 影响面小得多。只有当某个工具不读环境变量时才考虑 TUN。
Android 用户：优先用分应用代理，比全局 TUN 加规则更直接。注意电池优化会杀后台，把客户端加入白名单。
iOS 用户：客户端本身就是以 VPN 形式工作的，"要不要开 TUN"这个问题基本不存在。精力放在规则配置上。
多设备 / 全家用：在路由器上跑比每台设备配 TUN 合理。但必须先在一台电脑上完整验证规则，并特别处理智能家居设备（按 IP 段直连）与路由器管理界面的密码。
还在调试规则的人：先在系统代理模式下把规则调好并验证，再切到 TUN。在 TUN 模式下调规则，配错时可能整个系统断网，排查更困难。
下一步
- 配规则 → 规则分流
- DNS 相关问题 → DNS 设置
- 选节点 → 节点怎么选
- 客户端具体操作 → Clash Verge Rev · sing-box · Shadowrocket
- 连不上 → 超时与连接失败
- 速度慢 → 速度慢怎么排查
相关页面
- 教程：规则分流 · DNS 设置 · 节点怎么选 · 教程中心
- 客户端：客户端总览 · Clash Verge Rev · v2rayN · v2rayNG · sing-box · Shadowrocket
常见问题
TUN 模式是什么？
客户端创建一个虚拟网卡并接管系统的全部流量。与系统代理模式的区别是覆盖范围：系统代理只覆盖遵守代理设置的程序，TUN 覆盖所有程序，包括游戏、桌面应用、命令行工具。
我需要开 TUN 吗？
如果你的需求都在浏览器里（网页、流媒体、AI），系统代理模式就够，而且更简单、风险更低。只有当某个程序不读系统代理设置时才需要 TUN。
开 TUN 需要什么权限？
需要管理员或 root 权限来创建虚拟网卡与修改路由表。这也是 TUN 配错时影响更大的原因——它影响整个系统的网络，不只是浏览器。
开了 TUN 以后域名规则不生效了？
因为程序可能已经自己把域名解析成了 IP，客户端只看到 IP，域名规则不会命中。解决方式是启用 fake-ip（或等效机制），让域名规则在 TUN 模式下仍然有效。
开了 TUN 以后路由器管理界面打不开？
缺少局域网直连规则。TUN 接管全部流量后，访问局域网 IP 也会被送进代理。必须加一条局域网 IP 段直连的规则。
TUN 模式会更快吗？
不会。TUN 改变的是覆盖范围，不是传输质量。速度由线路类型、节点带宽、地区距离决定，与用哪种模式无关。
TUN 和 VPN 有什么区别？
实现层面类似（都创建虚拟网卡接管流量），区别在于 TUN 模式下你仍然有完整的规则分流能力——可以让国内域名直连、不同服务走不同节点，而 VPN 通常是全量转发。
iOS 上的 TUN 和桌面端一样吗？
不完全一样。iOS 通过系统的网络扩展机制实现，权限与行为受系统限制，某些桌面端可用的配置在 iOS 上不适用。