sing-box TUN 模式连接失败：分层排查与恢复步骤
简答：先关闭 TUN 并备份配置，运行 sing-box check。配置通过后，依次确认虚拟网卡、默认路由、DNS 和出站是否正常；不要同时修改 DNS、MTU、strict_route 和节点，逐层测试才能找到真正故障点。
定义：sing-box TUN 模式是通过虚拟网络接口接收系统流量，再交给路由规则、DNS 处理和出站连接的网络接管方式。
三步速查：先判断 sing-box TUN 失败在哪一层
本文只处理 sing-box 开启 TUN 后的启动失败、全局断网、DNS 失败和部分应用无法连接，不包含服务端搭建、节点质量评测或其他客户端配置。本站是第三方使用指南站，不是相关客户端的官方页面。
| 现象 | 先检查 | 验证标准 |
|---|---|---|
| 开启 TUN 后立即退出 | 备份配置，运行 sing-box check，查看权限和字段报错 | 配置检查通过，进程保持运行 |
| TUN 显示运行但全局断网 | 检查虚拟接口、auto_route、默认出站和其他 VPN | 接口存在，路由指向正确，出站有连接日志 |
| IP 可访问但域名打不开 | 检查 dns_mode、dns_address 和 DNS 路由 | DNS 请求有响应，域名与 IP 测试结果一致 |
| 只有一个应用失败 | 检查应用是否绕过系统 VPN、固定 DNS、优先 IPv6 或绑定独立接口 | 其他应用正常，问题应用的网络路径已确认 |
最短路径：先让配置启动，再确认 TUN 接口出现，随后检查路由、DNS 和出站。每完成一层只做一次测试，不要同时更改多个字段。
第一步：备份配置、确认版本并校验 JSON
- 复制当前配置文件，保留一份未开启 TUN 或最近能正常启动的版本。后续每次只恢复一个改动。
- 查看已安装版本：
sing-box version。TUN 文档显示，address、dns_mode、dns_address、strict_route和auto_redirect并非在同一版本加入，旧版本不能直接照抄新字段。 - 在配置所在环境运行
sing-box check。如果客户端提供“检查配置”按钮，使用该按钮也可以，但要以当前客户端实际日志为准。 - 检查失败时，先处理 JSON 语法、未知字段、字段类型和重复端口问题，直到配置能够通过检查，再排查网络接管。
- 需要格式化时，先复制文件，再使用
sing-box format -w -c config.json；不要直接覆盖唯一配置。
官方配置文档列出了 check、format 和配置结构；TUN 文档同时列出了字段的版本变化和已废弃字段。参考：sing-box 配置结构与检查命令、sing-box TUN 字段与版本变化。
第二步：先用最小 TUN 片段验证字段，不要直接改完整配置
下面是用于检查 TUN 字段的最小片段，不是可独立运行的完整配置。它仍需要已有的 dns、route 和 outbounds 配置，不能把示例中的地址直接当作节点或 DNS 服务。
{"type":"tun","tag":"tun-in","address":["172.18.0.1/30"],"auto_route":true,"strict_route":false,"dns_mode":"hijack"}
address定义 TUN 接口地址。官方文档显示，较新的配置使用address，旧的inet4_address和inet6_address已被标记为废弃。auto_route用于把默认路由设置到 TUN。为避免流量回环，需要结合route.auto_detect_interface、route.default_interface或出站的bind_interface。strict_route会改变不支持网络的处理方式。Windows 下还可能影响非 TUN 接口的 DNS 流量，因此应在基础连接正常后再测试。dns_mode从 sing-box 1.14.0 起用于控制 TUN 上的 DNS 处理；当auto_route开启时，官方文档说明hijack通常是默认模式。
如果这段字段加入后配置检查失败，先确认版本，而不是继续修改 MTU、DNS 和路由。字段行为以官方 TUN 文档为准。
第三步：按系统检查权限、虚拟网卡和路由
| 系统 | 先做什么 | 可执行检查 | 失败后怎么回退 |
|---|---|---|---|
| Windows | 用管理员权限启动，确认虚拟适配器出现 | route print；在开启和关闭 TUN 后分别记录默认路由 | 退出其他 VPN、网络过滤器和虚拟网卡工具，再重新启动 |
| macOS | 确认客户端获得网络扩展或 VPN 权限 | ifconfig 查看接口，netstat -rn 查看路由 | 关闭系统代理、重复 VPN 和其他网络扩展后再测试 |
| Linux | 确认运行权限及 TUN 设备权限 | ip link、ip route、ip rule | 先关闭 TUN，记录并恢复原有路由和防火墙，不要直接清空规则 |
| Android | 确认客户端的 VPN 权限已允许 | 查看客户端状态、VPN 通知和应用日志 | 关闭其他 VPN，重新授权后只启用一个 VPN 接管程序 |
| iOS | 确认系统 VPN 配置和网络扩展授权 | 查看客户端服务日志及系统 VPN 状态 | 删除重复的 VPN 配置，重新启用唯一的网络扩展 |
命令行 TUN 的官方支持范围是 Linux、Windows 和 macOS；Android 使用系统 VpnService，Apple 客户端通过 NetworkExtension 提供非特权 TUN。因此，移动端不能直接套用桌面端的接口、权限和路由命令。参考：Android 平台 TUN 特性、Apple 平台 TUN 与 NetworkExtension 特性。
第四步：把出站、TUN 接管和 DNS 分开测试
- 先测出站：暂时关闭 TUN，使用已有的 mixed 或 socks 入站测试同一个出站。如果普通代理入站也无法连接，优先检查节点地址、认证、TLS、系统时间和出站日志，暂时不要修改 TUN。
- 再测 TUN 接管：开启 TUN 后确认虚拟接口存在，再查看默认路由是否变化。接口存在但路由没有接管时，检查
auto_route、route_address、route_exclude_address以及接口绑定。 - 最后测 DNS：如果 IP 连接正常而域名失败，重点检查
dns_mode、dns_address和 DNS 路由。设置dns_address后，需要有对应的 DNS 处理规则，否则可能出现 DNS 请求无响应。 - 分流应用问题：浏览器正常但某个应用失败时，检查该应用是否使用独立代理、固定 DNS、IPv6、QUIC 或指定网络接口。不要因为单个应用失败就立刻更换节点。
判断时要分清三个结论：节点可连接，不等于 TUN 已接管；TUN 已接管，也不等于 DNS 正常。三者至少分别验证一次。
常见日志报错：按关键词决定下一步
| 日志或现象 | 优先检查 | 通过标准 |
|---|---|---|
operation not permitted | Linux 检查运行权限和 TUN 设备权限；图形客户端检查系统授权 | 能够创建虚拟接口，进程不再立即退出 |
Access is denied | Windows 以管理员权限启动，关闭可能冲突的网络工具 | 虚拟适配器出现，启动日志不再报权限错误 |
bind: address already in use | 检查本地监听端口，停止重复运行的 sing-box 或占用程序 | 同一端口只由一个进程监听 |
DNS exchange failed | 先验证出站，再检查 DNS 地址、DNS 路由和劫持模式 | DNS 日志恢复，域名解析可重复成功 |
| 启动成功但全部超时 | 依次回退 strict_route、auto_redirect 和自定义接口绑定 | 找到造成断网的字段或外部网络冲突 |
日志等级可以暂时调为 debug，并保留时间戳；排查完成后恢复日常等级。官方日志配置支持 trace、debug、info、warn、error 等级，详见sing-box 日志配置文档。
第五步：处理 strict_route、auto_redirect 与虚拟网络冲突
- Windows 和 VirtualBox：
strict_route可能使某些虚拟化软件无法正常工作。基础连接未验证前保持关闭，确认 TUN、路由和 DNS 正常后再单独测试。 - Linux 和 Docker：官方文档说明，Linux 上的
auto_redirect需要auto_route，并依赖 nftables 相关能力；它也用于改善 TUN 与 Docker bridge 的路由冲突。启用前先记录现有防火墙规则。 - WSL、虚拟机和容器：先关闭 TUN，确认宿主机网络恢复，再单独启动 TUN。若宿主机正常而虚拟环境失败，检查桥接接口、策略路由和防火墙，不要直接清空规则。
- 其他 VPN 或系统代理：同一时间只保留一个透明接管工具。重复接管可能导致路由回环、DNS 端口冲突或关闭 TUN 后代理残留。
这些设置不是通用“修复开关”。每启用一个字段，都要保存日志、检查路由并测试一个已知域名；出现全局断网就立即回退最近一次改动。
关闭 TUN 后仍断网：完整回滚清单
- 在客户端关闭 TUN，确认服务和虚拟接口已经停止。
- 关闭系统代理、VPN、网络扩展和其他透明接管工具。
- Windows 查看
route print并按需执行ipconfig /flushdns；macOS 检查系统代理、VPN 和 DNS；Linux 查看ip route、ip rule以及防火墙状态。 - 重新连接普通网络，确认不经过 sing-box 时 IP 和域名都能访问。
- 从备份配置开始，只恢复一个改动：先恢复出站，再恢复 TUN，最后按需测试 DNS 劫持、严格路由或 Linux 自动重定向。
如果回滚后仍无法联网，问题可能位于系统代理、路由、防火墙或其他网络工具，而不一定是 TUN 字段本身。不要在未备份原规则的情况下清空系统路由或防火墙。
常见问题
sing-box TUN 一开启就断网，先改 DNS 还是 MTU？
都不要先改。先关闭 TUN、备份配置并运行 <code>sing-box check</code>，然后确认虚拟接口、默认路由和出站是否分别正常。
为什么 TUN 已启动，但只有域名打不开？
优先检查 DNS。查看 <code>dns_mode</code>、<code>dns_address</code> 和 DNS 路由；如果 IP 也无法连接，再回到出站或路由层。
Windows 出现 Access is denied 怎么办？
先用管理员权限启动，暂时关闭其他 VPN、网络过滤器和虚拟网卡工具，确认 TUN 虚拟适配器出现后再测试。
strict_route 要不要一直开启？
不建议把它当作默认修复项。它可能改变不支持网络和 DNS 流量的处理方式，基础连接正常后再单独开启，并准备好回退。
Linux 开启 auto_redirect 后 Docker 无法联网怎么办？
先关闭 TUN 验证 Docker 是否恢复，再检查 nftables、Docker bridge 和策略路由。不要直接清空防火墙规则。
关闭 TUN 后仍然无法联网怎么办？
检查系统代理、VPN、DNS 和路由残留。Windows 查看 <code>route print</code>，Linux 查看 <code>ip route</code> 与 <code>ip rule</code>，macOS 查看 <code>netstat -rn</code>。