sing-box TUN 卡住怎么办？按启动、DNS、路由与断流排查

更新于 2026-10-27 · stc-spadesdns.cyou

简答：本文只覆盖 Linux 和 Windows 上 sing-box 开启 TUN 后卡住、断流或无网络的排查。最快顺序是：停止 TUN确认直连恢复，记录 sing-box 版本和首次报错，把日志临时调到 debug，再单独回退 DNS 劫持，最后对比 TUN 启动前后的路由表；不要先把 1.14.4 的一个公开 Issue 当成所有用户的通用原因。

定义：sing-box TUN 卡住，是指 TUN 虚拟接口、DNS 处理、系统路由或代理出站在启动或运行期间没有按预期完成，表现为网页加载停滞、部分连接失败、直连流量被影响或 TUN 无法正常接管流量。

先做这张 30 秒自查卡：停止 TUN，再逐项恢复

如果现在已经无法正常上网，先不要换节点，也不要同时修改 DNS、路由和 MTU。按下面顺序操作，每一步都记录结果；任何一步恢复网络，都先保留日志和配置副本。

停止 TUN：在客户端停止 TUN；如果你是通过 systemd 注册的服务运行，才使用 sudo systemctl stop sing-box，服务名称不一定就是 sing-box。
确认直连是否恢复：停止后重新打开一个普通网页，并用 nslookup example.com 或 Linux 的 dig example.com 检查域名解析。这里的结果只用于观察系统直连是否恢复，不能证明代理链路正常。
记录版本和平台：执行 sing-box version，同时记录 Linux 或 Windows、客户端类型、TUN 栈、DNS 出站类型和首次出现时间。
抓首次报错：把日志临时设为 debug，重现一次后记录第一条 DNS、timeout、route、tun 或 interface 相关错误，不要只看最后一行。
只回退 DNS：复制配置后，暂时将 TUN 的 dns_mode 改为 disabled，只测试 DNS 劫持是否影响现象。该模式表示不配置原生 DNS，也不劫持 DNS 流量。官方 TUN 文档

如果仅关闭 DNS 劫持后恢复，只能把范围缩小到 DNS 处理、DNS 出站、路由或回环，不能单独证明 DNS 建连就是根因。

现象—证据—动作—恢复标准

现象	先看什么	低风险动作	恢复标准
启动 TUN 一直等待	启动日志、权限、虚拟接口	停止进程后重新启动，确认接口是否出现	日志显示接口创建完成，系统能看到对应接口
开启 DNS 后网页普遍卡住	dns_mode、dns_address、DNS 出站日志	仅将 dns_mode 临时改为 disabled	直连解析不再持续超时，且配置能恢复启动
运行一段时间后断流	断流前后的日志、接口和路由变化	停止 TUN，保存日志和路由表，再启动一次	同一配置下能稳定复现或不再复现
只有部分网页或下载卡住	MTU、IPv4/IPv6、路由与出站绑定	一次只降低 MTU 或临时关闭一个相关字段	固定测试目标的连接能够完成，且没有新增回环错误

前置条件：确认版本、配置文件和运行方式

本文核验日期为 2026-10-27，命令重点针对 Linux 与 Windows。macOS、Android 的图形客户端可能使用不同的权限、日志入口和 VPN 接口，不能直接套用本文命令。

执行 sing-box version，确认你检查的是实际运行的内核，而不是系统中另一份 sing-box。
复制当前 JSON 配置和配置目录，所有修改都在副本上进行；不要把订阅链接、令牌、私钥、UUID 或完整服务器信息贴到公开页面。
如果命令行可执行文件与图形客户端分开安装，先确认客户端实际调用的内核路径和版本。
按官方配置文档执行 sing-box check。官方文档给出的检查命令是 sing-box check；它用于发现配置检查错误，不能证明 DNS、节点、TUN 路由或业务连接一定可用。官方配置文档
如果配置使用了 1.14.0 或更晚版本才出现的字段，例如 dns_mode、dns_address，必须确认运行内核版本支持这些字段。官方 TUN 文档列出了字段的版本变化。TUN 字段与版本变化

第一阶段：检查 TUN 是否真的启动成功

Linux

先停止 TUN，再分别记录启动前后的接口和路由：

ip link：查看是否出现新的 TUN 或虚拟接口。
ip route：查看默认路由和与 TUN 相关的路由。
ip rule 与 ip route show table all：查看策略路由和其他路由表。
如果通过 systemd 运行，使用 sudo journalctl -u sing-box --output cat -e 查看末尾日志；持续复现时使用 sudo journalctl -u sing-box --output cat -f。只有服务确实注册为 sing-box 时，这个服务名才适用。

