sing-box 的 TUN、DNS、route 和 log 是一条链：入口没接管，DNS 再漂亮也不会命中；DNS 没进入 sing-box，域名规则就可能退化成 IP 兜底；route.final 没写清，日志里“能连上”也可能只是走到了第一个 outbound。

截至 2026-05-23，GitHub Releases 页面可见 v1.14.0-alpha.25，而不少 GUI 仍混用 1.13 稳定线和 1.14 文档字段。排障第一步不是换大配置，而是确认当前 core 支持哪些字段。

先判定问题落在哪一层？

把现象先压到一层，能少走很多弯路。TUN 类问题最怕一边改 DNS、一边换订阅、一边开严格路由，最后只剩一个无法解释的现场。

现象更可能卡点第一条证据做动作
开 TUN 后全局断网auto_route、系统权限、出站接口回环默认路由没变，或日志有 permission / interface查路由表和 TUN 权限
浏览器能用，终端或 App 不通系统代理与 TUN 混用只有读取系统代理的软件可用排障时只保留一个入口
域名规则不命中DNS 没进 sing-boxdebug 日志看不到 DNS 查询查 dns_mode 或 hijack-dns
FakeIP 有返回但 route 仍按 IP 走reverse mapping 或缓存链断日志里只有 FakeIP，没有原始域名查 reverse_mapping 和 DNS server tag
未命中规则去了奇怪出口route.final 留空或 tag 写错日志落到第一个 outbound，或报 no such outbound显式写 route.final
关闭客户端后仍然没网系统代理、DNS、虚拟网卡残留系统仍指向本机端口或旧 DNS恢复系统网络设置

先固定一个测试动作：同一个域名、同一个 App、同一张网络。每次只改一个变量，才能知道哪一项真正影响结果。

最小配置先检查哪 7 个字段？

不要直接拿完整订阅排错。完整 profile 里可能同时包含远程规则集、FakeIP、嗅探、多个 selector、接口绑定、缓存目录和平台特定字段，变量太多。

跑两条命令：

sing-box version
sing-box check -c ./config.json

然后按下面 7 个点过一遍。

检查点合格信号常见错误
log.levelinfo 日常，复现时短切 debug长期开 trace，日志太大
inbounds[].type=tunTUN inbound 能启动，系统看到虚拟接口权限不足、地址或 MTU 未自动设置
auto_route默认路由或目标路由进入 TUN开关打开但系统路由没变
strict_route只在需要收紧多网卡 DNS 时开启Windows 虚拟网卡、VirtualBox、公司 VPN 冲突
route.auto_detect_interface出站绑定当前物理网卡又在 outbound 写了 bind_interface，导致全局设置失效
dns.final指向已存在的 DNS server tag留空后默认使用第一个 server，被误判成规则生效
route.final指向已存在的 outbound tag留空后默认使用第一个 outbound

官方 TUN 文档提醒：auto_route 要配合 route.auto_detect_interface、route.default_interface 或 outbound.bind_interface 之一，避免 TUN 下路由回环。排障时只留一种接口控制点，别三种都写。

DNS mode 要怎么选？

1.14 线的 TUN 文档列出 dns_mode：disabled、native、hijack，默认是 hijack。hijack 的意义是让平台 DNS 处理和 53 端口 DNS 流量都进入 sing-box 的 DNS 模块。

如果你手动写了 dns_address，官方文档提示自动 hijack 不再应用。这时要确认是否还需要显式的 route rule action：

{
  "route": {
    "rules": [
      {
        "protocol": "dns",
        "action": "hijack-dns"
      }
    ]
  }
}

1.13 或更早配置不要直接照抄 1.14 字段，看 sing-box check 是否接受 dns_mode；不接受，就按当前版本支持的 hijack-dns、DNS server 和 DNS rule 写法处理。

DNS 排障只看网页结果不够。要在日志里看到查询进入 sing-box，再看它被哪个 dns.servers[].tag 处理。官方 DNS 文档还写明：dns.final 为空时会使用第一个 DNS server，这和 route.final 的坑很像。

macOS 上要特别看缓存和系统 DNS。官方 DNS 文档提到 reverse_mapping 在 macOS 这类系统代理或缓存介入的环境可能不可靠，所以 FakeIP 能返回，不代表 route 阶段一定能还原原始域名。

route 规则和 final 为什么要显式写？

route 的目标不是“规则越多越好”，而是让每个未命中的连接也有可解释的去处。官方 route 文档说明：final 是默认 outbound tag；为空时使用第一个 outbound。

排障配置可以把兜底写得很直白：

{
  "route": {
    "auto_detect_interface": true,
    "rules": [
      {
        "domain_suffix": ["example.org"],
        "outbound": "proxy"
      }
    ],
    "final": "direct"
  },
  "outbounds": [
    { "type": "selector", "tag": "proxy", "outbounds": ["remote", "direct"] },
    { "type": "direct", "tag": "direct" }
  ]
}

这段只说明结构，不是通用模板。真实配置里 proxy、remote、direct 必须和 outbounds[].tag 完全一致。日志出现 no such outbound 时，查 tag 拼写，不要马上怀疑 TUN 或 DNS。

多人维护多端配置时，Clash/Mihomo、sing-box 和 V2Ray 的订阅导出语义不一样。同一份配置要跨客户端对照时，可以用兼容 Clash / Singbox / V2Ray 的订阅做输入基线；本机是否修好，仍以 route 命中日志和系统路由表为准。

