sing-box TUN 模式连接失败：先判断 TUN、DNS、路由还是节点故障
简答：先关闭 TUN，确认普通代理或直连网络是否恢复；再备份配置并运行 sing-box check，最后根据日志判断是 TUN 创建、DNS、路由还是节点出站失败。关闭 TUN 后恢复，优先查本机权限、DNS 接管和默认路由；只有域名失败查 DNS，只有单个节点失败再查节点或服务端。
定义：sing-box TUN 模式是通过虚拟网卡接管系统流量的工作方式，连接失败通常发生在 TUN 创建、DNS 解析、路由接管或代理出站其中一层。
先做三步速查：不要一开始就换节点
本文是第三方使用指南，不是 sing-box 或其他客户端的官方网站。排查时先把故障分层，否则同时修改 DNS、MTU、路由和节点，很难知道哪一步真正生效。
| 现象 | 第一步 | 优先怀疑 | 结果判断 |
|---|---|---|---|
| TUN 一开启就报错或自动关闭 | 关闭 TUN，查看第一条启动错误 | 权限、虚拟网卡、字段或版本差异 | 接口未出现或进程退出，先处理本机创建失败 |
| TUN 显示运行但所有网页打不开 | 关闭 TUN，看普通网络是否恢复 | DNS、默认路由、回环或系统代理冲突 | 关闭后恢复，问题集中在 TUN 接管链路 |
| 只有域名打不开，已有 IP 连接仍在 | 用 nslookup 或系统 DNS 测试 | dns_mode、DNS 出站或劫持规则 | 解析失败而路由正常，优先查 DNS |
| 只有一个节点失败 | 用同一配置测试其他节点 | 端口、TLS、协议或服务端状态 | 其他节点可用时，不要先改 TUN |
| 所有节点都失败，普通代理也失败 | 检查出站配置和端口可达性 | 节点地址、端口、时间或服务端连通性 | 本机 TUN 不是唯一可能原因 |
- 关闭 TUN，并确认浏览器或普通代理是否恢复。
- 复制当前配置和日志，再运行
sing-box check -c config.json。 - 根据第一条明确错误一次只改一个变量，优先从权限、DNS、路由、出站顺序排查。
官方配置说明将 JSON 配置检查与运行时网络行为分开；sing-box check 只能帮助发现配置结构或字段问题，不能证明 TUN 接口、DNS、路由和节点连接都正常。可参考 sing-box 配置引言。
安全回滚：先恢复网络，再逐项恢复 TUN
- 备份：复制配置文件，保留故障发生时的日志、系统版本和 sing-box 版本。
- 关闭接管：关闭 TUN；如果仍无法联网，再关闭系统代理、其他 VPN 或分应用代理。
- 确认直连：测试一个已知可访问的 IP 和一个域名，确认普通网络与解析都恢复。
- 校验配置：运行
sing-box check -c config.json，只修复命令明确指出的字段问题。 - 最小恢复：先只启用 TUN 和现有出站，不要同时加入自定义 DNS、严格路由、自动重定向或 MTU 修改。
- 逐项增加：按 DNS、路由、严格路由、Linux 自动重定向的顺序，每次只恢复一项。
如果关闭 TUN 后网络仍未恢复，不要继续修改 TUN 配置；先检查系统代理、其他 VPN、DNS 设置和节点出站。任何删除系统路由或防火墙规则的操作都应延后，优先使用只读检查。
官方文档当前明确列出了 TUN 字段的版本变化。stack 在 sing-box 1.15.0 中已标记为弃用，并计划在 1.17.0 移除；遇到旧配置时应按官方迁移说明核对，不要把旧字段直接复制到新配置。
DNS 与路由：最容易把“能启动”误判成“能联网”
先隔离 DNS。在支持当前字段的版本中，dns_mode 的含义是：disabled 不配置原生 DNS、也不劫持 DNS；native 尝试设置系统或接口 DNS；hijack 在此基础上额外处理 53 端口流量。排查时可先使用 disabled 隔离 DNS 变量，确认路由和出站是否基本可用，再测试 native。
不要绝对化理解 dns_address。官方 TUN 文档说明，未设置 dns_address 时，系统会根据 TUN 地址选择后续地址，并按相应方式处理；如果手动设置了 dns_address，则需要在当前版本配置中匹配对应的 hijack-dns 路由动作。这是特定 DNS 接管配置下的匹配关系，不代表所有 DNS 配置都必须使用同一条规则。详见TUN 配置参考。
再检查路由回环。auto_route 会把默认路由设置到 TUN。官方文档建议通过 route.auto_detect_interface、route.default_interface 或出站的 bind_interface 避免代理出站再次被送回 TUN。若 TUN 已运行但所有请求超时，先检查这些接口选择项，不要先改 MTU。
strict_route 要按平台理解。在 Windows 上，它用于更严格的路由处理，也用于减少普通多网卡 DNS 解析造成的泄漏，但官方同时提示某些应用可能因此无法正常工作；在 Android 和 Apple 图形客户端中，官方特性页将该字段标为未实现，因此不能把桌面端结论直接套到移动端。
Windows：权限、虚拟网卡、代理冲突和 DNS
- 关闭 TUN：确认普通代理或直连恢复。如果没有恢复，先检查系统代理和其他 VPN。
- 检查网卡：以管理员身份打开 PowerShell，执行
Get-NetAdapter。预期能看到新增或正在运行的虚拟适配器；如果没有，优先检查客户端权限、驱动安装和安全软件拦截。 - 检查路由：执行
route print，只观察活动路由，不要直接删除。开启 TUN 前后对比默认路由是否发生变化；如果 TUN 关闭后路由仍残留，先重启客户端或系统，再按客户端提供的恢复方式处理。 - 检查 DNS：执行
nslookup example.com。如果 TUN 关闭时能解析、开启后超时，优先测试dns_mode，不要同时修改节点。 - 检查系统代理：确认系统代理指向的本地端口仍由 sing-box 监听。TUN 与系统代理同时开启时，先保留一种接管方式做对照。
- 检查 strict_route：如果浏览器能用但 VirtualBox、局域网工具或某个程序不能用，记录关闭前后的差异，先临时关闭 strict_route 复测。
典型判断是：没有虚拟适配器属于创建或权限层；适配器存在但 DNS 超时属于 DNS 层；DNS 正常但所有 TCP 请求超时，继续检查默认路由、出站绑定和节点端口。Windows 的 strict_route、DNS 53 端口处理和 TUN 版本字段以官方 TUN 文档为准。
Linux：TUN 权限、路由表、nftables 和 Docker 冲突
- 停止服务：如果使用 systemd，执行
sudo systemctl stop sing-box，确认普通网络恢复后再继续。 - 检查接口：执行
ip addr。预期能看到 TUN 接口及其地址；没有接口时，先查运行用户权限、配置字段和启动日志。 - 检查路由：执行
ip route。只读观察默认路由、TUN 相关路由和 Docker 网桥；不要直接删除路由。若停止 sing-box 后异常路由仍在，先重启服务或系统网络管理服务，并保留现场信息。 - 检查 nftables：执行
sudo nft list ruleset。预期能看到与自动重定向相关的规则；如果规则被其他防火墙工具覆盖，先暂时关闭auto_redirect做对照，不要清空整套规则。 - 查看日志：执行
sudo journalctl -u sing-box --output cat -e查看最近日志，或执行sudo journalctl -u sing-box --output cat -f观察新日志。官方安装文档提供了这两种 systemd 日志命令。 - 检查 Docker：如果只在 Docker、容器或桥接网络中失败，比较启用 TUN 前后的
docker0、路由和 nftables 规则，再一次只调整自动重定向变量。
官方文档将 auto_redirect 标为 Linux 专用能力，并说明它需要 auto_route，通过 nftables 改善路由、性能并减少 TUN 与 Docker 网桥冲突；这不等于所有发行版、防火墙和内核都无需额外核对。参考TUN 字段说明和官方服务管理文档。
macOS：系统扩展、网络权限、系统代理和日志
- 关闭 TUN：确认普通网络恢复，再检查是否存在其他 VPN 或系统代理。
- 检查授权：在客户端或系统设置中确认 Network Extension、VPN 或相关网络扩展授权已经完成；如果系统出现授权提示，不要点拒绝后继续反复启动。
- 检查系统代理：确认系统代理没有指向已停止的本地端口。TUN 和系统代理同时启用时，先关闭其中一种。
- 检查 DNS：先测试域名解析，再根据结果对照
disabled、native和hijack。如果 IP 可达而域名失败，优先查 DNS，不要先改 MTU。 - 查看日志：Apple 图形客户端的官方特性页说明，服务日志可从客户端的 Settings → View Service Log 查看；如果当前客户端没有该入口，以当前版本界面为准。
Apple 图形客户端使用 NetworkExtension 提供非特权 TUN，且官方特性页将 strict_route 标为未实现，因此 macOS 或 iOS 客户端不能照搬 Windows 的 strict_route 排查结论。参考Apple 客户端特性说明。
Android：VPN 授权、分应用设置、其他 VPN 和日志
- 重新确认 VPN 授权：关闭 sing-box 后，从系统 VPN 设置确认没有其他 VPN 正在占用连接；再次启动时接受系统 VPN 请求。
- 检查分应用路由：如果只有部分应用不能联网，检查客户端的 include_package、exclude_package 或分应用代理设置。先临时取消分应用限制，测试全量接管。
- 检查始终开启 VPN：如果系统开启了“始终开启 VPN”或“阻止未使用 VPN 的连接”，先记录设置状态，再暂时关闭做对照，避免把系统强制策略误判为 sing-box 节点故障。
- 检查 DNS：先用浏览器测试 IP 和域名，再检查当前配置的 DNS 模式。移动端不要直接套用 Windows 的 strict_route 或 Linux 的 auto_redirect 判断。
- 查看日志：官方 Android 特性页说明，崩溃日志位于工作目录的
stderr.log；图形客户端是否提供完整运行日志，以当前客户端界面为准。 - 检查电池限制：如果 TUN 启动后过一段时间自动停止，检查系统对 sing-box 的后台运行和电池优化限制；先恢复前台运行，再判断是否仍然断流。
官方 Android 特性页说明，图形客户端通过 Android VpnService 提供非特权 TUN，并支持按应用包含或排除；同时将 strict_route 标为未实现。因此 Android 的排查重点是 VPN 授权、分应用规则、其他 VPN 冲突和后台限制，而不是照搬桌面端路由选项。参考Android 客户端特性说明。
按日志关键词判断下一步
| 关键词或现象 | 通常对应层级 | 下一步 |
|---|---|---|
| configure tun interface、permission denied、device unavailable | TUN 创建或权限 | 检查系统授权、运行用户、虚拟网卡和其他 VPN 冲突 |
| DNS exchange failed、resolve timeout | DNS | 暂时隔离 DNS 模式，检查 DNS 出站和 hijack-dns 关系 |
| no route、network unreachable | 路由 | 只读检查 ip route 或 route print，核对自动探测接口和默认接口 |
| connection refused、i/o timeout | 出站或节点 | 检查地址、端口、TLS 时间和同配置下其他节点 |
| context canceled | 连接被取消或上游变化 | 结合前一条错误判断，不要只凭这一行断定节点故障 |
如果需要增加日志，可在配置中设置 log.level 为 debug，并保留故障时段的日志；官方日志配置支持 trace、debug、info、warn、error 等级以及输出文件。排查完成后可恢复到较低日志等级，避免长期产生过多日志。参考sing-box 日志配置。
最终复测清单：确认修复的是哪一层
- 关闭 TUN，确认普通网络、IP 连接和域名解析都正常。
- 开启最小 TUN 配置，只测试一个网页和一个 DNS 查询。
- 检查是否出现 TUN 接口、默认路由和预期日志。
- 再恢复 DNS 设置，单独测试域名解析。
- 再恢复路由规则或严格路由，测试局域网、浏览器和命令行。
- 最后测试多个节点、TCP 连接和需要 UDP 的应用。
- 若某一步失败，回到上一个成功配置，不覆盖原始备份。
如果只有一个节点失败，应优先检查节点端口、TLS、协议和服务端状态；如果所有节点只在 TUN 开启后失败，应回到本机权限、DNS 和路由。无法从本页资料确认某个具体服务的在线状态时，不要把一次连接失败直接判断为服务端故障。
常见问题
sing-box TUN 一开启就断网，应该先改什么？
先关闭 TUN，确认普通网络恢复，再备份配置并运行 sing-box check -c config.json。配置通过后，优先隔离 DNS 和默认路由变量，不要同时修改 MTU、节点和规则。
sing-box check 通过了，为什么 TUN 还是连接失败？
配置检查通过不代表虚拟网卡权限、系统路由、DNS 出站、nftables 或节点端口可达。继续结合日志、ip addr、ip route、route print 或实际域名测试判断。
dns_mode 应该选 disabled、native 还是 hijack？
排查时可先用 disabled 隔离 DNS；确认路由和出站正常后再测试 native。hijack 会额外处理 DNS 流量，若设置了自定义 dns_address，应按当前版本配置参考匹配 hijack-dns 路由动作。
Windows 开启 strict_route 后部分软件不能联网怎么办？
记录开启和关闭后的差异，先临时关闭 strict_route 复测，并检查软件是否使用虚拟网卡、独立 DNS 或特殊绑定接口。官方文档明确提示该选项在某些 Windows 应用场景中可能造成兼容性影响。
Linux 开启 TUN 后 Docker 网络异常怎么办？
先停止 sing-box，确认 Docker 网络恢复，再只读检查 ip route 和 nft list ruleset。不要清空防火墙规则；根据结果单独测试 auto_redirect 或相关路由设置。
Android 为什么只有部分应用不能联网？
优先检查 VPN 授权、分应用代理、include_package、exclude_package、其他 VPN 和后台限制。先临时取消分应用限制并全量接管，再判断是应用规则还是 TUN 本身的问题。
常见问题
sing-box TUN 一开启就断网，应该先改什么？
先关闭 TUN，确认普通网络恢复，再备份配置并运行 sing-box check。之后先隔离 DNS 和默认路由变量，不要同时修改 MTU、节点和规则。
sing-box check 通过了，为什么 TUN 还是连接失败？
check 主要验证配置结构，不能证明虚拟网卡权限、系统路由、DNS 出站、nftables 或节点端口可达，需要结合日志和系统网络检查继续定位。
dns_mode 应该选 disabled、native 还是 hijack？
排查时可先用 disabled 隔离 DNS，确认路由和出站正常后再测试 native；hijack 涉及额外 DNS 流量处理，需按当前版本配置参考匹配 dns_address 与 hijack-dns 规则。
Windows 开启 strict_route 后部分软件不能联网怎么办？
先记录开启与关闭后的差异，临时关闭 strict_route 复测，同时检查软件是否使用虚拟网卡、独立 DNS 或特殊绑定接口。
Linux 开启 TUN 后 Docker 网络异常怎么办？
先停止 sing-box，确认 Docker 网络恢复，再只读检查 ip route 和 nft list ruleset；不要清空防火墙规则，按变量逐项复测。
Android 为什么只有部分应用不能联网？
优先检查 VPN 授权、分应用代理、include_package、exclude_package、其他 VPN 和后台限制，先取消分应用限制测试全量接管。