sing-box TUN 模式怎么开?按系统与客户端一步步设置
简答:sing-box TUN 模式通常是在客户端的 TUN/VPN 开关中启用;如果使用命令行配置,则在 inbounds 中加入 type 为 tun 的入站,并设置 address 与 auto_route。Windows、macOS、Android、iOS 通常需要系统授权,Linux 还应重点检查 root 权限、nftables 和 auto_redirect。先备份配置,再只开启 TUN、auto_route,并用日志、虚拟网卡、DNS 和终端流量逐项验证,不要把“已连接”直接当成所有应用都已可用。
定义:TUN 模式是由 sing-box 创建虚拟网络接口并接管匹配流量的工作方式,和只修改浏览器或系统 HTTP 代理不同,能够覆盖更多不遵循系统代理设置的应用。
先看速查:你应该在哪里开启 TUN
不同客户端的菜单名称可能不同,常见名称包括“启用 TUN”“TUN Mode”“VPN 模式”或“系统扩展”。以下只列官方资料可以确认的平台能力;具体按钮位置仍以所用客户端版本显示为准。
| 系统 | 开启方式 | 首次授权或限制 | 验证重点 |
|---|---|---|---|
| Windows | 在图形客户端中启用 TUN/VPN,或使用带 tun 入站的配置 | 可能需要管理员权限;strict_route 可影响 DNS 与部分虚拟机软件 | 虚拟网卡、系统代理状态、DNS 与终端流量 |
| macOS | 在 Apple 图形客户端中启用 TUN 或系统扩展 | 通过 NetworkExtension 提供非特权 TUN;界面授权以系统提示为准 | 系统 VPN/网络扩展状态和网页实际连通性 |
| Linux | 命令行或图形客户端加载 tun 入站 | 通常要检查 root、路由权限、nftables;官方推荐 auto_redirect | ip addr、ip route、nft 规则与日志 |
| Android | 在图形客户端启动 VPN/TUN | 客户端通过 Android VpnService 提供非特权 TUN;部分高级路由能力受系统权限限制 | VPN 授权、应用分流、DNS 和实际应用连接 |
| iOS | 在支持 sing-box 的 Apple 客户端中启用 NetworkExtension | 由系统网络扩展管理接口;部分 TUN 字段在 Apple 平台不可用 | 系统 VPN 状态、目标应用连接和 DNS |
官方文档确认,Apple 客户端通过 NetworkExtension 提供非特权 TUN,Android 客户端通过 Android VpnService 提供非特权 TUN;这不代表所有配置字段在移动端都可用。Apple 平台特性说明 Android 平台特性说明
最快开启方法:先用客户端开关,不要立即改 JSON
- 备份当前配置。复制配置文件或导出配置,记录当前能正常连接的状态。若开启后断网,可以先关闭 TUN 并恢复备份。
- 确认客户端已经有可用出站。TUN 只负责接管流量,不会自动生成节点、订阅或代理出站。先确认配置能建立基本连接。
- 打开 TUN/VPN 开关。在客户端中找到 TUN、VPN 或系统扩展开关;首次弹出系统授权时按当前系统提示操作。找不到该开关时,不要猜测菜单路径,先确认客户端是否支持 TUN。
- 先保持默认路由。首次排查只启用 TUN 与 auto_route;Linux 再考虑 auto_redirect,避免一次修改多个变量。
- 验证并分流。依次检查客户端日志、虚拟接口、一个网页、一个终端请求和 DNS。浏览器能打开不等于所有应用都已经过 TUN,单次成功也不等于长期稳定。
停止条件:如果启用后客户端日志出现配置字段错误、权限错误或 DNS 循环,先关闭 TUN,不要继续叠加规则。回滚后保留错误日志,再按下方现象分流。
手写 JSON:当前版本可先用的最小 TUN 入站
如果你使用命令行 sing-box,最小入站可以从下面结构开始。它只展示 TUN 入站,不包含代理出站、路由规则和 DNS 服务器,因此不能单独保证连接可用。
{
"inbounds": [
{
"type": "tun",
"tag": "tun-in",
"address": [
"172.18.0.1/30",
"fdfe:dcba:9876::1/126"
],
"auto_route": true
}
]
}address 是 TUN 接口使用的 IPv4/IPv6 前缀,官方文档将它列为必填字段;auto_route 用于把默认路由设置到 TUN。为了避免代理自身流量再次被 TUN 接管造成环回,还需要配置 route.auto_detect_interface、route.default_interface 或出站的 bind_interface 其中一种可行方案。官方 TUN 字段文档
不要继续照抄旧教程中的 inet4_address、inet6_address、inet4_route_address 或 inet6_route_address。官方文档已将地址字段合并到 address,路由字段合并到 route_address;具体版本是否仍接受旧字段,应以当前配置检查结果为准。
auto_route、auto_redirect、strict_route 怎么选
| 字段 | 作用 | 建议 | 停止或回滚信号 |
|---|---|---|---|
auto_route | 设置到 TUN 的默认路由 | 桌面和命令行首次启用时通常先检查它 | 开启后完全断网或日志出现路由环回 |
auto_redirect | Linux 使用 nftables 改善 TUN 路由与转发 | 官方建议 Linux 使用;需要内核相关 nftables/NFQUEUE 支持 | nft 规则创建失败、Docker 网络异常或启动报错 |
strict_route | 执行更严格的路由规则;Windows 上可阻止普通多宿主 DNS 解析造成的泄漏 | 需要更严格 DNS 路径时再启用 | VirtualBox 或其他虚拟网络软件异常 |
dns_mode | 控制 TUN 接口上的 DNS 处理 | 启用 auto_route 时官方默认倾向 hijack;仍需检查客户端和 DNS 规则 | DNS 循环、域名无法解析或直连 DNS 仍有请求 |
官方说明中,dns_mode 包括 disabled、native 和 hijack;启用 auto_route 时默认使用 hijack。但 DNS 设置是否真正生效,还要结合日志、系统接口 DNS 和实际解析结果判断,不能只看开关状态。官方 TUN 与 DNS 字段说明
按现象排查:启动失败、无网络和 DNS 循环
1. 启动时报权限或创建接口失败
先确认系统授权、客户端是否以所需权限运行,并查看 sing-box 日志中的具体错误。Linux 重点检查当前用户权限、TUN 设备、路由权限和 nftables;Windows、macOS、Android、iOS 则先检查系统 VPN、网络扩展或 VpnService 授权。无法从日志确认原因时,不要直接修改 MTU 或地址。
2. TUN 已开启但所有网页都打不开
先关闭 TUN,确认原始出站仍能连接;再只开启 TUN 和 auto_route。如果这样恢复,可能是路由规则、DNS 或环回配置引起。检查是否设置了 route.auto_detect_interface、route.default_interface 或出站绑定接口,并确认节点连接本身没有被重新送回 TUN。
3. 域名打不开但 IP 测试有结果
把问题缩小到 DNS:查看客户端日志是否有 DNS 请求,检查 dns_mode 是否为 disabled,确认 DNS 地址和路由规则是否互相指向。不要把“能 ping 通 IP”当成 DNS 正常,因为 ICMP、TCP 和 DNS 是不同路径。
4. Linux 开启后 Docker 或局域网异常
优先检查 auto_redirect、Docker bridge 接口和排除路由。官方说明 auto_redirect 旨在改善 Linux TUN 路由并减少与 Docker 桥接网络的冲突,但具体规则仍受系统防火墙和网络拓扑影响。
5. 旧配置提示 stack 或地址字段问题
按 sing-box 官方迁移说明,1.15.0 起 stack 已废弃,建议删除该字段以使用 sing-tun 自有 TCP/IP 栈;官方还说明该字段计划在 1.17.0 移除。旧配置应先复制备份,再删除一个旧字段并重新执行配置检查,不要同时改动 DNS、路由和出站。官方迁移指南
开启后的验证清单:确认“真的生效”
- 配置层:客户端日志没有 JSON、字段、权限或路由错误。
- 接口层:系统出现由客户端管理的 VPN 或 TUN 接口;移动端接口名称可能由系统管理,不一定能手动指定。
- 路由层:默认路由或目标路由符合预期,代理出站没有回到 TUN 形成环路。
- DNS 层:执行一次域名解析并查看客户端日志;如果需要排查 DNS 泄漏,应对比系统 DNS、接口 DNS 与客户端处理结果。
- 应用层:分别测试浏览器、终端和一个不遵循系统代理的应用。一个网页能打开,只能证明该次请求成功,不能证明所有应用都被接管。
如果验证失败,按“关闭 TUN—恢复备份—保留日志—只改一个字段—再次验证”的顺序回滚。不要用单次延迟或单次测速推断长期线路质量。
常见问题
sing-box TUN 模式和系统代理有什么区别?
系统代理通常只影响遵循 HTTP、HTTPS 或 SOCKS 代理设置的应用;TUN 通过虚拟网络接口接管更底层的流量,因此覆盖范围可能更大。但最终是否经过代理仍取决于路由、DNS、应用限制和客户端平台能力。
开启 TUN 后还要不要打开系统代理?
不一定。TUN 与系统代理是两条不同机制,是否同时启用取决于客户端实现和你的分流需求。首次排查时建议只启用一种接管方式,避免端口、路由和代理链互相影响。
为什么配置里有 stack,官方却建议删除?
官方迁移指南说明,sing-box 1.15.0 起 sing-tun 使用自有 TCP/IP 栈,stack 已废弃。新配置可删除该字段;如果删除后仍启动失败,应继续查看具体日志,而不是恢复多个旧字段。
Android 和 iOS 能不能使用 Linux 的 auto_redirect?
不能直接照搬。官方文档将 auto_redirect 的支持范围和权限条件按平台区分;Android 的图形客户端通过 VpnService 提供 TUN,Apple 客户端通过 NetworkExtension 提供 TUN,许多 Linux 专用字段在移动端不可用。
开了 TUN 就代表 DNS 不会泄漏吗?
不能直接这样判断。DNS 还受 dns_mode、strict_route、系统接口 DNS、路由规则和客户端实现影响。应查看日志并做实际 DNS 对比;如果发现异常,先关闭 TUN 或回滚到备份,再单独调整 DNS 配置。
常见问题
sing-box TUN 模式怎么开?
图形客户端中找到 TUN、VPN 或系统扩展开关并授权;命令行则在 inbounds 中加入 type 为 tun 的入站,设置 address 和 auto_route,再按日志、虚拟接口、DNS 与实际应用流量验证。
Windows 开启 sing-box TUN 需要管理员权限吗?
是否需要管理员权限取决于客户端实现和当前配置。若出现创建接口、设置路由或系统扩展权限错误,应以客户端日志和系统授权提示为准,不要仅凭开关状态判断。
Linux 为什么建议开启 auto_redirect?
官方文档说明 auto_redirect 仅支持 Linux 且依赖 auto_route,可通过 nftables 改善 TUN 路由与性能,并减少和 Docker 桥接网络的冲突;实际仍要检查内核和防火墙支持。
sing-box 1.15 还能继续写 stack 吗?
stack 自 sing-box 1.15.0 起已废弃,官方迁移指南建议删除它以使用 sing-tun 自有 TCP/IP 栈,并说明该字段计划在 1.17.0 移除。
TUN 开启后完全断网怎么办?
先关闭 TUN并恢复备份,检查客户端日志中的权限、DNS、路由和环回错误;然后只重新开启 TUN 与 auto_route,确认基本连接后再逐项加入 strict_route、auto_redirect 或自定义 DNS。