#Bettbox v1.17.6 正式版发布
https://github.com/appshubcc/Bettbox/releases/tag/v1.17.6
- 通知栏网速显示功能回归(需在增强工具设置中手动开启)
- 更新Flutter3.44.0正式版及部分依赖项
- 更新Mihomo内核至最新Commits
- 新增代理页面搜索框支持搜索代理组名称
- 新增特定条件下支持自动显示子策略组icon图标#PR117@ AIsouler
- 修复自动显示icon后的顶部间距问题
- 优化桌面端托盘菜单亮屏锁开关同步逻辑
- 优化桌面端软件更新和首次开启时的代理组显示更新速度
- 优化安卓端网络切换后的主动打断连接逻辑
- 修复安卓端开机启动可能不生效的问题
- 修复部分场景下链式代理异常问题
https://github.com/appshubcc/Bettbox/releases/tag/v1.17.6
- 通知栏网速显示功能回归(需在增强工具设置中手动开启)
- 更新Flutter3.44.0正式版及部分依赖项
- 更新Mihomo内核至最新Commits
- 新增代理页面搜索框支持搜索代理组名称
- 新增特定条件下支持自动显示子策略组icon图标#PR117@ AIsouler
- 修复自动显示icon后的顶部间距问题
- 优化桌面端托盘菜单亮屏锁开关同步逻辑
- 优化桌面端软件更新和首次开启时的代理组显示更新速度
- 优化安卓端网络切换后的主动打断连接逻辑
- 修复安卓端开机启动可能不生效的问题
- 修复部分场景下链式代理异常问题
GitHub
Release v1.17.6 · appshubcc/Bettbox
注意: 部分小米&Android16+机型在更新APP前,需提前关闭VPN以防止系统Bug造成的网络锁死
通知栏网速显示功能回归(需在增强工具设置中手动开启)
更新Flutter3.44.0正式版及部分依赖项
更新Mihomo内核至最新Commits
新增代理页面搜索框支持搜索代理组名称
新增特定条件下支持自动显示子策略组icon图标#PR117@ AIsouler
修复自动显示ic...
通知栏网速显示功能回归(需在增强工具设置中手动开启)
更新Flutter3.44.0正式版及部分依赖项
更新Mihomo内核至最新Commits
新增代理页面搜索框支持搜索代理组名称
新增特定条件下支持自动显示子策略组icon图标#PR117@ AIsouler
修复自动显示ic...
❤10
May 22
#Bettbox v1.17.8正式版发布
https://github.com/appshubcc/Bettbox/releases/tag/v1.17.8
- 更新Mihomo内核至最新Commits
- 修复特定配置下代理组显示错误问题
- 优化为Windows端增加高性能UDS通信方案
- 优化安卓端快速断开连接逻辑&HY2节点推荐开启
- 规范Android应用启动遮罩体验&修复Hyperos动画异常@ AIsouler
-新增脚本覆写功能可选开关排除指定订阅
- 统一脚本页面开关和弹出卡片样式
- 修复Webdav同步时安卓端APP应用列表被覆盖问题
- 修复检查更新可能遇到的API限制问题并增加Fallback方案
- 修复安卓端部分场景下的网速通知更新问题
- 针对单个订阅的脚本覆写开关无需切换直接生效
https://github.com/appshubcc/Bettbox/releases/tag/v1.17.8
- 更新Mihomo内核至最新Commits
- 修复特定配置下代理组显示错误问题
- 优化为Windows端增加高性能UDS通信方案
- 优化安卓端快速断开连接逻辑&HY2节点推荐开启
- 规范Android应用启动遮罩体验&修复Hyperos动画异常@ AIsouler
-新增脚本覆写功能可选开关排除指定订阅
- 统一脚本页面开关和弹出卡片样式
- 修复Webdav同步时安卓端APP应用列表被覆盖问题
- 修复检查更新可能遇到的API限制问题并增加Fallback方案
- 修复安卓端部分场景下的网速通知更新问题
- 针对单个订阅的脚本覆写开关无需切换直接生效
GitHub
Release v1.17.8 · appshubcc/Bettbox
注意: 部分小米&Android16+机型在更新APP前,需提前关闭VPN以防止系统Bug造成的网络锁死
更新Mihomo内核至最新Commits
修复特定配置下代理组显示错误问题
优化为Windows端增加高性能UDS通信方案
优化安卓端快速断开连接逻辑&HY2节点推荐开启
规范Android应用启动遮罩体验&修复Hyperos动画异常@ AIsouler
新增脚本...
更新Mihomo内核至最新Commits
修复特定配置下代理组显示错误问题
优化为Windows端增加高性能UDS通信方案
优化安卓端快速断开连接逻辑&HY2节点推荐开启
规范Android应用启动遮罩体验&修复Hyperos动画异常@ AIsouler
新增脚本...
❤14🥰1
May 24
#Bettbox v1.17.10正式版发布
https://github.com/appshubcc/Bettbox/releases/tag/v1.17.10
主要更新
- Upgrade mihomo core v1.19.26
- Update zashboard v3.6.0
- 修复: Linux arm64环境下的JS覆写脚本可用性问题
- 修复: 因Windows任务栏Bug可能引发的托盘菜单消失
- 修复: 特定类型下的DIRECT流量被错误统计到代理流量
- 修复: Linux和macOS因路径问题可能引起的TUN启动失败
- 修复: 安卓端从通知栏进入APP前台未能触发Resume状态更新
- 修复: 规范macOS窗口初始化逻辑并移除最低版本判断
- 变更: 移除macOS端flutter_acrylic插件修复渲染错误
- 修复: 列表页模式下右侧滚动条滞后的高度计算问题
- 修复: 规范化停止服务时的处理逻辑以解决Defender误报行为
- 修复: 在面板节点变化后仅同步Selector类型的代理组
- 优化: Windows端系统代理开启时默认勾选绕过本地设置
- 优化: 使用302跳转检测更新防止可能遇到的API限制
- 优化: 简化JS脚本执行后的资源释放逻辑
- 优化: 前台刷新时自动同步外部面板选择数据
- 优化: 针对Android TV设备使用传统启动方式
- 优化: 前台刷新时自动同步外部Zashboard面板选择数据
- 优化: 针对配置Url导入失败时的本地化提示并附带清晰HTTP错误码
- 优化: 安卓端仅针对冷启动APP显示应用遮罩并简化侧滑返回逻辑
- 优化: 简化更新代理组代码结构并统一调用入口
- 优化: 简化页面结构并移除设置中多余的侧滑条包裹
- 优化: Windows端避免在窗口不可见时发送WM_SIZE消息
- 优化: 安卓端启动遮罩图片更换为SVG格式@ AIsouler
- 新增: 安卓端通知组件启用状态缓存并移除重复的判断逻辑
- 变更: 移除Windows平台下TUN和系统代理的互斥逻辑
- 变更: 统一Tunnel设置中暂无数据时的居中显示
- 变更: 移除代理页面默认延迟测试并发数量限制
- 新增: 安卓端适配CMFA的应用列表剪切板导出格式
- 变更: 规范浅色图标文字以及修正部分俄语翻译@ HarwoodKinnav
- 其他细节变更
https://github.com/appshubcc/Bettbox/releases/tag/v1.17.10
主要更新
- Upgrade mihomo core v1.19.26
- Update zashboard v3.6.0
- 修复: Linux arm64环境下的JS覆写脚本可用性问题
- 修复: 因Windows任务栏Bug可能引发的托盘菜单消失
- 修复: 特定类型下的DIRECT流量被错误统计到代理流量
- 修复: Linux和macOS因路径问题可能引起的TUN启动失败
- 修复: 安卓端从通知栏进入APP前台未能触发Resume状态更新
- 修复: 规范macOS窗口初始化逻辑并移除最低版本判断
- 变更: 移除macOS端flutter_acrylic插件修复渲染错误
- 修复: 列表页模式下右侧滚动条滞后的高度计算问题
- 修复: 规范化停止服务时的处理逻辑以解决Defender误报行为
- 修复: 在面板节点变化后仅同步Selector类型的代理组
- 优化: Windows端系统代理开启时默认勾选绕过本地设置
- 优化: 使用302跳转检测更新防止可能遇到的API限制
- 优化: 简化JS脚本执行后的资源释放逻辑
- 优化: 前台刷新时自动同步外部面板选择数据
- 优化: 针对Android TV设备使用传统启动方式
- 优化: 前台刷新时自动同步外部Zashboard面板选择数据
- 优化: 针对配置Url导入失败时的本地化提示并附带清晰HTTP错误码
- 优化: 安卓端仅针对冷启动APP显示应用遮罩并简化侧滑返回逻辑
- 优化: 简化更新代理组代码结构并统一调用入口
- 优化: 简化页面结构并移除设置中多余的侧滑条包裹
- 优化: Windows端避免在窗口不可见时发送WM_SIZE消息
- 优化: 安卓端启动遮罩图片更换为SVG格式@ AIsouler
- 新增: 安卓端通知组件启用状态缓存并移除重复的判断逻辑
- 变更: 移除Windows平台下TUN和系统代理的互斥逻辑
- 变更: 统一Tunnel设置中暂无数据时的居中显示
- 变更: 移除代理页面默认延迟测试并发数量限制
- 新增: 安卓端适配CMFA的应用列表剪切板导出格式
- 变更: 规范浅色图标文字以及修正部分俄语翻译@ HarwoodKinnav
- 其他细节变更
GitHub
Release v1.17.10 · appshubcc/Bettbox
注意: 部分小米&Android16+机型在更新前,需提前手动关闭VPN以防止系统问题造成的网络锁死
Upgrade mihomo core v1.19.26
Update zashboard v3.6.0
修复: Linux arm64环境下的JS覆写脚本可用性问题
修复: 因Windows任务栏Bug可能引发的托盘菜单消失
修复: 特定类型下的DIRECT流量被错误统计到代理流量...
Upgrade mihomo core v1.19.26
Update zashboard v3.6.0
修复: Linux arm64环境下的JS覆写脚本可用性问题
修复: 因Windows任务栏Bug可能引发的托盘菜单消失
修复: 特定类型下的DIRECT流量被错误统计到代理流量...
❤6
June 1
很久没更新过锐评系列了，Xray在新版中强制加入2026.6.1日起取消对allow insecure的支持，说白了就是不再支持无条件绕过安全证书验证
对于自建用户来说这不是个难事，自签名也可以很方便通过证书锁定SSL Pining来解决，机场用户则只能等待服务端支持
简单说说我的看法，你要问我支不支持，我是支持的，这没啥毛病，上游内核的强制更改希望可以反推机场主重视安全性，不是坏事，但是最终结果和推进进度就不好说了，因为这种情况下，机场用户得到的回复很可能是：推荐用户换个客户端，多年下来几乎做为半官方客户端的V2rayN&G：似乎我比较受伤。。
对于自建用户来说这不是个难事，自签名也可以很方便通过证书锁定SSL Pining来解决，机场用户则只能等待服务端支持
简单说说我的看法，你要问我支不支持，我是支持的，这没啥毛病，上游内核的强制更改希望可以反推机场主重视安全性，不是坏事，但是最终结果和推进进度就不好说了，因为这种情况下，机场用户得到的回复很可能是：推荐用户换个客户端，多年下来几乎做为半官方客户端的V2rayN&G：似乎我比较受伤。。
🔥14❤3👍2
June 1
前台流畅丝滑、后台省电无感，致力于成为体验更好且可长期稳定运行的 Mihomo 客户端
以上是Bettbox在Readme开头其中一段描述，如图，刚好群里有人在问，本着自己也需要记录一下的原则，这里稍微展一下，为什么敢这么说
1.关于前台流畅，本项目Fork自早期的FlClash，而FlClash则是参考Hiddify来做的多平台客户端，hiddify的一些逻辑和代码可能是因为时间或其他原因，并没有效利用起Flutter现有的内置组件，而是大多数单独造轮子(一些单纯是因为当时Flutter官方还不支持)，以现在的眼光来看，结果就是有些页面性能低下，滚动和滑动也不流畅，没有发挥出设备本身的性能，Bettbox做了哪些工作呢，无论是Android还是各个平台的桌面端，针对现有绝大部分的列表页，滑动体验，首页小部件以及弹出动画部分等等全部进行高性能重构，想法思路则是更多利用起Flutter自身组件来实现更加高效的前台页面显示，其中Android端完美适配设备自身高帧率，这就是一些人觉得为什么更加流畅的原因
省电部分，请看下文
👍13
June 1
书接上回
2.关于后台省电，首先你可能经常会听到一种言论，都是Mihomo内核，GUI就一个壳子能有啥区别？准确的说这句话只在同个APP且运行逻辑一致的特定情况下成立，桌面端Windows可能感觉不出来，但是有些Macbook用户看电量数据应该感觉明显，至于Android就更不用多说，废话不多说，Bettbox如何在增加了更多功能和细节的情况下做到更加省电，相比原版的主要区别
首先每个新能功能和页面以及动态部分均考虑到了内存控制，不要扯什么内存就是拿来用的，同样的功能和运行情况下，更低内存代表更低消耗这是铁律，其次当后台运行的时候，APP会向内核和系统本身请求低内存运行(这个说法并不十分严谨，但是因为篇幅原因你可以这样理解)，同时做到了除内核本身以外的其他动态组件部分尽量处于静止状态，在不杀UI的情况下做到了等同于一些APP杀UI进程的轻量模式，这意味着更少的CPU/GPU消耗。同时关键的一点Bettbox延续了早期FlClash安卓版本的统一进程，内核与APP本身处在同一个进程自然少去了对应的通信调用开销(得益于内核本身的优秀稳定性以及APP稳定性优化，单进程的缺点在这里并不复存在)，一句话，更低的内存占用和通信开销，更稳定且更少的后台CPU/GPU占用，自然也就更省电
因为字数原因，这里只讲了主要逻辑，细节部分没办法摊开说透，不过对于需要想了解的人也够了，最后趁着这个机会，我将会在ColorOS16上面做一次为期7天的Bettbox后台耗电量测试，同时也可以展示一下Mihomo内核的超强稳定性，168小时后出结果，如图，如果CPU平均占用AVG 依然可以维持在1%以下，请说一句Bettbox NB! Mihomo YYDS!
2.关于后台省电，首先你可能经常会听到一种言论，都是Mihomo内核，GUI就一个壳子能有啥区别？准确的说这句话只在同个APP且运行逻辑一致的特定情况下成立，桌面端Windows可能感觉不出来，但是有些Macbook用户看电量数据应该感觉明显，至于Android就更不用多说，废话不多说，Bettbox如何在增加了更多功能和细节的情况下做到更加省电，相比原版的主要区别
首先每个新能功能和页面以及动态部分均考虑到了内存控制，不要扯什么内存就是拿来用的，同样的功能和运行情况下，更低内存代表更低消耗这是铁律，其次当后台运行的时候，APP会向内核和系统本身请求低内存运行(这个说法并不十分严谨，但是因为篇幅原因你可以这样理解)，同时做到了除内核本身以外的其他动态组件部分尽量处于静止状态，在不杀UI的情况下做到了等同于一些APP杀UI进程的轻量模式，这意味着更少的CPU/GPU消耗。同时关键的一点Bettbox延续了早期FlClash安卓版本的统一进程，内核与APP本身处在同一个进程自然少去了对应的通信调用开销(得益于内核本身的优秀稳定性以及APP稳定性优化，单进程的缺点在这里并不复存在)，一句话，更低的内存占用和通信开销，更稳定且更少的后台CPU/GPU占用，自然也就更省电
因为字数原因，这里只讲了主要逻辑，细节部分没办法摊开说透，不过对于需要想了解的人也够了，最后趁着这个机会，我将会在ColorOS16上面做一次为期7天的Bettbox后台耗电量测试，同时也可以展示一下Mihomo内核的超强稳定性，168小时后出结果，如图，如果CPU平均占用AVG 依然可以维持在1%以下，请说一句Bettbox NB! Mihomo YYDS!
👍66❤1😢1
June 1
Forwarded from ⬇️ 𝘼𝙥𝙥𝙨𝙝𝙪𝙗 𝘾𝙝𝙖𝙣𝙣𝙚𝙡
Windows平台使用Bettbox的十大理由
1.不用操心TUN需不需要管理员权限，也不用管防火墙防不防火，因为Bettbox已经将这些烦人的工作提前处理，只需要导入订阅使用
2.延续FlClash项目(此处Respect) 开源，免费，无广告，无私货，可放心介绍他人使用。新装系统也不用顾虑缺这个库少那个dll，不用顾虑各种强大的内核功能如何设置，因为这也已提前处理，开箱可用
3.内核与GUI之间使用UDS(Unix Domain Sockets)高性能通信，无需操心系统端口抢占问题，老旧系统自动平滑回退TCP方案，CPU分级优化，高性能列表/动画UI渲染等，榨干硬件性能
4.原生Windows arm64现已全面支持，提前为接下来(可能到来)的Win On Arm时代打好基础。同时强迫症也不用担心注册表和垃圾文件遗留，因为卸载程序会干净彻底的进行清理，方便你无后无后顾地体验或切换其他客户端
5.跨平台体验一致，Android 端、macOS 以及 Linux同款使用习惯和全功能支持，大量打磨的人性化设计，仅熟悉多个客户端，不如先熟练深耕掌握其中一个
6.智能启停功能(多平台)支持，无论你是ThinkPad还是RedmiBook，都能实现和(家里或公司)的智能路由系统的无缝代理接力与网络切换，仅需设置一次，后续便无需手动干预
7.首个Windows系统上讨厌的NCSI网络地球图标修复，更加健壮的开机/延迟启动，亮屏锁小工具，以及重新打造的中英双语言版本的UWP应用回关豁免工具等等
8.前台体感流畅，无需WebView也不依赖Chromium，前台以及长期后台低占用甚至0% CPU/GPU消耗，这不仅证明它不会在后台偷偷挖矿，重要的是，它可以省下更多的计算资源供你的前台工作应用使用
9.标准的安装程序目录设计以及规范的管理员权限调用，提前考虑的安全方案，通过Sha256签名验证(以及部分类Filelock 机制)来保障内核安全启动不被篡改
10.为长久稳定运行考虑，无论是7*24小时运行的AI生产力主机，还是像笔者一样从不关机的笔记本，Bettbox(及Mihomo内核)都能轻松应对
PS: 以上大部分也同样适用于macOS以及Linux客户端
1.不用操心TUN需不需要管理员权限，也不用管防火墙防不防火，因为Bettbox已经将这些烦人的工作提前处理，只需要导入订阅使用
2.延续FlClash项目(此处Respect) 开源，免费，无广告，无私货，可放心介绍他人使用。新装系统也不用顾虑缺这个库少那个dll，不用顾虑各种强大的内核功能如何设置，因为这也已提前处理，开箱可用
3.内核与GUI之间使用UDS(Unix Domain Sockets)高性能通信，无需操心系统端口抢占问题，老旧系统自动平滑回退TCP方案，CPU分级优化，高性能列表/动画UI渲染等，榨干硬件性能
4.原生Windows arm64现已全面支持，提前为接下来(可能到来)的Win On Arm时代打好基础。同时强迫症也不用担心注册表和垃圾文件遗留，因为卸载程序会干净彻底的进行清理，方便你无后无后顾地体验或切换其他客户端
5.跨平台体验一致，Android 端、macOS 以及 Linux同款使用习惯和全功能支持，大量打磨的人性化设计，仅熟悉多个客户端，不如先熟练深耕掌握其中一个
6.智能启停功能(多平台)支持，无论你是ThinkPad还是RedmiBook，都能实现和(家里或公司)的智能路由系统的无缝代理接力与网络切换，仅需设置一次，后续便无需手动干预
7.首个Windows系统上讨厌的NCSI网络地球图标修复，更加健壮的开机/延迟启动，亮屏锁小工具，以及重新打造的中英双语言版本的UWP应用回关豁免工具等等
8.前台体感流畅，无需WebView也不依赖Chromium，前台以及长期后台低占用甚至0% CPU/GPU消耗，
9.标准的安装程序目录设计以及规范的管理员权限调用，提前考虑的安全方案，通过Sha256签名验证(以及部分类Filelock 机制)来保障内核安全启动不被篡改
10.为长久稳定运行考虑，无论是7*24小时运行的AI生产力主机，还是像笔者一样从不关机的笔记本，Bettbox(及Mihomo内核)都能轻松应对
PS: 以上大部分也同样适用于macOS以及Linux客户端
❤47👏3🎉1💯1
June 5
聊聊Mihomo的新功能Age Key(上)
首先，快速说下这是用来干嘛的，说白了就是用来加密(订阅)文件用的，使用了密钥对之后，只有当你有了Private key(下面统称为私钥)之后，才能打开由对应的Public key(一下统称为公钥)加密的(订阅)文件
事情的缘由大概是这样，某知名客户端CVR搞了一套叫CVD的东西出来，美其名曰: 环境恶劣，保护订阅，对抗封锁，以wwq为首的Mihomo内核组在看过方案之后对比嗤之以鼻，认为其方案不仅实现非常一般并且会导致用户失去了选择权，同时有泄露用户隐私或(硬件ID)被精准定位的风险等，具体细节请参见相关公开讨论，这里不开CVR吐槽大会，只看事情本身，篇幅原因也不做过多评价，了解即可
在上述事情的催化下，Mihomo在1.19.26版本发布还不满一周的情况下，火速更新到了1.19.27正式版并顺势推出了Age key功能，如果站在机场主的角度，订阅在国内平台传播被肆意抓取显然不是一件好事情，结合前面的介绍可以得出一个结论，Age Key(能)解决的最大的事情，还是订阅被公开抓取或者滥用的问题(以及个人可以使用Gist)，因为订阅文件被强制加密，只有你手里有私钥才能解开
(我认为的)常见的理想中的情况1: 机场使用公钥对订阅文件进行加密，后台面板应有对应的一键复制私钥(再次小科普一下，公+私是一对，所以叫做密钥对)，流程: 用户首先导入Url订阅，但是只有填写(复制后台面板的)正确的私钥后，订阅文件才能被正常解析打开。
另外一种情况2，则是由用户自己生成密钥对，把公钥填入机场后台面板后，然后再由机场加密下发，依然是只有填写(自己生成的)正确的私钥后，订阅文件才能被正常解析打开。
补充:情况3，用户自己生成密钥对，可以在导入订阅文件时，在header里主动带上请求头X-Age-Public-Key(公钥)，机场后端收到后，然后再(使用公钥)下发加密订阅，大致流程其实和情况2一致，这种方式可以免去用户再去机场面板后台操作，也更加适用于自己写配置添加Providers规则
首先，快速说下这是用来干嘛的，说白了就是用来加密(订阅)文件用的，使用了密钥对之后，只有当你有了Private key(下面统称为私钥)之后，才能打开由对应的Public key(一下统称为公钥)加密的(订阅)文件
事情的缘由大概是这样，某知名客户端CVR搞了一套叫CVD的东西出来，美其名曰: 环境恶劣，保护订阅，对抗封锁，以wwq为首的Mihomo内核组在看过方案之后对比嗤之以鼻，认为其方案不仅实现非常一般并且会导致用户失去了选择权，同时有泄露用户隐私或(硬件ID)被精准定位的风险等，具体细节请参见相关公开讨论，这里不开CVR吐槽大会，只看事情本身，篇幅原因也不做过多评价，了解即可
在上述事情的催化下，Mihomo在1.19.26版本发布还不满一周的情况下，火速更新到了1.19.27正式版并顺势推出了Age key功能，如果站在机场主的角度，订阅在国内平台传播被肆意抓取显然不是一件好事情，结合前面的介绍可以得出一个结论，Age Key(能)解决的最大的事情，还是订阅被公开抓取或者滥用的问题(以及个人可以使用Gist)，因为订阅文件被强制加密，只有你手里有私钥才能解开
(我认为的)常见的理想中的情况1: 机场使用公钥对订阅文件进行加密，后台面板应有对应的一键复制私钥(再次小科普一下，公+私是一对，所以叫做密钥对)，流程: 用户首先导入Url订阅，但是只有填写(复制后台面板的)正确的私钥后，订阅文件才能被正常解析打开。
另外一种情况2，则是由用户自己生成密钥对，把公钥填入机场后台面板后，然后再由机场加密下发，依然是只有填写(自己生成的)正确的私钥后，订阅文件才能被正常解析打开。
补充:情况3，用户自己生成密钥对，可以在导入订阅文件时，在header里主动带上请求头X-Age-Public-Key(公钥)，机场后端收到后，然后再(使用公钥)下发加密订阅，大致流程其实和情况2一致，这种方式可以免去用户再去机场面板后台操作，也更加适用于自己写配置添加Providers规则
👍22❤2🔥2
June 8
聊聊Mihomo的新功能Age Key(下)
接上文，看到这里，想必大部分是应该都能清楚这具体是什么功能了，准确的说它的目的不是用于反审查，也无法阻止相关人员获取真实节点信息，但是，在开源生态里，同时在保证用户隐私的情况下，可以让机场主们通过此功能来更好地解决最常见的国内订阅泄露问题，对于用户，则可以解决恶心的阅后即焚导致的不能更新流量信息的问题，这也算是一大进步。我认为wwq应在这个事情上再做一步顺便推广一下新标准，在询问之后本人表示并无这个想法，于是，我便献丑从简单科普的角度发文来介绍一下
讲真，本人对这个功能原本并不是很感冒(无它，只是自己确实用不到)，另外，虽然已被多为大佬/频道推荐，但Bettbox当前仍然属于非知名客户端，推动力有限，但Readme上标榜为Another Better Mihomo GUI，不能只嘴上说说，对内核该做的适配是一定要做的，截至发文前，Bettbox当前v1.18.0正式版多平台已全面支持Age加密订阅格式，以及本地密钥对生成(X25519)功能
最后，说了这么多，为了大家都别白忙活和标准落地(折腾嘛就要与时俱进)，同时做为首个多平台率先支持Age Key的Mihomo客户端，我们打算额外加点有意思的玩法，具体如下: 首个支持Age加密(满2年且无明显公开劣迹)的机场，可以免费获得Bettbox首个公开(Github以及群组/频道)推荐席位！有想法的老板们可以行动咯
(PS: Bettbox当前用户数量以日thousands增长，虽然目前和几十K Star的项目还比不了，但咱好歹也已经拒绝过好几个机场广告投放了，嘿嘿)
接上文，看到这里，想必大部分是应该都能清楚这具体是什么功能了，准确的说它的目的不是用于反审查，也无法阻止相关人员获取真实节点信息，但是，在开源生态里，同时在保证用户隐私的情况下，可以让机场主们通过此功能来更好地解决最常见的国内订阅泄露问题，对于用户，则可以解决恶心的阅后即焚导致的不能更新流量信息的问题，这也算是一大进步。我认为wwq应在这个事情上再做一步顺便推广一下新标准，在询问之后本人表示并无这个想法，于是，我便献丑从简单科普的角度发文来介绍一下
讲真，本人对这个功能原本并不是很感冒(无它，只是自己确实用不到)，另外，虽然已被多为大佬/频道推荐，但Bettbox当前仍然属于非知名客户端，推动力有限，但Readme上标榜为Another Better Mihomo GUI，不能只嘴上说说，对内核该做的适配是一定要做的，截至发文前，Bettbox当前v1.18.0正式版多平台已全面支持Age加密订阅格式，以及本地密钥对生成(X25519)功能
最后，说了这么多，为了大家都别白忙活和标准落地(折腾嘛就要与时俱进)，同时做为首个多平台率先支持Age Key的Mihomo客户端，我们打算额外加点有意思的玩法，具体如下: 首个支持Age加密(满2年且无明显公开劣迹)的机场，可以免费获得Bettbox首个公开(Github以及群组/频道)推荐席位！有想法的老板们可以行动咯
(PS: Bettbox当前用户数量以日thousands增长，虽然目前和几十K Star的项目还比不了，但咱好歹也已经拒绝过好几个机场广告投放了，嘿嘿)
GitHub
Release v1.18.0 · appshubcc/Bettbox
Fixes and improvements
具体变更参考最新Commits
Bettbox 正式版本发布
✈️ Telegram 社区交流
⬇️ Download / 下载链接
Note: For desktop CPUs from 2012 or earlier, please download the Compatible version
注意：桌面端2012年同期及之...
具体变更参考最新Commits
Bettbox 正式版本发布
✈️ Telegram 社区交流
⬇️ Download / 下载链接
Note: For desktop CPUs from 2012 or earlier, please download the Compatible version
注意：桌面端2012年同期及之...
👍36❤4
June 8
June 8
你的 Bettbox (Mihomo内核) 到底吃了多少内存？(上)
群里经常会看下以下言论:
1.Bettbox内存占用真低，只有FlClash的十分之一，怎么做到的，× Fake news
2.Bettbox这个内存显示有问题，和后台真实占用完全不一样，自欺欺人，× Fake news
3.这是Mihomo纯内核占用，属于不含APP的整体内存占用，有点对但不全对，× Fake news
下面我以最真实，最准确，最不忽悠的方式告诉你，这里的内存信息显示的到底是啥！
首先，Mihomo 内核是用Go语言写的，我们这里显示内存信息就是当前Go运行时的 HeapInuse堆内存+ StackInuse栈内存占用总和，Go运行时有数十种内存指标，我挑选出两个觉得最有用的，注意单词: inuse，也就是说正在被使用的，这是我个人认为比较有用的数值，可以快速判断当前内核运行压力以及是否遇到内存泄露，这两个英文指标看着吓人，其实在 Bettbox(Mihomo内核) 里，它们代表了两件事：
1. HeapInuse，你订阅的几百个节点、动辄几万条的分流规则、还有一些解析出来的 DNS 缓存等等，基本都在这里，当你的配置有待优化，这个数值就不会太低
2. StackInuse，你每打开一个网页、发一个请求，内核就会派出一个微型打工人Goroutine去帮你搬运或者转发数据，当你在看4K视频或者全速下载时会有上百个并发连接，这个数值就会随之升高
熟悉了内存信息显示的到底是什么之后，再来聊一下这个数值参考
1.正常的全ruleset配置，这个数值中度以及低度负载情况下，应在30M以内(通常在15M或更低)
2.高负载压力下如果数值在30-50M也属于正常情况，通常会在后面慢慢回落，如果内存持续居高不下，你需要检查一下配置是否有问题或者遇到泄露问题
3.同配置分流规则下，使用Geodata一定比MRS占用更高，这是正常情况
4.长按内存信息小部件，可以触发内核强制GC垃圾清理，因为绝大多数时候你并不需要这个，所以这个仅作为隐性功能提供
未完待续
群里经常会看下以下言论:
1.Bettbox内存占用真低，只有FlClash的十分之一，怎么做到的，× Fake news
2.Bettbox这个内存显示有问题，和后台真实占用完全不一样，自欺欺人，× Fake news
3.这是Mihomo纯内核占用，属于不含APP的整体内存占用，有点对但不全对，× Fake news
下面我以最真实，最准确，最不忽悠的方式告诉你，这里的内存信息显示的到底是啥！
首先，Mihomo 内核是用Go语言写的，我们这里显示内存信息就是当前Go运行时的 HeapInuse堆内存+ StackInuse栈内存占用总和，Go运行时有数十种内存指标，我挑选出两个觉得最有用的，注意单词: inuse，也就是说正在被使用的，这是我个人认为比较有用的数值，可以快速判断当前内核运行压力以及是否遇到内存泄露，这两个英文指标看着吓人，其实在 Bettbox(Mihomo内核) 里，它们代表了两件事：
1. HeapInuse，你订阅的几百个节点、动辄几万条的分流规则、还有一些解析出来的 DNS 缓存等等，基本都在这里，当你的配置有待优化，这个数值就不会太低
2. StackInuse，你每打开一个网页、发一个请求，内核就会派出一个微型打工人Goroutine去帮你搬运或者转发数据，当你在看4K视频或者全速下载时会有上百个并发连接，这个数值就会随之升高
熟悉了内存信息显示的到底是什么之后，再来聊一下这个数值参考
1.正常的全ruleset配置，这个数值中度以及低度负载情况下，应在30M以内(通常在15M或更低)
2.高负载压力下如果数值在30-50M也属于正常情况，通常会在后面慢慢回落，如果内存持续居高不下，你需要检查一下配置是否有问题或者遇到泄露问题
3.同配置分流规则下，使用Geodata一定比MRS占用更高，这是正常情况
4.长按内存信息小部件，可以触发内核强制GC垃圾清理，因为绝大多数时候你并不需要这个，所以这个仅作为隐性功能提供
未完待续
❤13👏1
June 16
你的 Bettbox (Mihomo内核) 到底吃了多少内存？(下)
为什么不使用整体内存显示
1.Bettbox安卓端为统一单进程架构，好处是效率高，但是相对应地，单纯显示内核占用成本也会比较高
2.Windows平台下进程管理器和APP获取到的数值本身也并不能做到完全统一，如果一致需要额外处理，且无必要
3.Bettbox(含Mihomo内核)无论是安卓端还是桌面端，整体占用足够低，与其操心整体占用不如更多关心当前配置以及核心真实运行状态
4.那些说故意显示更低数值自欺欺人的，如果要更低，直接meminfo*0.1314再显示岂不是更低？说话前先动动脑子
5.桌面端可以通过进程管理器，安卓端可以使用Scene或者查看整体RES或者使用Running Services Monitor 查看PSS等详细数据，当然也可以通过ADB
随便再说点别的相关
1.Bettbox安卓端当前已适配新的Android17&国内金标联盟后台内存优化标准要求(插一嘴，Android后台是根据进程优先级以及真实PSS来判定是否需要强制Kill相关进程，并非单纯看内存大小)
2.常识问题，前台和后台内存不可一概而论，你不能要求一个Flutter应用同时包含阴影动画，各种小部件和图标以及流畅列表的情况下在前台运行时只占用30M内存，这没有任何意义，本软件也不会为了前台省下那么一点点内存而去砍掉流畅性和显示效果
3.软件/APP目前自带轻量模式(没有设置和选项)，安卓端和桌面端在后台一段时间里，会自动配合回收内存和无用缓存，同时并不会影响到进程本身，再次打开的时候除了0.5S的恢复时间，你并不会有其他感觉
4.安卓端使用应用黑白名单占用会更低也更有效率，且不会遇到一些国内APP的兼容性问题，推荐开启
5.桌面端，TUN虚拟网络模式相比纯系统代理，内核大约会高出15-20M左右，这也是正常现象
6.DEBUG模式下，打开内核设置中的外部控制，访问http://127.0.0.1:9090/debug/pprof 可以看到一些原始信息，具体介绍参见:https://wiki.metacubex.one/api/#debug，如果遇到内存泄露的时候向内核提交ISSUE，这会有些用处，平时运行建议关闭DEBUG模式
为什么不使用整体内存显示
1.Bettbox安卓端为统一单进程架构，好处是效率高，但是相对应地，单纯显示内核占用成本也会比较高
2.Windows平台下进程管理器和APP获取到的数值本身也并不能做到完全统一，如果一致需要额外处理，且无必要
3.Bettbox(含Mihomo内核)无论是安卓端还是桌面端，整体占用足够低，与其操心整体占用不如更多关心当前配置以及核心真实运行状态
4.那些说故意显示更低数值自欺欺人的，如果要更低，直接meminfo*0.1314再显示岂不是更低？说话前先动动脑子
5.桌面端可以通过进程管理器，安卓端可以使用Scene或者查看整体RES或者使用Running Services Monitor 查看PSS等详细数据，当然也可以通过ADB
随便再说点别的相关
1.Bettbox安卓端当前已适配新的Android17&国内金标联盟后台内存优化标准要求(插一嘴，Android后台是根据进程优先级以及真实PSS来判定是否需要强制Kill相关进程，并非单纯看内存大小)
2.常识问题，前台和后台内存不可一概而论，你不能要求一个Flutter应用同时包含阴影动画，各种小部件和图标以及流畅列表的情况下在前台运行时只占用30M内存，这没有任何意义，本软件也不会为了前台省下那么一点点内存而去砍掉流畅性和显示效果
3.软件/APP目前自带轻量模式(没有设置和选项)，安卓端和桌面端在后台一段时间里，会自动配合回收内存和无用缓存，同时并不会影响到进程本身，再次打开的时候除了0.5S的恢复时间，你并不会有其他感觉
4.安卓端使用应用黑白名单占用会更低也更有效率，且不会遇到一些国内APP的兼容性问题，推荐开启
5.桌面端，TUN虚拟网络模式相比纯系统代理，内核大约会高出15-20M左右，这也是正常现象
6.DEBUG模式下，打开内核设置中的外部控制，访问http://127.0.0.1:9090/debug/pprof 可以看到一些原始信息，具体介绍参见:https://wiki.metacubex.one/api/#debug，如果遇到内存泄露的时候向内核提交ISSUE，这会有些用处，平时运行建议关闭DEBUG模式
❤13🤣1
June 16
Forwarded from ⬇️ 𝘼𝙥𝙥𝙨𝙝𝙪𝙗 𝘾𝙝𝙖𝙣𝙣𝙚𝙡
具体问题懒得细说了，见下图，也许是Android系统的某个VPN级暗坑，如何确定这个问题
1.首先，确认后台权限和通知栏等一切正常，同时后台进程并没有被杀掉
2.在开启外部控制的前提下，访问本地127.0.0.1:9090端口的(Zashboard)面板会卡住，同时APP后台正常但是内核却无法连接，进入前台后。马上又恢复正常
3.这并非是常规的系统杀后台或者简单的内核挂掉的问题，节点稳定性问题和杀后台问题也不在本次讨论范围内，不能一概而论
4.此版本可直接覆盖v1.18.0新版本，如果有遇到此类问题的小米OPPO三星系机型，建议后台运行测试3-5天来确认是否可以再复现 (推荐问题判定唯一方式见以上(2.))
5.截图前面的几张CMFA基本说明了这个是特定系统现象
专用修复测试版本下载地址: https://t.me/appshub_chat/161278
1.首先，确认后台权限和通知栏等一切正常，同时后台进程并没有被杀掉
2.在开启外部控制的前提下，访问本地127.0.0.1:9090端口的(Zashboard)面板会卡住，同时APP后台正常但是内核却无法连接，进入前台后。马上又恢复正常
3.这并非是常规的系统杀后台或者简单的内核挂掉的问题，节点稳定性问题和杀后台问题也不在本次讨论范围内，不能一概而论
4.此版本可直接覆盖v1.18.0新版本，如果有遇到此类问题的小米OPPO三星系机型，建议后台运行测试3-5天来确认是否可以再复现 (推荐问题判定唯一方式见以上(2.))
5.截图前面的几张CMFA基本说明了这个是特定系统现象
专用修复测试版本下载地址: https://t.me/appshub_chat/161278
Telegram
⬇️ 𝘼𝙥𝙥𝙨𝙝𝙪𝙗 𝘾𝙝𝙖𝙣𝙣𝙚𝙡 in 💬 𝘼𝙥𝙥𝙨𝙝𝙪𝙗 𝘾𝙝𝙖𝙩
Bettbox_v1.17.10_OPT.apk
这是之前并未发布的一个特殊版本，小米OPPO三星系列有相关问题的，可以直接覆盖安装尝试
这是之前并未发布的一个特殊版本，小米OPPO三星系列有相关问题的，可以直接覆盖安装尝试
❤8
June 18
Forwarded from ⬇️ 𝘼𝙥𝙥𝙨𝙝𝙪𝙗 𝘾𝙝𝙖𝙣𝙣𝙚𝙡
毕业论文: 如何在Mihomo DNS配置中简单高效地预防DNS泄露？
满分💯分(可适当说明思路)
具体要求如下:
0.不限DNS工作模式
1.禁止使用全局代理
2.不依赖任何现有域名规则
3.确保国内主流域名可精准解析(享受国内CDN加速)
注: 本测试为开卷考试，答题格式以及DNS相关配置参考如下:https://wiki.metacubex.one/config/dns/
满分💯分(可适当说明思路)
具体要求如下:
0.不限DNS工作模式
1.禁止使用全局代理
2.不依赖任何现有域名规则
3.确保国内主流域名可精准解析(享受国内CDN加速)
注: 本测试为开卷考试，答题格式以及DNS相关配置参考如下:https://wiki.metacubex.one/config/dns/
❤11
June 20
https://t.me/appshub_channel/296
接上文娱乐性节目，最终群友@sueoff 率先以100分的成绩拿下毕业论文(https://t.me/appshub_chat/164035)，@SatenRuiko_AC 和另外一个未发配置的群友以95分的成绩摘得榜眼(扣掉的5分是因为自己发现并提出了问题，但是并未解决)。拆解相关思路如下:
1.既然要求国内DNS不可泄露且不可使用域名规则，所以nameserver一定要是国外DNS
2.既然是国外DNS那么想要国内相对精准的解析就一定要强制指定ECS
3.既然群友考虑到了UDP，那UDP也当然是要精准解析的，所以最终Fallback也是必须的
4.无论是redir-host还是fake-ip，在配置中都没那么重要，因为常规连接请求下Mihomo在这两种模式里发送给远端的都是域名
最常见解析流程示例:
1.访问 taobao.com
由于指定了国内ECS，而常规大厂域名托管DNS均支持ECS，所以最终返回国内IP通过CNIP对比后，走DIRECT，正确
提示: 类似 taobao.com这种全球域名，如果不强制国内ECS的情况下，最终反馈的将一定是国外IP
2.访问 youtube.com，默认UDP(QUIC)下
指定国内ECS的8.8.8.8会返回香港或者较近地区的IP，此时Mihomo经过Fallback-filter中的GEOIP: CN对比后发现并非国内IP，然后会使用Fallback DNS重新解析，最终得到正确远端IP实现国外精准解析(注意: Fallback DNS和Nameserver并非完全同步发起查询，而是对比Fallback-filter后再发起Fallback)
提示: 非UDP连接情况下，此时Fallback为非必须，上面说到，指定国内ECS的8.8.8.8会返回香港或者较近地区的IP，此时无论是fake-ip还是redir-host，都可以实现精准解析，因为最终Mihomo发给远端的是域名而非IP，所以即使返回了香港IP，你的美国VPS一样可以实现精准解析
其他相关，不考虑国外UDP的情况下，如果设备为固定台式电脑，仅仅只需要指定当前地区运营商的IP段(即配置中指定测国内精准ECS后的8.8.8.8)，即可实现国内外主流域名精准解析，direct-nameserver和Fallback均为非必须。如果是移动设备则需要配置direct-nameserver，如果考虑国外UDP连接则需要配置Fallback
最后，Mihomo的DNS非常灵活强大，具体玩法也是多种多样，同时，此配置也并非推荐日用配置(有相关域名规则干嘛不好好利用呢)，而是因为我看到群友搞的Mihomo内核考试题目(传送门)随兴而发，以上思路仅作为内核DNS相关功能科普
接上文娱乐性节目，最终群友@sueoff 率先以100分的成绩拿下毕业论文(https://t.me/appshub_chat/164035)，@SatenRuiko_AC 和另外一个未发配置的群友以95分的成绩摘得榜眼(扣掉的5分是因为自己发现并提出了问题，但是并未解决)。拆解相关思路如下:
1.既然要求国内DNS不可泄露且不可使用域名规则，所以nameserver一定要是国外DNS
2.既然是国外DNS那么想要国内相对精准的解析就一定要强制指定ECS
3.既然群友考虑到了UDP，那UDP也当然是要精准解析的，所以最终Fallback也是必须的
4.无论是redir-host还是fake-ip，在配置中都没那么重要，因为常规连接请求下Mihomo在这两种模式里发送给远端的都是域名
最常见解析流程示例:
1.访问 taobao.com
由于指定了国内ECS，而常规大厂域名托管DNS均支持ECS，所以最终返回国内IP通过CNIP对比后，走DIRECT，正确
提示: 类似 taobao.com这种全球域名，如果不强制国内ECS的情况下，最终反馈的将一定是国外IP
2.访问 youtube.com，默认UDP(QUIC)下
指定国内ECS的8.8.8.8会返回香港或者较近地区的IP，此时Mihomo经过Fallback-filter中的GEOIP: CN对比后发现并非国内IP，然后会使用Fallback DNS重新解析，最终得到正确远端IP实现国外精准解析(注意: Fallback DNS和Nameserver并非完全同步发起查询，而是对比Fallback-filter后再发起Fallback)
提示: 非UDP连接情况下，此时Fallback为非必须，上面说到，指定国内ECS的8.8.8.8会返回香港或者较近地区的IP，此时无论是fake-ip还是redir-host，都可以实现精准解析，因为最终Mihomo发给远端的是域名而非IP，所以即使返回了香港IP，你的美国VPS一样可以实现精准解析
其他相关，不考虑国外UDP的情况下，如果设备为固定台式电脑，仅仅只需要指定当前地区运营商的IP段(即配置中指定测国内精准ECS后的8.8.8.8)，即可实现国内外主流域名精准解析，direct-nameserver和Fallback均为非必须。如果是移动设备则需要配置direct-nameserver，如果考虑国外UDP连接则需要配置Fallback
最后，Mihomo的DNS非常灵活强大，具体玩法也是多种多样，同时，此配置也并非推荐日用配置(有相关域名规则干嘛不好好利用呢)，而是因为我看到群友搞的Mihomo内核考试题目(传送门)随兴而发，以上思路仅作为内核DNS相关功能科普
Telegram
⬇️ 𝘼𝙥𝙥𝙨𝙝𝙪𝙗 𝘾𝙝𝙖𝙣𝙣𝙚𝙡
毕业论文: 如何在Mihomo DNS配置中简单高效地预防DNS泄露？
满分💯分(可适当说明思路)
具体要求如下:
0.不限DNS工作模式
1.禁止使用全局代理
2.不依赖任何现有域名规则
3.确保国内主流域名可精准解析(享受国内CDN加速)
注: 本测试为开卷考试，答题格式以及DNS相关配置参考如下:https://wiki.metacubex.one/config/dns/
满分💯分(可适当说明思路)
具体要求如下:
0.不限DNS工作模式
1.禁止使用全局代理
2.不依赖任何现有域名规则
3.确保国内主流域名可精准解析(享受国内CDN加速)
注: 本测试为开卷考试，答题格式以及DNS相关配置参考如下:https://wiki.metacubex.one/config/dns/
👍25❤4😁2
June 20
#Bettbox v1.18.1正式版发布
https://github.com/appshubcc/Bettbox/releases/tag/v1.18.1
主要更新:
- Upgrade Flutter 3.44.2 & Core
- 优化: 增强安卓端休眠状态恢复稳定性并移除冗余日志打印
- 优化: 拆分智能启停和快速响应开关逻辑不再互斥
- 优化: 更健壮的桌面端首次启动流程
- 修复: WebDAV URL中用户名含@时的认证解析
- 新增: Windows&Linux平台可选始终显示标题栏按钮
- 新增: 允许手动设置混合端口为0以强制关闭监听
- 新增: 更多&配置页面支持快捷后退及侧边栏返回父级功能
- 新增: 在线面板小部件打开链接时预先检测并自动跳转外部控制设置
- 新增: 检测新版本更新时自动识别当前平台后续可直链更新
- 变更: 统一默认Meta UA与Provider保持一致
- 新增: 内置MRS简易信息显示与支持
- 变更: 清理安卓端多余的严格路由开关选项
- 变更: Play商店域名映射现强制根据开关状态增加或删除
- 新增: 内核设置中外部控制选项支持自动填入密码打开
- 变更: 统一安卓端忽略电池优化授权状态显示
- 新增: 适配内核Age加密订阅功能并添加X25519密钥对快捷生成
- 优化: 安卓TV端底部导航栏简化并阻止对应焦点跳跃
- 新增: 为安卓TV适配后的Banner图片资源
- 修复: NTP/Sniffer等模块的覆写开关状态同步生效问题
- 修复: Windows系统睡眠唤醒后托盘和窗口可能出现的异常问题
- 修复: 安卓刘海屏模式下因挖孔摄像头导致的UI错位问题
- 其他细节变更
https://github.com/appshubcc/Bettbox/releases/tag/v1.18.1
主要更新:
- Upgrade Flutter 3.44.2 & Core
- 优化: 增强安卓端休眠状态恢复稳定性并移除冗余日志打印
- 优化: 拆分智能启停和快速响应开关逻辑不再互斥
- 优化: 更健壮的桌面端首次启动流程
- 修复: WebDAV URL中用户名含@时的认证解析
- 新增: Windows&Linux平台可选始终显示标题栏按钮
- 新增: 允许手动设置混合端口为0以强制关闭监听
- 新增: 更多&配置页面支持快捷后退及侧边栏返回父级功能
- 新增: 在线面板小部件打开链接时预先检测并自动跳转外部控制设置
- 新增: 检测新版本更新时自动识别当前平台后续可直链更新
- 变更: 统一默认Meta UA与Provider保持一致
- 新增: 内置MRS简易信息显示与支持
- 变更: 清理安卓端多余的严格路由开关选项
- 变更: Play商店域名映射现强制根据开关状态增加或删除
- 新增: 内核设置中外部控制选项支持自动填入密码打开
- 变更: 统一安卓端忽略电池优化授权状态显示
- 新增: 适配内核Age加密订阅功能并添加X25519密钥对快捷生成
- 优化: 安卓TV端底部导航栏简化并阻止对应焦点跳跃
- 新增: 为安卓TV适配后的Banner图片资源
- 修复: NTP/Sniffer等模块的覆写开关状态同步生效问题
- 修复: Windows系统睡眠唤醒后托盘和窗口可能出现的异常问题
- 修复: 安卓刘海屏模式下因挖孔摄像头导致的UI错位问题
- 其他细节变更
GitHub
Release v1.18.1 · appshubcc/Bettbox
❤27👏3👍1
June 22
推荐使用内置BundleMRS，以解决远程规则集&首次启动概率性卡住的问题
具体用法参见: https://wiki.metacubex.one/config/rule-providers/#path-in-bundle
小提示: 如果发现内置MRS里面没有相同的规则(完整列表见 https://github.com/MetaCubeX/meta-rules-dat/tree/meta )，用相近的先代替也可
例如一定要用fake-ip-filter.mrs，但是内置MRS的Geosite文件夹并没有对应的规则，那么配置里则可以直接先写上相近的
path-in-bundle: "geo/geosite/private.mrs"
先正常启动，后续根据配置时间即可正常更新
其他相关:
1.Bettbox当前版本已适配内置MRS支持，资源页面的Url当前仅用于UI占位使用(否则光秃秃的不太好看)，在没有新的玩法加入以前，目前BundleMRS.7z不可直接在线更新，也不需要更新
2.和CMFA不同的是，Bettbox内置的BundleMRS目前仅支持GeoIP和GeoSite，也就是说并无ASN，除非后续有人使用并且有相关ISSUE提交，不然不打算加入👀
具体用法参见: https://wiki.metacubex.one/config/rule-providers/#path-in-bundle
小提示: 如果发现内置MRS里面没有相同的规则(完整列表见 https://github.com/MetaCubeX/meta-rules-dat/tree/meta )，用相近的先代替也可
例如一定要用fake-ip-filter.mrs，但是内置MRS的Geosite文件夹并没有对应的规则，那么配置里则可以直接先写上相近的
path-in-bundle: "geo/geosite/private.mrs"
先正常启动，后续根据配置时间即可正常更新
其他相关:
1.Bettbox当前版本已适配内置MRS支持，资源页面的Url当前仅用于UI占位使用(
2.和CMFA不同的是，Bettbox内置的BundleMRS目前仅支持GeoIP和GeoSite，也就是说并无ASN，除非后续有人使用并且有相关ISSUE提交，不然不打算加入👀
❤9
June 23