这个目测是你没加加速代理和镜像站的原因导致的。
使用反馈，目前主路由ROS，遇到tg无法加载消息的情况，检查mosdns日志没有看到相关域名，判断是tg绕过了dns解析，直接走的IP直连。
解决方案，除了文档中的1.1.1.1和8.8.8.8外，还需要在主路由增加tg的ip段gateway指向
149.154.160.0/22
149.154.164.0/22
149.154.172.0/22
91.108.4.0/22
91.108.20.0/22
91.108.56.0/22
91.108.8.0/22
95.161.64.0/20
91.108.12.0/22
/ip route
add dst-address=91.108.4.0/22 gateway=你的msf地址 comment="TG"
谢谢，我会在 README 里添加对应的网段的。
能不能配置自己的 github token，检测更新全是 403 限流
你直接在命令行里登陆github不就行了。
不想折腾飞牛宿主机环境。还是拉下来自己改改吧
这个项目支持飞牛安装。愿意折腾可以看一下原理图，不愿意折腾就保留现在
感觉挺不错的，支持一下，dns设置，确实比网关设置更加的合理，优雅。
我怎么感觉和 shellclash 是一个思路呢，Mark 一下，回头拿 AI 分析下看看
各位佬友，MSF 回来更新了，v0.6.0 已正式发布。
前段时间我暂停了项目的公开发布，对仓库进行了比较彻底的代码、配置、界面素材和第三方来源审计。与其带着不清晰的历史继续迭代，我最终选择重新整理公开历史和发布基线，把能够说明来源、许可证和实现边界的材料尽可能补全后，再重新发布。
这不是简单换个版本号重新上传。
这次主要做了什么
- 重新整理干净的公开代码与发布基线；
- 对第三方代码、配置、规则和素材进行逐项来源及许可证记录；
- 当前 Go 后端和 React WebUI 继续作为独立实现维护；
- 全面重做登录、初始化、主框架、MosDNS、Mihomo、日志、配置和设置界面；
- 删除旧项目名称兼容入口、废弃页面、未使用图标及不可达代码；
- 增加 MosDNS 本地回环一键诊断，改善长列表、图表和代理页面性能；
- Linux、Docker、Unraid、fnOS、macOS 和 GHCR 镜像均从同一个干净的
v0.6.0Tag 构建； - 正式发布资产均提供 SHA-256 校验文件，前端
npm audit保持零已知漏洞。
根据当前逐文件审计记录，仓库中未发现 mssb 原有的 Shell/Python 程序源码，也未发现对其程序代码进行逐行翻译的情况。
共同使用的 MosDNS/Mihomo 字段、规则格式和必要处理流程，则按照共同上游、标准接口及功能约束进行区分，并记录相关来源。
当前支持平台
- Linux x86_64 / ARM64
- Docker TUN
- Unraid PLG
- fnOS x86 / ARM
- macOS 15–26 Universal 2（未签名 Beta，TUN only）
相关链接
项目地址：
v0.6.0 下载：
第三方来源与许可证：
UI 来源与实现边界记录：
另外说明一下：由于这次重新整理了公开历史和发布基线，仓库原先积累的 Star 没有保留下来。
如果你以前关注或 Star 过 MSF，并且仍然认可现在这个项目，欢迎重新点一次 Star；对我而言，实际部署反馈、Issue 和文档改进同样非常有帮助。
目前尤其希望收集 Docker、fnOS ARM 和 macOS TUN 环境的真实反馈。已经部署 v0.6.0 的佬友，遇到问题可以直接在本帖或 GitHub Issue 留言，我会继续处理。
仅限合法技术交流、不提供违法代理技术和节点。请只在自己拥有或已经获得管理授权的网络中使用。
1 Like
这个思路不是好几年前就有了吗。。一直用的 paopaodns 和 paopaogateway 没懂为啥要重复造轮子
MSF 与 PaoPaoDNS、PaoPaoGateway 面向相近的家庭网络场景，在 MosDNS、Mihomo、Fake-IP 和规则分流等基础能力上确实存在交集。但 PaoPaoDNS 偏递归 DNS，PaoPaoGateway 偏精简专用网关；MSF 的定位是提供统一、可审计、跨平台的 MosDNS + Mihomo 管理控制平面。它们是同赛道的不同实现和取舍，并不是同一项目的简单复制。
而且说个最简单的区别，我只需要开一个实例，所有的设置在一个网页上就解决了。paopao系列需要开两个实例。更何况重复造轮子的说法不准确，且不谈系统适配更多，你都没有用，你咋知道哪个更方便呢？如果便利性也是一种需求，那还算重复造轮子么？
更何况我从头到尾甚至连借鉴都没有借鉴过paopao系列的实现方式。
不懂你这么轻易的下结论对你有什么好处。
1 Like
拿一堆开源免费的东西糊在一起也好意思说赚钱啊，你和那些作者诗人啊。
那怎么不给开源免费的相关作者版权费啊？
1 Like
我是路人，你说这句什么意思，我没搞懂
我是用了，在nas上部署了，界面挺好看就是问题太多了；singbox没开发完却让mosdons监听111端口和NAS的冲突，手动改吧重启又被回复；有时候mosdns规则不生效
，还有待完善；
就是这个项目有参考过一个开源的项目，但是这个开源项目的作者，做了个闭源的产品。然后就来贴脸我说抄袭他。所以本质上来讲，这个玩意儿都是开源的，很多东西很难说有版权或者著作权的。
111端口暂时还是保留给singbox的，后期如果不做singbox才会解绑这个端口。如果后期做这个111端口的定义还要看情况才会开放给你们改。
你可以说我做的不成熟，本来这个东西做出来就是为了方便和美观的。你要说我做的不好我也认。毕竟才迭代到v0.6.4。
但是端口要放开给你们改。实现难度和程序逻辑的成本都要增加。我反正是不太倾向于放开的。
但是换句话说，你有能力你可以提PR，也不用在这嘴一张就是不好。
退一万步讲mosdns本来就是用111的，你既然用了，还不让我占用是什么道理，你不可以改nas的端口占用么？
我现在把111放开了，后面要再加回来，是不是又要有一大堆人反馈说用不了。你自己换位思考一下呢？