Windows

使用管理员 PowerShell 执行 route print，记录默认路由、接口列表和 TUN 启动前后的差异。
在“网络连接”或“设备管理器”中确认虚拟网卡是否出现、是否被禁用；不要在未确认接口名称和归属前批量删除路由。
如果图形客户端有日志页，优先查看启动 TUN 时的第一条错误；如果客户端使用独立日志文件，先确认日志文件位置再复制相关片段。

官方文档说明，auto_route 会把默认路由设置到 TUN；为避免流量回环，可以配置 route.auto_detect_interface、route.default_interface 或出站的 bind_interface。auto_route 与回环规避说明

第二阶段：用最小回退顺序定位 DNS 与路由

不要把下面片段当作完整配置直接粘贴。它们只是对现有 TUN 入站的单字段修改示例；修改前保存原值，测试结束后逐项恢复。

步骤一：只测试 DNS 是否参与故障

在 TUN 入站中暂时设置：

"dns_mode": "disabled"

重新启动并观察：是否还会出现相同的卡住现象、DNS 超时和无关直连停滞。若没有改善，恢复原值后进入路由检查；若有所改善，再把 dns_mode 改为 native 单独复测，最后才回到 hijack。官方文档说明，disabled、native 和 hijack 的处理方式不同，且启用 auto_route 时默认倾向使用 hijack。dns_mode 官方定义

步骤二：检查 DNS 地址是否与规则一致

如果配置显式设置了 dns_address，记录这些地址是否是当前 TUN 地址或规则实际要处理的地址。官方说明称，设置该字段后会配置对应的 hijack-dns 路由规则；因此，DNS 地址、DNS 劫持和路由规则要一起看，不能只改一个地址就下结论。dns_address 官方定义

步骤三：检查出站回环

如果日志显示 DNS 或代理出站反复进入 TUN，检查 route.auto_detect_interface、route.default_interface 或出站 bind_interface 是否指向真实物理网卡。一次只选择一种绑定方式进行测试，不要同时添加多个互相冲突的接口约束。

步骤四：Linux 再检查 auto_redirect

Linux 下，官方文档建议在启用 auto_route 时配合 auto_redirect；它使用 nftables 改善 TUN 路由，并说明可以减少 TUN 与 Docker 网桥的冲突。若系统同时使用 Docker、策略路由或自定义 nftables 规则，先保存现状，再暂时关闭相关自定义规则进行对照。auto_redirect 官方说明

步骤五：最后测试 strict_route

strict_route 会影响严格路由行为。官方文档指出，在 Windows 上它可能导致某些应用，例如 VirtualBox，在特定情况下无法正常工作；在 Linux 上也会改变部分不支持网络和绑定设备流量的处理方式。若启用它后出现虚拟机、局域网或特定应用异常，可暂时改为 false 做单变量对照，确认结果后再决定是否恢复。strict_route 官方说明

第三阶段：只有部分网页或下载卡住时检查 MTU

如果 TUN 能启动、DNS 也不再持续超时，但网页只能加载部分内容、连接建立后没有数据或下载中途停住，可以把 MTU 作为最后一项变量。先记录原值，再只修改 mtu，每次修改后测试同一个域名和同一个固定资源；不要把某个 MTU 数值当成所有网络的通用答案。

停止 TUN，保存原配置。
只降低或调整 mtu，不要同时改变 DNS、路由和节点。
重新启动，测试同一个网页、同一个域名解析和同一个下载资源。
如果没有改善，立即恢复原 MTU；如果改善，也要重复测试确认不是暂时性现象。

MTU 调整只能说明数据包路径可能存在兼容性问题，不能证明 DNS、节点或出口本身正常。

1.14.4 的 DNS 卡住个案：能确认什么，不能确认什么

截至 2026-10-27，公开的 sing-box Issue 4659 仍显示为开放状态。报告内容是：官方 sing-box 1.14.4 在 gVisor TUN 下，等待通过标准 SOCKS5 或 HTTP 出站建立 DNS 连接时，可能让无关直连流量停滞。报告环境明确写明为 Debian 12、Linux 6.1、amd64，且测试服务运行在隔离网络命名空间中。Issue 4659 原始报告

