为什么要了解这个问题?
TUN 无网络可能是节点、语法、权限、DNS 或路由中的一个环节失败。先保存能恢复的状态,才适合逐项定位。
先关闭 TUN 对照原网络,验证节点,再检查当前版本配置、服务权限、DNS 与路由冲突;修复后同时测试目标应用、局域网和退出恢复。
如何处理这个问题?
按下面的顺序操作,每完成一步再进入下一步;已经确认的条件可以直接通过目录跳到对应环节。
步骤 1:恢复并记录对照状态
保存配置与脱敏日志,正常关闭 TUN,查看普通网络是否恢复。关闭后仍失败时,先查本地网络与其他连接工具,避免把所有问题归到 sing-box。
步骤 2:确认出站节点可用
用同一账号、节点和网络验证可用的代理入口。节点握手本身失败时,应先处理认证、地址或协议条件,TUN 路由再完整也不能建立坏掉的出站。
步骤 3:校验版本与配置语法
记录核心版本,按对应文档检查配置;使用核心时可执行 sing-box check -c config.json。语法通过只证明结构可读取,还要继续检查字段语义与连接情况。
步骤 4:检查虚拟接口权限
查启动日志是否创建接口、申请权限失败。图形客户端与直接运行核心的授权方式不同,按当前系统正常授权,不使用关闭全部系统保护的脚本。
步骤 5:核对 DNS 和出口路由
分辨域名解析错误、路由循环与握手错误。检查 DNS 请求和节点自身连接是否被错误地送回代理入口;用官方文档核对当前版本字段,每次只修改一处。
步骤 6:排除冲突并验证恢复
正常退出其他 VPN 后复测,再测试局域网与目标应用。确认修复后保存配置,退出 TUN 再验证网络恢复;仍失败时提供版本与脱敏对照日志。
完成后怎么判断?
目标应用和本地网络都按预期工作,启停可恢复,日志中的原错误消失。
不要为排查复制含个人令牌的配置到公共转换站或论坛。
官方资料与进一步核对
客户端菜单与平台条件可能变化,操作前核对对应开发者或平台说明。
把这个问题与下一步接起来
从连接问题继续定位到网络层和配置层
先保留报错与日志,再做同节点、不同网络或不同应用的对照;一次只改变一个条件。
记录目标请求是否完成与耗时,作为对照证据,而不是解锁结论。
判断是否只有特定网络、协议或时段失败,避免把全部超时直接归因于封锁。
核对配置结构与订阅格式,区分配置没有加载和节点无法建立连接。
与这个问题相关的文章
- sing-box TUN 是什么?什么时候需要开启?
先理解 TUN、路由与 DNS 的关系。
- Mac 开启 Clash TUN 后没网怎么办?
Mac 设备还需检查特定网络行为。
- Hysteria 2 连接超时怎么办?Hy2 节点为什么不能用?
Hy2 出站超时时核对 UDP 路径。