日志开到什么级别才够？

官方 log 文档列出的级别包括 trace、debug、info、warn、error、fatal、panic。日常运行用 info；排 TUN、DNS、route、outbound 命中时，短时间改成 debug 通常够用。

{
  "log": {
    "level": "debug",
    "output": "box.log",
    "timestamp": true
  }
}

注意 output：官方文档写明，设置输出文件后不会继续写到 console。很多 GUI 用户以为“没日志”，其实日志已经进文件。

取样时抓 30-60 秒，不要贴一整天日志。重点找这些线索：

日志关键词说明下一步
dns、exchange、cacheDNS 查询和上游响应对照 dns.rules、dns.final、server tag
route、match、规则序号连接进入路由决策对照命中的规则和 outbound
no such outboundroute 或 final 引用不存在查 outbounds[].tag
permission、operation not permitted系统权限不足查管理员权限、网络扩展或 VPN 授权
default interface、bind出站接口被指定查物理网卡名是否变化
address already in use本机端口冲突查旧客户端或残留进程

提交日志前先脱敏：订阅 URL、节点地址、UUID、password、private key、token、公司内网段、真实公网 IP 都要替换。保留字段形状即可，例如 https://sub.example/api?token=REDACTED。

Windows、macOS、Linux、Android 权限怎么分开看？

Windows 常见是管理员权限、WFP、虚拟网卡和其它 VPN 客户端冲突。strict_route 在 Windows 上可帮助阻止非 TUN 接口的 53 端口 DNS，但也可能影响 VirtualBox 这类虚拟网络软件。

macOS 常见是网络扩展授权、系统 VPN 配置和 DNS 缓存。关闭 sing-box 后若系统代理仍指向 127.0.0.1 的旧端口，浏览器会继续失败，看系统网络设置，不要只看 GUI 按钮。

Linux 常见是 NetworkManager、systemd-resolved、nftables/iptables、Docker bridge 和路由策略冲突。官方 TUN 文档还建议 Linux 在可用时使用 auto_redirect，它能改善路由行为并减少 Docker bridge 相关冲突。

Android 要记住一件事：系统同一时间只会把 VpnService 交给一个应用。SFA、Clash 系客户端、WireGuard、公司 VPN 不能同时占用系统 VPN 通道。排障阶段先关掉其它 VPN 应用，再让系统重新弹出授权。

平台看什么快速回退动作
Windows管理员权限、虚拟网卡、WFP、防火墙关 strict_route，退出其它 VPN，重启客户端
macOS网络扩展授权、系统代理、DNS 缓存清系统代理，重启网络扩展或切换网络位置
Linuxip route、ip rule、nftables、Docker关 TUN，用本机 mixed/socks 入站验证 core
AndroidVpnService 授权、始终开启 VPN、电池策略删除旧 VPN 配置，关其它 VPN 应用，重新授权

权限问题和配置问题要分开。权限不足通常在 TUN 创建、路由写入或 VPN 授权阶段就报错；配置错误更多表现为启动后立即退出，日志里出现 unknown field、JSON parse、no such outbound 或 DNS server tag 不存在。

回滚步骤：从完整订阅退到最小复现

回滚不是把所有设置恢复默认，而是退到“能启动、能转发、能解释”的最小状态。文件名直接写清顺序和变量。

00-original-profile.json
01-check-pass.json
02-mixed-only.json
03-add-dns.json
04-add-route-final.json
05-add-tun-auto-route.json
06-add-strict-route.json

推荐顺序：

  1. 复制原始配置，不在唯一文件上直接改。
  2. 删除远程 rule_set、复杂 selector、嗅探和平台特定规则，只留一个本机入口。
  3. 用 direct 和一个远端 outbound 验证 core 能转发。
  4. 加 DNS server 和 dns.final，确认日志能看到查询。
  5. 加 route rule 和显式 route.final，确认命中路径。
  6. 最后加 TUN、auto_route、接口控制和 strict_route。

如果第 3 步能通、第 6 步断网，问题在 TUN、路由、权限或接口绑定，不在节点参数。若第 4 步开始失败，修 DNS server、上游可达性和 tag 引用。

求助前要打包哪些信息？

求助不是把整份订阅扔出去。能让别人判断问题的，是版本、系统、最小配置片段、同一动作的日志和最近变更。

信息写法示例为什么要给
core 版本sing-box 1.13.x 或 1.14.0-alpha.25字段支持差异很大
客户端SFA、官方 core、Hiddify、Karing、第三方 GUIGUI 可能内置旧 core
系统Windows 11 24H2、macOS 15、Ubuntu 24.04、Android 15权限和网络栈不同
入口tun auto_route=true / mixed :7890判断入口是否接管
DNS 模式dns_mode=hijack、action=hijack-dns、dns.final=remote判断域名链路
route 兜底route.final=proxy 或 direct判断未命中流量去向
复现动作“访问 example.org，时间 21:03:10”日志能按时间对齐
最近变更升级 core、换订阅、改 DNS、开 strict_route找第一处变化

公开 issue 或群聊里不要贴完整订阅、真实节点地址、token、UUID、private key、后台面板地址和内网拓扑。可以把敏感值替换成 REDACTED，保留 tag、字段名和层级。

相关阅读