sing-box TUN route 接管失败怎么办 | auto_route、DNS hijack 与 route.final 排查 2026

Q: sing-box TUN 开了为什么浏览器还是走原来的网络？

常见原因是 `auto_route` 没写入默认路由，或出站流量没有绑定物理网卡，导致请求绕回原接口。先看系统路由表，再看 `route.auto_detect_interface。完整步骤、表格和例外情况请查看原文。

Q: auto_route 和 auto_detect_interface 是一回事吗？

不是。`auto_route` 负责把默认路由导向 TUN，`route.auto_detect_interface` 负责让出站连接绑定当前默认物理网卡，主要用于避免 TUN 回。完整步骤、表格和例外情况请查看原文。

Q: strict_route 打开后为什么有些局域网设备访问不了？

`strict_route` 会让不支持或未覆盖的网络更严格地不可达。Windows 上还能减少多网卡 DNS 泄漏，但 VirtualBox、旁路由或局域网访问要先检查排除网段。

TUN 接管失败要先分清两件事：系统流量有没有进 TUN，DNS 查询有没有进 sing-box。只看客户端界面显示“已启动”不够，TUN 可以启动成功，系统默认路由、DNS 53 端口和最终 outbound 仍然各走各的。

截至 2026-05-22，sing-box changelog 显示最新稳定版是 1.13.11；官方文档同时列出 1.14.0 线的 dns_mode、dns_address 等新增字段。排错时先确认自己跑的是哪个版本，别把 1.14 文档字段直接塞进 1.13 配置。

先判断：接管失败卡在哪一层？

现象	更可能卡点	第一处证据	优先动作
TUN 开启后所有网站仍按原网络访问	`auto_route` 没写入默认路由	系统路由表没有 TUN 默认路由	查 TUN inbound 的 `auto_route`
开启后断网，日志里反复出现连接失败	出站接口回环或物理接口选错	outbound 连接又打回 TUN	查 `route.auto_detect_interface` / `default_interface`
浏览器能访问，规则分流完全不命中	DNS 没进入 sing-box	DNS 查询不出现在 sing-box 日志	查 `dns_mode` 或 `hijack-dns`
FakeIP 有返回，但 route 按 IP 兜底	域名回写链断了	`reverse_mapping` 没有对应域名	查 DNS server、FakeIP range、缓存
未命中规则的连接去了意外出口	`route.final` 留空或写错	日志显示命中第一个 outbound	显式写 `route.final`
只有 Windows 多网卡环境异常	`strict_route`、系统 DNS 或虚拟网卡冲突	同时存在 Wi-Fi、以太网、VPN/VirtualBox 网卡	临时关虚拟网卡并观察 DNS

这张表按“入口 → DNS → route → outbound”排序。入口层没确认之前，不要急着改规则集；DNS 没接进来之前，FakeIP 和域名规则也不会稳定命中。

auto_route 真正接管默认路由了吗？

auto_route 的作用是让 sing-box 自动设置到 TUN 的默认路由。官方 TUN 文档同时提醒：为了避免 TUN 下的路由回环，要设置 route.auto_detect_interface、route.default_interface 或 outbound.bind_interface 其中一种。

最小检查顺序如下：

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

然后在系统里看默认路由是否变化。Linux 可看 ip route，macOS 可看 route -n get default，Windows 可看 route print。如果 TUN 已启动但默认路由仍指向原网关，问题优先在 auto_route、系统权限或客户端包装层，不在订阅内容。

还有两个字段经常被忽略：route_address 和 route_exclude_address。它们在 1.10.0 后替代旧的 inet4_route_address、inet6_route_address、inet4_route_exclude_address、inet6_route_exclude_address。如果你把目标网段写进了 exclude，TUN 看起来开启，实际流量会被排除。

auto_detect_interface、default_interface 和 bind_interface 该留哪一个？

这三个字段都和“出站连接走哪张物理网卡”有关，不是越多越好。排错时只保留一个主控制点。

字段	放在哪里	适合场景	冲突提醒
`route.auto_detect_interface`	`route`	笔记本经常在 Wi-Fi、网线、热点之间切换	如果 outbound 已写 `bind_interface`，它不会生效
`route.default_interface`	`route`	固定服务器、软路由或单网卡设备	开了 `auto_detect_interface` 后会被忽略
`outbound.bind_interface`	单个 outbound	只想让某个 outbound 绑定指定网卡	多 outbound 配置时容易漏写或写错
`route.default_mark`	`route`，Linux only	Linux 策略路由、容器或旁路由环境	outbound 已写 `routing_mark` 时会被忽略

如果你正在排“打开 TUN 后所有请求超时”，先把接口控制简化成一种。常见错误是全局开了 auto_detect_interface，某个 outbound 又绑定了旧网卡名；电脑一换 Wi-Fi 名称或虚拟网卡顺序，连接就落到不存在或不该走的接口。

strict_route 该开还是关？

strict_route 只有在 auto_route 场景下才有排错价值。它不是“增强速度”的开关，而是更严格地处理不支持或未覆盖的网络。

Windows 上，官方文档写明 strict_route 可帮助阻止非 TUN 接口上的 53 端口 DNS 请求，减少多网卡 DNS 行为带来的偏差。代价是某些虚拟网卡或局域网软件可能出问题，文档举到 VirtualBox 这类应用。

Linux 上，strict_route 关闭且没有 auto_redirect 时，ICMP 不会经过 TUN；开启后，不支持的网络可能直接不可达。旁路由、容器、Docker bridge、局域网打印机这类环境，最好先写清 route_exclude_address，再决定是否开严格路由。

设备环境	建议起点	为什么
普通 Windows 笔记本，多网卡或虚拟网卡少	`auto_route: true` + `strict_route: true`	先减少系统 DNS 从非 TUN 接口出去的变量
Windows 装了 VirtualBox、WSL、公司 VPN 客户端	先不开 `strict_route`，逐项验证	虚拟网卡和 WFP 过滤可能互相影响
Linux 桌面单网卡	`auto_route: true`，再看是否需要 `auto_redirect`	默认路由和 nftables 行为要一起看
OpenWrt / 旁路由	先写排除网段，再开严格策略	局域网设备、网关和 DNS 服务器不能被误导入 TUN
Android VPN 模式	关注 `route.override_android_vpn`	官方文档提示 Android VPN 优先级会影响 TUN

DNS hijack 为什么会让 route 看起来“不生效”？

很多 TUN route 故障其实是 DNS 没进 sing-box。浏览器访问域名时，先发生 DNS 查询；如果查询被系统 DNS、路由器 DNS 或另一个客户端处理，sing-box 后面的 dns.rules、FakeIP、reverse_mapping 和域名 route 规则就拿不到完整证据。

1.14.0 文档给 TUN 增加了 dns_mode：disabled、native、hijack。其中 hijack 等于设置接口 DNS，并额外处理 53 端口 DNS 流量。dns_address 如果没有设置，sing-box 会从 TUN address 派生地址并自动做 DNS 处理；如果你手动设置了 dns_address，文档提示自动 hijack 不再应用，需要显式配置 hijack-dns route rule。

1.13 稳定版用户不要直接照抄 dns_mode。更可靠的排查办法是看当前版本是否支持这个字段；不支持时，用 route rule action 里的 hijack-dns 把 DNS 请求交给 sing-box DNS 模块。

一个排错用的逻辑片段可以长这样，字段要按你的版本文档调整：

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

关键不在于复制这段，而是确认 DNS 请求出现在 sing-box 日志里。只有 DNS 先进入 sing-box，后面的 FakeIP、域名规则和 route.final 才有判断依据。

FakeIP、reverse_mapping 和 dns.rules 怎么对上？

sing-box 1.12.0 之后，FakeIP 是一个 DNS server 类型，写在 dns.servers 里，示例使用 type: "fakeip" 和独立 tag。官方 FakeIP 页面给出的默认 IPv4 段是 198.18.0.0/15，IPv6 示例是 fc00::/18。

FakeIP 常见断链点有三类：

配置点	错误写法表现	正确检查
`dns.servers[].tag`	DNS rule 指向不存在的 server	tag 拼写逐字一致
`dns.rules[].action`	仍按旧字段写 server，导入后行为异常	新文档要求 DNS rule 定义 action
`reverse_mapping`	route 只能看到 FakeIP，回不到域名	开启后用同一域名复测日志
FakeIP range	与内网、容器网段或保留地址冲突	避免和局域网、Docker、虚拟网卡网段重叠
缓存文件	重启后规则或映射状态不一致	检查 cache/store 相关路径权限

reverse_mapping 的作用是保留 IP 到域名的映射，让路由阶段能从 FakeIP 找回原始域名。官方 DNS 文档也提醒，它在 macOS 这类系统 DNS 已经介入的环境可能有问题。换句话说，macOS 上不要只看 FakeIP 是否返回，还要看 route 日志里是否真的出现原始域名。

route.final 留空为什么危险？

官方 route 文档写得很直接：final 是默认 outbound tag；如果为空，会使用第一个 outbound。排错时这会制造假象：你以为流量按规则走了，实际只是未命中规则后落到了第一个 outbound。

把 final 显式写出来，至少能让日志更可读：

{
  "route": {
    "auto_detect_interface": true,
    "final": "proxy"
  },
  "outbounds": [
    { "type": "selector", "tag": "proxy", "outbounds": ["direct", "remote"] },
    { "type": "direct", "tag": "direct" }
  ]
}

这段只是示意，真实配置里的 proxy、direct、remote 必须和 outbounds tag 完全一致。启动失败提示 no such outbound，通常就是 route rule 或 final 引用了不存在的 tag。

如果同一份配置要在 Clash / Singbox / V2Ray 客户端之间迁移，订阅返回格式、出站 tag 和规则语义会有差异。多人维护多端配置时，可以把兼容 Clash / Singbox / V2Ray 的订阅作为同一套输入基线；但 TUN 接管是否成功，仍然要回到本机路由表和 sing-box 日志确认。

日志要开到什么级别才看得出问题？

sing-box log 文档列出的级别包括 trace、debug、info、warn、error、fatal、panic。排 TUN route 接管失败，先用 debug；只有需要看更细的匹配细节时，再短时间切到 trace。

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

注意：官方文档说明配置 output 后，日志不会继续写到 console。很多人以为“开了日志但没输出”，其实是日志已经进文件了。

建议抓这几类关键词：

日志线索	说明	下一步
`route` 命中某条 rule	说明连接进入 route 决策	对照 rule index 和 outbound tag
`dns` 查询没有出现	DNS 没进 sing-box	查 `dns_mode` / `hijack-dns` / 系统 DNS
`no such outbound`	tag 引用不存在	查 `route.rules[].outbound` 和 `route.final`
`bind`、`interface`、`default interface`	出站接口被指定或探测	查物理网卡名称是否变化
`permission`、`operation not permitted`	系统权限不足	查管理员权限、VPN 权限或防火墙
`fakeip`、`reverse_mapping`	FakeIP 链路参与了决策	查域名是否能回写到 route

最小复现配置怎么做？

不要直接拿完整订阅排 TUN。完整配置里可能同时有远程规则集、FakeIP、嗅探、策略组、接口绑定、DNS 分流和多个 outbound，变量太多。

更好的办法是临时做一个最小复现：一个 TUN inbound，一个 DNS 入口，一个 direct outbound，一个远端 outbound，一个显式 final。先确认 TUN 接管，再把规则集逐个加回来。

排错记录建议写成一行：

字段	示例
sing-box 版本	`1.13.11` 或 `1.14.0-alpha.x`
系统	Windows 11 24H2 / macOS 15 / Ubuntu 24.04
TUN 入口	`auto_route=true, strict_route=false`
接口策略	`route.auto_detect_interface=true`
DNS 策略	`dns_mode=hijack` 或 `action=hijack-dns`
失败域名	固定一个测试域名，不要每次更换
失败时间	带 timestamp 的 debug 日志时间

同一个动作能稳定复现，才值得改配置。今天开 TUN、明天换订阅、后天改 DNS，最后很难判断到底是哪一项修好或弄坏了。

修好后怎么验证？

修复不是看界面变绿，而是看四个证据同时成立：

系统默认路由指向 TUN，或目标网段明确进入 TUN。
DNS 查询出现在 sing-box 日志里，而不是只在系统或路由器日志里。
连接日志命中预期 route rule；未命中时落到显式 route.final。
出站连接绑定到预期物理接口，没有回到 TUN 或错误虚拟网卡。

复测时用同一个域名、同一个浏览器、同一张网络。不要刚改完 strict_route 就同时切 Wi-Fi，也不要一边清缓存一边换配置文件。TUN 类问题最怕“看起来好了”，但日志证据对不上。

资料来源

FAQ

sing-box TUN 开了为什么浏览器还是走原来的网络？

常见原因是 auto_route 没写入默认路由，或出站流量没有绑定物理网卡，导致请求绕回原接口。先看系统路由表，再看 route.auto_detect_interface。

auto_route 和 auto_detect_interface 是一回事吗？

不是。auto_route 负责把默认路由导向 TUN，route.auto_detect_interface 负责让出站连接绑定当前默认物理网卡，主要用于避免 TUN 回环。

strict_route 打开后为什么有些局域网设备访问不了？

strict_route 会让不支持或未覆盖的网络更严格地不可达。Windows 上还能减少多网卡 DNS 泄漏，但 VirtualBox、旁路由或局域网访问要先检查排除网段。

DNS hijack 没生效会造成什么现象？

域名解析仍由系统 DNS 或路由器处理，sing-box 的 DNS 规则、FakeIP 和 reverse_mapping 就拿不到完整链路，表现为 route 规则看似正确但域名流量不命中。

route.final 留空会怎样？

官方文档说明 final 为空时会使用第一个 outbound。排错时最好显式写出兜底 outbound，避免未命中规则的流量被送到错误出口。

sing-box 1.13 能直接使用 dns_mode 吗？

不要直接照抄。官方 changelog 在 1.14 alpha 线加入 dns_mode 和 dns_address；如果你还在 1.13 稳定版，应按当前版本支持的 DNS 与 route rule 写法配置。