sing-box项目中TUN接口下DNS查询失败问题解析

问题背景

在使用sing-box项目的TUN模式时，用户遇到了DNS查询失败的问题。当启用TUN接口时，DNS解析无法正常工作，而关闭TUN使用mixed接口则表现正常。这是一个典型的网络代理环境下DNS解析配置问题。

问题现象分析

从日志中可以观察到几个关键现象：

1. 大量DNS查询请求被定向到172.18.0.2:53（TUN接口的DNS服务器）
2. 这些查询都被路由到direct出站
3. 最终DNS查询没有得到有效响应

根本原因

经过分析，问题出在路由规则配置上。用户配置中存在两个关键错误：

1. DNS协议匹配规则("protocol": "dns")被放置在路由规则的前面，而没有先进行流量嗅探(sniff)
2. 在route规则中使用"any"来表示所有入站连接，这在TUN模式下会导致DNS查询被错误处理

解决方案

正确配置顺序

DNS协议匹配规则应该放在嗅探规则之后，确保流量先被正确分类：

"rules": [
    {
        "inbound": ["tun-in"],
        "action": "sniff"
    },
    {
        "protocol": "dns",
        "action": "hijack-dns"
    },
    // 其他规则...
]

明确指定入站连接

避免使用"any"来表示所有入站连接，应该明确指定具体的入站标签：

"rules": [
    {
        "inbound": ["tun-in", "mixed-in"],
        "action": "sniff"
    },
    // 其他规则...
]

配置建议

对于使用TUN模式的sing-box用户，建议采用以下最佳实践：

1. 明确区分入站连接：为TUN和mixed接口分别配置清晰的标签和规则
2. 合理的规则顺序：确保流量先被嗅探分类，再进行协议匹配
3. DNS服务器配置：为TUN接口配置专门的DNS服务器，避免与系统默认DNS冲突
4. 日志监控：开启debug级别日志，便于排查DNS查询路径

技术原理深入

在TUN模式下，所有网络流量（包括DNS查询）都会通过虚拟网络接口。sing-box需要正确识别并处理这些流量：

1. 流量嗅探：通过分析数据包内容识别协议类型
2. DNS劫持：将DNS查询重定向到配置的DNS服务器
3. 路由决策：根据规则决定DNS查询应该走直连还是代理

当规则顺序不正确时，DNS查询可能被错误地路由到无法响应的服务器，导致查询失败。

总结

sing-box的TUN模式提供了强大的网络流量控制能力，但也需要更精细的配置。通过调整规则顺序和明确指定入站连接，可以解决DNS查询失败的问题。这提醒我们在配置网络代理时，理解各组件的工作顺序和相互关系至关重要。