管理 Clash/Mihomo 配置，真正麻烦的往往不是“拿到一个订阅链接”，而是之后的一连串工作：合并多个来源、筛选和重命名节点、维护规则、避免 DNS 泄露，以及在上游发生变化后继续更新。
SubBoost 正是为这些事情准备的。它是一套开源的 Clash/Mihomo 订阅转换、增强和管理工具，把不少原本需要手写 YAML 的操作放进了可视化界面。
项目也提供了可以直接使用的官方在线平台 。如果只是偶尔整理订阅，不想维护服务器，注册后打开网页就能用，这仍然是最方便的选择。
SubBoost 能做什么
最基础的用途，是把订阅 URL、YAML 文件、节点链接等不同来源导入进来，生成一份适合 Mihomo 使用的新订阅。它并不提供代理服务，而是负责加工和管理用户已有的订阅与节点。
在这个基础上，SubBoost 还提供了不少实用能力：
- 聚合多个订阅和自建节点，并按计划自动刷新；
- 批量重命名、删除节点，或者为节点设置监听端口；
- 按来源、地区、关键词等条件组织和筛选节点；
- 通过界面配置链式代理与 Relay 代理组；
- 启用常用代理组和远程规则集，完成更精确的流量分流；
- 调整规则顺序，继续做更细的手工定制；
- 使用项目提供的基础配置降低 DNS 泄露风险。
它最吸引我的地方，不是凭空发明了新的代理协议，而是把许多零散、容易出错的配置工作串成了一条清晰的流程。对于不想长期维护一份庞大 YAML 的人，这种可视化管理很有价值。
官方在线平台：有限额，但轻度使用足够方便
这里也要特别感谢项目方提供 subboost.org 这项在线服务。运行公共实例要承担服务器、数据库、网络和安全维护成本，愿意让普通用户开箱即用，本身就是对项目很实际的投入。
官方在线平台存在配额限制。账户界面会分别显示订阅配额、每个订阅的节点上限、模板配额，以及每种导入方式的导入源配额。这些配额意味着不能无限创建订阅，也不能在一个配置里不断增加导入源。
不过，“有限制”并不等于“不够用”。对于只管理少量订阅、偶尔做一次转换的轻度用户，官方平台通常已经够用，而且完全省去了部署、升级、备份和域名配置。它很适合作为第一次接触 SubBoost 的入口。
配额数字属于在线服务的运行策略，可能随账户和平台调整而变化，所以本文不把某个数值写成永久承诺。登录后在账户页面看到的实时配额，才是当前账号的准确上限。
为什么我最后还是选择自己搭建
当订阅数量、节点数量或导入源逐渐增加，或者希望数据完全保存在自己的环境中，自建就更合适了。自部署版由自己管理账户和数据库，项目代码中为本地管理员设置的相关容量上限也远高于日常个人使用需求，不再受公共平台的常规账号配额约束。
更重要的是，SubBoost 已经把部署过程做得很简单。官方提供 Linux 一键安装脚本，会检查 Docker 和 Docker Compose，生成数据库密码、加密密钥与首次初始化令牌，下载镜像并启动服务。安装完成后还会给出管理地址和创建管理员的入口。
我这次没有逐条手工配置，而是直接把需求交给 AI：在已有服务器上部署 SubBoost，设置访问地址并检查服务状态。大约 3 分钟后，配置就完成了。
这个“三分钟”只是我的一次实际体验，不是项目方承诺的安装时间。服务器是否已经安装 Docker、网络能否顺利访问 GitHub 和 GHCR、是否还要配置域名与 HTTPS，都会影响最终耗时。但它至少说明了一件事：有了项目提供的一键部署工具，再让 AI 代为执行和检查，自建已经不再是一项沉重的系统工程。
自建版的结构并不复杂
从公开源码看，SubBoost 是一个 TypeScript monorepo，主要由几层组成：
packages/core负责订阅解析、节点处理、规则与配置生成等核心逻辑；packages/ui提供共享的可视化界面和交互；packages/server-core放置订阅管理、自动刷新等服务端能力；local是可自行部署的 Next.js 应用，通过 Prisma 使用 PostgreSQL 保存数据。
官方的 Docker Compose 配置包含三个服务：Web 应用、PostgreSQL 数据库和负责定时更新的 cron 侧车。可以把它简单理解成下面这条链路：
浏览器
↓
SubBoost Web 应用
├─ 解析、转换并生成 Mihomo 配置
├─ PostgreSQL 保存账户、订阅和模板
└─ cron 定时刷新订阅与规则索引这种结构对个人部署很友好：应用和数据库的职责清楚，升级、备份和恢复也有官方命令及文档支持。项目同时提供从公开镜像安装的一键方案，以及从源码构建的高级方案。一般个人使用选择前者即可。
自建也意味着自己承担责任
自建摆脱了公共实例的常规配额，但并不是“安装完就永远不用管”。至少还要注意几件事：
- 如果服务暴露在公网，应配置 HTTPS，并避免直接暴露数据库；
- 妥善备份
.env和数据库，尤其要保存加密密钥，否则已有订阅可能无法解密； - 定期更新版本，留意订阅导入、安全限制和数据库迁移相关说明；
- 不要把代理组监听端口直接开放到公网；
- 项目采用 AGPL-3.0-only 许可证，修改后通过网络向他人提供服务时，应了解相应的源码提供义务。
SubBoost 本身也明确说明，它不提供代理服务，不保证第三方订阅内容的可用性或合法性。工具解决的是配置管理问题，用户仍需对自己的来源和使用方式负责。
在线使用，还是自己搭建
我的选择标准很简单：
- 第一次体验、订阅不多、希望零维护：直接使用官方在线平台；
- 配额已经影响使用、重视数据控制、手头有服务器：自行部署；
- 想先试后迁移：先感谢并使用官方服务，确认适合自己后再自建。
官方平台和自建版并不是非此即彼。前者降低了体验门槛，后者给重度用户更多空间；公共服务的配额也是维持服务稳定的一种合理方式。
对我而言，SubBoost 最值得记录的地方，就是它同时照顾到了这两类人：轻度用户可以立即使用，想要更多控制的人也拿得到完整源码和部署工具。而在 AI 已经能代为完成常规服务器操作的今天，“自己搭一套”甚至可能只需要一句足够明确的指令，再等三分钟。
参考资料
本文根据 2026 年 8 月 29 日可见的 SubBoost 2.8.1 版本、官方文档与公开源码整理。功能、部署方式和在线平台配额策略都可能继续变化，请以项目最新说明为准。