这只能证明一个特定环境中的公开复现报告，不能推出所有 1.14.4 用户都会遇到同一问题，也不能证明你的卡住一定由该 Issue 引起。若你的版本、TUN 栈、DNS 出站类型和日志现象都不同，应回到本文的通用排查顺序。该 Issue 页面没有给出已验证的通用修复结论，后续状态以发布方说明为准。

验证标准：什么结果才算排查有效

配置层：sing-box check 不再报告配置检查错误；这只代表配置检查通过。
接口层：启动日志显示 TUN 接口创建完成，Linux 的 ip link 或 Windows 的网络接口列表能看到对应接口。
路由层：启动前后能解释默认路由、策略路由和 TUN 路由的变化，没有不断新增的重复规则。
DNS 层：日志不再持续出现 DNS 建连超时或重复等待；nslookup 或 dig 的结果可以作为对照，但不能单独证明代理链路有效。
流量层：在客户端连接页或 debug 日志中看到测试连接进入预期出站。仅能打开一个普通网页，不能单独证明流量经过了 TUN。
回退层：恢复原配置后仍能停止 TUN，并让系统直连恢复；否则先处理残留接口或路由，不要继续叠加配置。

日志级别可临时设置为 debug，官方支持的级别包括 trace、debug、info、warn、error、fatal 和 panic。排查完成后应恢复为较低噪声的级别。官方日志配置文档

常见失败及对应动作

一启动 TUN 就断网：先停止 TUN并确认直连恢复，再检查接口、默认路由和启动日志；不要先更换节点。
关闭 DNS 劫持后恢复：这只是缩小到 DNS、DNS 出站、劫持地址或路由范围。按 disabled→native→hijack 的顺序逐项恢复，并保留每次日志。
sing-box check 通过但仍然无网：配置格式通过不等于 TUN、DNS、出站和路由可用，继续看接口、路由表和连接日志。
Linux 使用 Docker 后出现回环：对照 auto_route、auto_redirect 和 nftables 规则；一次只改变一个条件。
Windows 虚拟机或局域网设备异常：临时关闭 strict_route 做对照；如果恢复，记录具体应用和网络接口，再决定是否调整路由排除项。
运行一段时间后断流：保存断流前后的日志、ip route show table all 或 route print 输出，比较接口和路由是否发生变化。不要把个案 Issue 直接当成最终根因。

安全提醒与范围限制

本文是第三方使用指南，不是 sing-box 官方页面，也不代表任何客户端发布方。订阅链接、访问令牌、私钥、UUID、服务器地址和完整配置不要公开粘贴，也不要上传到不明的在线转换页面；分享日志前先删除凭据和个人路径。

本文只覆盖 Linux 与 Windows 的命令行和桌面排查。macOS、Android 的 VPN、系统权限、日志入口和网络接口可能不同，本文命令不应直接套用。Issue 4659 的复现环境是特定 Linux 隔离环境，不能外推到所有平台或版本；版本字段和修复状态请以当前发布方说明为准。

常见问题

sing-box TUN 卡住时，第一步要换节点吗？

不建议。先停止 TUN，确认直连网络恢复，再记录版本、首次报错、接口和路由变化。只有确认 TUN、DNS 和路由没有明显异常后，才适合单独测试节点。

sing-box 1.14.4 的 DNS 卡住问题是不是所有用户都会遇到？

不能这样判断。截至 2026-10-27，公开 Issue 4659 仍是特定环境下的开放报告，环境为 Debian 12、Linux 6.1、amd64 和 gVisor TUN。它不能证明所有 1.14.4 用户都会复现，页面也没有给出已验证的通用修复结论。

sing-box check 通过后为什么仍然没有网络？

sing-box check 主要用于配置检查。通过并不代表虚拟接口创建成功、DNS 出站可用、路由没有回环或测试流量确实进入 TUN，还需要结合启动日志、系统接口、路由表和连接记录判断。

关闭 DNS 劫持后恢复，是否说明 DNS 就是根因？

不能直接下这个结论。关闭 DNS 劫持后恢复，只能把范围缩小到 DNS 处理、DNS 出站、dns_address、路由规则或回环。应按 disabled、native、hijack 顺序逐项恢复，并每次只改一个变量。

能 ping 通 IP，是否就能证明 TUN 和 DNS 正常？

不能。ping 通常反映本机 ICMP 路径，不能单独证明代理出站、TUN 路由或 DNS 建连正常。应结合 nslookup 或 dig、客户端连接日志和系统路由表对照。