sing-box mixed 模式下的 DNS 解析问题

mixed 模式下，流量直接进入主路由进行分流，而不会进入 DNS 模块。

进入主路由后，默认不进行域名解析，就是域名走域名的规则判断，ip 走 ip 的规则判断。走远端代理的去远端机器上进行 dns 解析，走直连的域名才会开始进行域名解析，这个时候默认使用 dns 配置的第一个 server 。（当然你可以在路由规则的 default_domain_resolver 你可以指定使用哪一个 server ）

总之就是，mixed 模式下，DNS 里的路由规则似乎是没有用的。

已经弃坑 singbox 了，这软件和它的名字一样 sb 。每次大版本更新规则全变，每次小版本更新一堆 bug 哪哪突然就用不了了。文档写的和狗屎一样，反馈问题开发者还 bb 。

对了，这开发者默认是你会去看懂代码的。

sb

sb 运行效率很高得，建议钉死一个稳定版本使用。

这软件的乐趣不就是更新一个版本，改配置文件可以玩一天吗？

@Ipsum 服了。。。你说到痛点了。。

@daisyfloor #1 你黑都黑不到点上，大版本更新不兼容之前的配置并没有任何问题。这个软件作者傻逼的是每个小版本更新都是 破坏性更新，不兼容之前的配置。

短暂的用过一段时间，确实相比 clash 配置更合理，但是确实是问题不少，经常变动，提过一个 issue ，作者似乎也没啥心思理解我的问题就直接关了。

@FrankAdler 这作者堪称劳模啊，更新的非常频繁

支持一楼，提过一次反馈直接被关了

它的效率并没有比 mihomo 高很多，那点性能差距没有稳定性来的实际，我一直服务器用 xray ，客户端全平台都是 mihomo 的配置。

之前我用 ai 写了个 update.sh 每天更新最新版本，然后就发生了像上面说的版本一变，配置文件就要跟着改，特别是 dns ，主要问题是他文档 dns 写的很迷，绕来绕去的
现在 hy2 用的 https://github.com/apernet/hysteria ，vless 用的 xray ，每天自动更新版本，到现在都没问题

就 singbox 那注解一样的文档, 能看懂多少有点天才了. 小版本还经常引入破坏性更新. 没人能顶得住.
还有一些神奇的坚持, 例如不加入 provider.

sing-box 项目，用户提交的问题，如果作者知道问题在哪怎么解决，修复之前不进行任何回复，修复完了在群里接受大大修 bug 真快的吹捧；如果不知道问题在哪或暂时解决不了的，就直关 issue 或者踢群。同时永远在小版本改配置语法，协议看似集成丰富其实后续跟进有限。

说回 dns ，它的 dns 表现是无法预期的。同系统内在 53 端口部署的 mosdns 服务，sing-box tun 模式下设置 dns 地址为 local 或 127.0.0.1 （文档默认端口为 53 ）或 127.0.0.1 （显式配置端口 53 ），这三种表现都是不同的，离谱的是后两种按照文档是相同配置。所以 sing-box 现在只作备份方案

难怪我配置不好透明代理，不是我的问题，哈哈哈哈。

@shinyzhu 透明代理用 tun+fakeip ，但不代表下次更新个小版本还能正常用。

建议他别拿来当客户端
老实当服务端

千万别做 客户端.
服务端不错

@JensenQian 正解

一个版本用到底就行了，配置文件+二进制文件，全平台可用。
如果是 Linux 再开启 auto-redirect 做透明代理，性能一流，比 tproxy 更轻更快更简单。

服务端很好使，客户端用别的吧

确实，更新个中间版本很多破坏性更新，文档是最新版（ 1.12.X ），实际上 1.12.X 还没发布。真是蛋疼，又没有旧版的文档镜像，找文档好累，tg 问了个问题直接拉黑了

@paperseller 原来我被踢是因为这个，哈哈

@johnnyhao 我客户端用的 nekobox ，sing-box 内核的，看来又得研究换个了

@daisyfloor #1 不对吧，开启协议探测，检测到 DNS 协议就转发到 DNS 模块不就行了？

@0xD800 不需要手写配置啊，我都是用 Gemini 生成的脚本自动转换配置，或者可以用这个 https://sing-box-subscribe-doraemon.vercel.app/ 把机场订阅填写进去，选择 1.12 版就行了。
我用的 Gemini 生成的脚本
python sub_converter_final.py -u 机场 url
https://drive.google.com/file/d/1v3GHmmewKE-ilrswCuj3tkSvjY0Mc1le/view?usp=sharing

