这个工具解决什么问题
玩过 Clash 或 Mihomo 的人都经历过这条「折腾链」：机场给了一个订阅链接，导入后节点名乱七八糟；想按地区分流，手动写代理组写到眼花；想把两三家订阅合并成一个，得靠各种在线转换网站，节点数据还得过第三方的手；想配链式代理，YAML 里一层套一层的 dialer-proxy 更是劝退。
SubBoost 把这条折腾链整条收进了 Web 界面。它是开源的（AGPL-3.0）Clash/Mihomo 订阅转换、增强和管理工具：你把订阅喂给它，它输出一份结构清晰、分流精确、带防泄露配置的聚合订阅，全程可视化点击完成。
核心能力一览
| 能力模块 | 干什么 | 替代了什么手工活 |
|---|---|---|
| 订阅转换 | 导入订阅链接、YAML 文件、节点链接 | 在线转换网站复制粘贴 |
| 订阅聚合 | 多个订阅合并成一份聚合订阅 | 手动拼 YAML |
| 节点管理 | 批量重命名、删除、配置监听端口 | 逐条改节点配置 |
| 节点筛选 | 按来源/地区/自定义规则生成筛选代理组 | 手写 filter 正则 |
| 链式代理 | 可视化一键配置链式代理和前置代理组 | 手写 dialer-proxy 嵌套 |
| 精确分流 | 30+ 常用代理组、2000+ 远程规则集 | 手抄别人的规则模板 |
| 防 DNS 泄露 | 默认基础配置 + DNS 配置 | 自己研究 fake-ip/redir-host |
| 自动刷新 | 定时刷新订阅，智能节点匹配 | 手动更新订阅 |
它在同类工具里的位置
订阅转换这个领域已有几个知名工具：老牌的 subconverter 是规则转换引擎，sub-store 侧重订阅管理。SubBoost 的差异点在「增强 + 管理」这一层——它不只做格式转换，而是把你导入的订阅变成一个可长期运营的资产：
- 转换是入口，管理是日常：节点增删改、分组策略调整都在界面上持续操作，不用每次重新走转换流程
- 聚合是常态：多来源订阅稳定地聚合成一个输出，配合自动刷新，机场节点变了你的聚合订阅自动跟上
- 高级功能可视化：链式代理、精确分流这类在 YAML 时代属于「高手专属」的配置，变成了表单和下拉框
如果你已经自托管了不少服务，SubBoost 的定位和本站写过的 GPT-Load API 网关类似——都是「把散装资源统一管理起来」的自托管中间层。
两种使用方式
方式一：在线使用。 官方提供在线站点（subboost.org），注册即用，零部署成本。适合先体验功能再决定要不要自托管。
方式二：自托管。 官方提供 GHCR 镜像一键部署，也支持 Docker Compose 从源码构建（需要 PostgreSQL）。适合在意数据主权的用户——毕竟订阅链接和节点信息属于敏感配置，自托管意味着这些数据只存在你自己的服务器上。
部署细节在SubBoost 部署教程里完整展开。
谁适合用
- 多订阅用户：手里有两家以上机场，想合并管理
- 自建节点玩家：自己的 VPS 节点和机场订阅混用，需要统一出口
- 分流讲究人：想要精细的国内/国外/流媒体/AI 服务分流策略
- 隐私敏感用户：不想让订阅信息经过第三方在线转换服务
- 家庭网络管理员：给全家设备维护一份稳定的聚合订阅
新手常见问题 FAQ
Q：SubBoost 自己提供节点吗？
不提供。按官方声明，它是纯粹的订阅管理工具，节点全部来自你导入的订阅源（机场订阅、自建节点链接）。它负责把散装资源整理成结构清晰、分流精确的聚合订阅，本身不涉及任何网络访问行为。
Q：和手动改 YAML 相比，优势在哪？
手动改 YAML 的每个动作——重命名节点、加代理组、调规则顺序——都是一次性的：下次订阅更新，改动全部重来。SubBoost 的改动落在节点池上，配合自动刷新持续保值；而且链式代理、DNS 防泄露这类配置，界面上点点就能完成，不需要你先学 YAML 语法。
Q：输出给哪些客户端用？
任何支持 Clash/Mihomo 配置格式的客户端都能直接拉取聚合订阅：桌面端的 Clash Verge、Mihomo Party，移动端的 Stash、FlClash，路由器上的 OpenClash 都属于这一类。
Q：必须自托管才能用吗？
不是。官方在线站点（subboost.org）注册即用，可以先零成本体验完整功能，确认适合自己之后再按部署教程搬到自己的服务器上。
Q：开源协议对使用者有影响吗？
SubBoost 采用 AGPL-3.0 协议开源。个人使用、自托管没有任何额外限制；如果你想基于它做二次开发并对外提供服务，才需要遵守 AGPL-3.0 相应的开源义务。
Q：已经在用其他转换方案，值得换吗？
看你现在的痛感：单一订阅、分流需求简单的，现有方案够用就不折腾；被多订阅管理、手写规则、手动更新这些事持续消耗着的，SubBoost 的聚合加可视化就是对症的解法——迁移成本只在入口层，订阅重新导入一遍。
按需求找功能：速查表
把你带着来的问题和对应功能、展开文章对上号：
| 你的需求 | 用哪个能力 | 展开阅读 |
|---|---|---|
| 两三家机场合并成一个订阅 | 订阅聚合 | 订阅聚合实战 |
| 节点名太乱，想批量整理 | 批量重命名 | 节点管理实战 |
| 国内国外、流媒体、AI 分开走 | 精确分流 | 精确分流教程 |
| 流量先中转再落地 | 链式代理 | 链式代理配置 |
| 查域名解析会不会泄露 | 防 DNS 泄露 | DNS 防泄露配置 |
| 不想手动更新订阅 | 自动刷新 | 自动刷新与智能匹配 |
先说清楚边界
按官方声明，SubBoost 本身不提供任何代理服务——它是纯粹的订阅管理工具，节点来自你自己的订阅源。它运行在服务端，产出的是 Clash/Mihomo 格式的配置订阅，客户端（Clash Verge、Mihomo Party、Stash 等）拉取这份订阅使用。工具本身与网络访问行为无关，这是理解它的正确姿势。