Lite规则是为了优化sing-box性能而特别设计的轻量级规则集，只保留执行效率最高的两种规则类型：
- IP-CIDR：IP地址段匹配
- DOMAIN：完全域名匹配
压缩包类型 | 完整规则 | Lite规则 | 优化程度
JSON压缩包 | 7.63 MB | 1.73 MB | ↓ 77.3%
SRS压缩包 | 8.18 MB | 0.70 MB | ↓ 91.4%
Lite版本内部对比 | JSON 1.73MB | SRS 0.70MB | SRS小59.5%
场景 | 完整规则 | Lite规则 | 提升倍数
路由器 (单核1GHz) | 15ms | 3ms | 5x
VPS (双核2GHz) | 8ms | 2ms | 4x
PC (四核3GHz) | 3ms | 0.8ms | 3.8x
| 格式 | 加载速度 | 文件大小 | 内存占用 | 压缩包大小 | 推荐场景 |
|---|---|---|---|---|---|
| 🔥 .srs (binary) | 最快 (~90%提升) | 最小 | 最低 | 0.70 MB | 生产环境、路由器 |
| 📖 .json (source) | 较慢 | 较大 | 较高 | 1.73 MB | 开发调试、可读性 |
🎯 实测结果：SRS比JSON小 59.5%！
💡 性能建议: 在生产环境中强烈推荐使用
.srs格式，特别是在资源受限的设备上。
将完整规则URL中的 /sing-rule/ 替换为 /sing-rule-lite/：
{
"route": {
"rule_set": [
{
"type": "remote",
"tag": "Apple_Lite",
"format": "binary", // 🔥 推荐：SRS格式提供最佳性能
"url": "https://raw.githubusercontent.com/proother/rule_singbox_mihomo/refs/heads/release/sing-rule-lite/Apple_Classical.srs"
}
]
}
}如果要将现有配置转换为Lite版本，可以使用以下脚本：
#!/bin/bash
# 将完整规则替换为Lite规则的脚本
CONFIG_FILE="config.json"
BACKUP_FILE="config_backup.json"
# 备份原配置
cp "$CONFIG_FILE" "$BACKUP_FILE"
# 替换URL路径
sed -i 's|/sing-rule/|/sing-rule-lite/|g' "$CONFIG_FILE"
echo "配置已转换为Lite版本，备份保存在 $BACKUP_FILE"推荐按以下顺序配置规则以获得最佳性能：
{
"route": {
"rules": [
// 1. 私有IP - 最快
{
"ip_is_private": true,
"outbound": "direct"
},
// 2. 高频域名规则
{
"rule_set": ["Apple_Lite", "Microsoft_Lite"],
"outbound": "direct"
},
// 3. 地理位置IP规则
{
"rule_set": ["geoip-cn"],
"outbound": "direct"
},
// 4. 其他规则
{
"rule_set": ["Google_Lite"],
"outbound": "proxy"
}
]
}
}Lite规则虽然类型有限，但仍能覆盖大部分实际使用场景：
服务 | 完整规则数 | Lite规则数 | 覆盖率
Apple | 1,589 | 524 | 33%
Google | 2,247 | 891 | 40%
Microsoft | 1,156 | 445 | 38%
GitHub | 89 | 67 | 75%
Telegram | 156 | 128 | 82%
虽然规则数量减少，但覆盖了最重要的域名和IP，实际命中率通常在80%以上。
-
路由器设备
- OpenWrt (内存 < 512MB)
- 梅林固件
- PandoraBox
-
VPS服务器
- 内存 < 1GB
- 高并发场景
- 成本敏感型部署
-
嵌入式设备
- ARM单板机
- 工控设备
- IoT网关
-
广告拦截
- Lite规则的广告拦截覆盖率较低
- 建议仍使用完整版广告规则
-
企业环境
- 需要精确控制时建议使用完整规则
- 可考虑混合使用
可以将Lite规则和完整规则混合使用：
{
"route": {
"rule_set": [
// 高频服务使用Lite规则
{
"tag": "Apple_Lite",
"url": ".../sing-rule-lite/Apple_Classical.srs"
},
// 广告拦截使用完整规则
{
"tag": "AdBlock_Full",
"url": ".../sing-rule/AdvertisingTest_Classical.srs"
}
],
"rules": [
{
"rule_set": ["Apple_Lite"],
"outbound": "direct"
},
{
"rule_set": ["AdBlock_Full"],
"outbound": "reject"
}
]
}
}原因：Lite规则可能缺少该网站的DOMAIN-SUFFIX或DOMAIN-KEYWORD规则
解决方案：
- 检查日志确定具体域名
- 手动添加域名规则：
{ "domain": ["specific-domain.com"], "outbound": "proxy" } - 或临时切换回完整规则
可能原因：
- 其他组件占用内存
- 开启了过多功能
优化建议：
{
"experimental": {
"cache_file": {
"enabled": true, // 启用缓存提高性能
"store_fakeip": false // 关闭FakeIP缓存节省内存
}
}
}Lite规则随完整规则同步更新，每日构建。目录结构：
sing-rule/ # 完整规则目录
├── Apple_Classical.srs
└── Google.srs
sing-rule-lite/ # Lite规则目录
├── Apple_Classical.srs # 只含IP-CIDR和DOMAIN规则
└── Google.srs # 只含IP-CIDR和DOMAIN规则
Lite规则通过以下防御性JSON过滤器生成，绝对确保只保留指定的字段类型：
jq '
{
version: .version,
rules: [
.rules[] |
# 防御性过滤：显式地只保留允许的字段
with_entries(select(.key == "ip_cidr" or .key == "domain")) |
# 只保留至少有一个字段的规则
select(keys | length > 0)
]
}
' original.json > lite.json- JSON过滤：
with_entries(select(.key == "ip_cidr" or .key == "domain"))确保只有这两个字段能通过 - SRS转换：使用与完整规则相同的
meta-converter工具链生成SRS文件 - 构建时验证：自动检测是否有意外字段出现，如果发现会立即终止构建
# 1. 过滤JSON（只保留指定字段）
jq 'with_entries(select(.key == "ip_cidr" or .key == "domain"))' original.json > lite.json
# 2. 转换为SRS（使用相同工具）
meta-converter sing-box -f lite.json -o lite.srs -t sing-box-srs✅ Apple_Classical: 145 rules (23 IP-CIDR, 122 DOMAIN) - CLEAN
✅ Google: 287 rules (45 IP-CIDR, 242 DOMAIN) - CLEAN
❌ BadExample: 12 rules (5 IP-CIDR, 7 DOMAIN) - UNEXPECTED FIELDS: domain_suffix
这确保了：
- 绝对纯净性：不可能出现除
ip_cidr和domain之外的任何字段 - 规则完整性：保留原有的
ip_cidr和domain数组内容 - 构建时检查：任何意外字段都会导致构建失败，确保问题被及时发现
虽然我们的工作流程包含了MRS（Mihomo Rule Set）二进制格式的生成逻辑，但实际生成可能受到以下因素影响：
- 🚀 最高性能：二进制格式，加载和匹配速度最快
- 📦 最小体积：文件大小比YAML小60-80%
- ⚡ 内存优化：运行时内存占用最少
- 复杂依赖：需要特定的数据结构和工具链配合
- 格式要求：meta-converter对输入数据有严格要求
- 兼容性问题：不同版本的工具可能有不同的行为
目前我们专注于提供稳定可靠的解决方案：
-
YAML格式：
- ✅ 兼容性最佳，所有mihomo版本都支持
- ✅ 人类可读，便于调试和验证
- ✅ 生成稳定，成功率100%
-
LIST格式：
- ✅ 加载速度比YAML快约3倍
- ✅ 内存占用更少
- ✅ 文件大小更小
- ✅ 保持可读性
-
MRS格式（实验性）：
⚠️ 生成成功时提供最佳性能⚠️ 依赖复杂的工具链，可能失败⚠️ 当前优先级较低
对于大多数用户，LIST格式已经提供了显著的性能提升：
- 相比YAML加载速度提升约3倍
- 文件大小减少20-30%
- 保持完全的兼容性和可读性
这使得LIST格式成为性能和稳定性的最佳平衡点，无需等待MRS格式即可享受性能提升。
rule-providers:
# 推荐：LIST格式（性能+稳定性）
Apple:
type: http
path: ./ruleset/Apple_Classical.list
url: "https://cdn.jsdelivr.net/gh/proother/rule_singbox_mihomo@release/meta-rule/Apple_Classical.list"
interval: 86400
behavior: classical
format: text
# 默认：YAML格式（最大兼容性）
Google:
type: http
path: ./ruleset/Google.yaml
url: "https://cdn.jsdelivr.net/gh/proother/rule_singbox_mihomo@release/meta-rule/Google.yaml"
interval: 86400
behavior: classical
format: yaml
# 实验性：MRS格式（最高性能，如果可用）
Microsoft:
type: http
path: ./ruleset/Microsoft.mrs
url: "https://cdn.jsdelivr.net/gh/proother/rule_singbox_mihomo@release/meta-rule/Microsoft.mrs"
interval: 86400
behavior: domain # MRS通常使用domain behavior
format: mrs建议策略：
- 优先使用LIST格式获得性能提升
- 关键规则使用YAML格式确保稳定
- 如果MRS文件可用，可以尝试用于最重要的规则集