@0xD800 文档也不用看，直接让 Gemini 或者 Claude 去看提修改建议就行了，如果还是不行丢一个正确的 config 给 Gemini 它就能逆向出一个脚本。

@Ipsum 笑死我了还真是，不过人家就是 0.几也情有可原，等待它的 1.0 版本

看这个帖子实在是绷不住，只能说这个 clowwindy 说啥来着，这圈子好像十多年了也是这样也没变过。我觉得比起花时间研究这些软件还不如研究怎么润划算。

回答下 OP 的问题，HTTP 代理和 Socks 5/6 客户端都能够指示目的域名，因此客户端不会对域名做解析。对于这些代理软件的策略路由来说，通用的逻辑是在匹配 IP 规则前解析，具体策略因软件而异，有些是可配置的。

@Kairossaster 一部分吧，最主要的原因还是太忙了。

至今没学会怎么配置，摊手

@yolee599 在 TUN 模式下确实是你说的这个逻辑，但他说的是 mixed 模式。mixed 模式下流量直接进入路由分流。

@AkinoKaedeChan #27 还记得这事儿的，都是老网民了，确实这么多年一点没变：伸手党大骂“为爱发电”怎么不单独给我发电。哎！

@daisyfloor 可以在 inbounds 添加本地 port 监听 udp direct ，dns 模块在这个 port 设置一个 server ，把 route.default_domain_resolver 设置为这个 server ，然后这个入站设置 sniff

sing-box 是有一大堆问题，但是它又支持 Hysteria2 又支持 Tun 又支持 iOS ，我找不出第二家。

看起来还是热心人多，还在耐心解答。mixed 模式根据命中的 geoip ，geosite 路由走了，DNS 劫持不会生效，

要想处理 DNS 规则就要用 Tun 模式，配合 DNS 模块分流。

这个回复框很难用，碰到空白就提交了。不是 sing-box 垃圾，而是目标用户要有 JSON 基础，它作为一个通用代理平台如果用 GUI 填字段、拉选项配置开发上就很麻烦，它有几大模块，每个里面又有很多子模块自由组合，直接用 JSON 配置是有道理的，如果支持 yml 就更好，它支持注释。

那些骂 sing-box 的人也可以理解，滚动更新快速迭代新功能，在工程上舍弃旧的配置字段会让人不适应。但这是一个开源项目，不是付费软件，它没有义务全方位服务你，没有这层契约。开源的精神是共建共享，你为我，我为你，SS 原作者的意思是开源社区里有一大堆饭来张口，衣来伸手的白嫖党，什么都要满足于他，这不符合开源的目的，开源项目作者也不是教育使用开源的人怎么怎么样，而是你能力不够或是不理解代码文档，你就更努力学习这些，你会了可以选择写博客来分享如何配置，如何解决疑难杂症，有能力的就添砖加瓦建设开源项目，没能力的也不要过多抱怨，显得戾气纷纷。

sing-box 支持 JSONC 扩展，配置文件里可以写注释。
在 mixed 模式下，DNS 流量会在本地发起一次查询（因为 mixed 并不会劫持 53 端口），同时根据 rule 规则，远端代理也会再进行一次 DNS 解析。这样就导致了 DNS 泄露 。

关于协议探测，得先用 TUN 劫持全部流量才可以读取到包头进行协议类别判断 ，DNS 规则只有在 TUN 模式生效。

谢谢各位 ，我问了个很简单的问题 事后就想明白了

回到现实，写开源软件的人不是全职在干这个，他们有其他的事，人的精力是有限的，代码，测试，文档都需要人来做，不可能凭空就很完美，开源项目的赞助或打赏也没有几个人去做，反过来骂开发者或贡献者不合理，他们没有惹你。如果你和软件无缘换一个便是，大家都开心。

@Orzpls 其实不全是这个意思，这段话前面的部分不能忽略，有些 大 佬 确实喜欢一群人围着他转

sing-box 作者自己就对喷别的开源协议项目协议设计一坨 *，自身 issues 和文档的处理确实很狗屎 基本不采纳社区 patch 纯粹个人项目自己玩的开心

按文档示例配置，不会劫持 dns 吗？
```
{
"inbounds": [
{
"type": "mixed",
"tag": "in"
}
],
"route": {
"rules": [
{
"inbound": "in",
"action": "resolve",
"strategy": "prefer_ipv4"
},
{
"inbound": "in",
"action": "sniff",
"timeout": "1s"
}
]
}
}
```
在 sniff 后面加上
```
{
"protocol": "dns",
"action": "hijack-dns"
},
```

前两天刚把 1.10 养老设置花一天时间更新到 1.12 ，特么那个官网配置介绍如同猜谜，参数给你了，怎么用自己看着办。然后又有一堆参数要废在 1.13 和 1.14……要不是这 sb 整合各种协议，早放弃了……

@JensenQian 正解，累一点，把所有东西写好在服务端，千万别折腾客户端

@Michaol sing-box 配置 我基本拿着源码边写配置边调试

@sherlock2435 mixed 模式下，有且只有 direct 出站的域名会进行域名解析。如果你想用 ip 规则兜底比如域名规则没命中的再解析下域名得到 ip 再去匹配 ip 规则（ clash 默认就是这样），你得在路由的 ip 规则前加入一个 resolve 的 action ，并且 server 指定 google （ detour 走 proxy ） ，你不这样做的话。就不会有那一次为了匹配 ip 规则而进行的域名解析。

另外，我从来没遇到过 dns 泄露。因为 mixed 模式下，sing-box 就不会像 clash 那样做多余的本地 dns 解析。

@Qetuo233 太麻烦，这是给自己以后留下屎山代码的做法。你不知道它下面哪个版本什么时候会变更这些写法逻辑。

我改用 tun+fakeip 了简单很多。

我的原则是在实现功能的前提下，尽量的简化配置里的逻辑。

@Orzpls 不是说它的产品做到不好，产品确实牛逼。

而是说大家都想帮他解决问题、定位问题时候

而它的首先的反应是：我没有问题，然后把问题关掉或者改为 not plan ，离谱的是后面有时候它自己又偷偷改掉了。。

还有，你既然做通用代理平台，前段时间 xray 把 reality 服务端的 new session ticket 的严重漏洞修复了，你是不是也应该同步更新下？就是因为你想在 xray 那边 PR 你的 anyTLS 被拒了，然后 xray 系的东西就不更新了？？

回到你的回答，你说就新手就更努力的“学习这些，添砖加瓦等等”，你自己看看 SB 作者怎么建议新手的：
https://github.com/SagerNet/sing-box/issues/3251 （最后一条回复）

它默认的意思就是如果你不会看代码（不懂），你就不配参与讨论甚至是提出问题。

说的好听一点是通用代理平台，说得难听一点就是缝合怪，只不过缝得手艺还不错。

没什么好装逼的。拿出来让人用，就别玻璃心经不起吐槽。

@daisyfloor 通过路由规则将流量 detour 到代理进行解析，和使用 DNS 规则路由的最终效果看起来类似域名都会经由代理解析， 这样的话 DNS 规则路由一般用于哪些特殊场景

@sherlock2435 #51 用于任何代理软件需要获得 DNS 解析结果的场景，包括策略路由对 IP 的匹配、direct 出口。

@sherlock2435 “通过路由规则将流量 detour 到代理进行解析” 是非必要不进行的。因为本身要走代理的流量，最终在代理节点上出去，放在代理节点完成域名解析并出站就是简单的。没必要提前进行解析。过多的 DNS 解析本身就是影响网络浏览体验。

我最终不用 mixed 了，使用 tun+fakeip ，这样每一个流量都会提前进行 dns 模块的解析，在 dns 规则里分流，如果是 cn 的域名就本地解析得到 ip 后用 ip 进路由走 ip 规则分流出站。 如果不是 cn 的，或者都返回 fakeip ，然后直接进路由分流。

这个是之前用 clash 时候的习惯。


其实 sing-box 和 clash 最大的不同确实是，sing-box 你可以按自己的需求随便写，同一个目的有多种实现方法。

这个怎么说呢，也好也不好。对于新手用户很不友好。

@sherlock2435 原本打算 1.10 安安静静用下去，无奈小朋友们的客户端会升级，现在 1.11 和 1.12 客户端连接到 1.10 服务端会出现大量迁移警告，其实不管这些警告也是能用的，只不过确实不好看而且吓人。另外主要是服务端写了 sniff 和 override_address 去解锁多地流媒体，1.12 把 override_address 从 outbound 挪去 route 了，不得不折腾。

只要机场订阅链接支持 sing-box ，客户端就用 OneBox 吧，别折腾了。

https://github.com/OneOhCloud/OneBox