SubBoost: a visual Clash/Mihomo subscription converter for chained proxies and DNS leak prevention

What SubBoost actually converts, and who is stuck without it

The README describes SubBoost as a Clash/Mihomo subscription conversion, enhancement and management tool. The input side accepts subscription links, YAML files and node links, which covers the three shapes most providers hand out. The output side is an optimized aggregate subscription that SubBoost keeps updating on a schedule.

The person this is aimed at already has a working Mihomo setup but several subscriptions, or one subscription plus a handful of self-hosted nodes. Merging those by hand means editing a config file every time a provider rotates a hostname or adds a region. SubBoost moves that work into a UI: rename nodes in batches, set listening ports, and build filtered proxy groups that contain only the nodes you selected by source, region or custom rule. The README also lists more than 30 common proxy groups and over 2,000 remote rule sets, so the routing table is assembled from maintained lists rather than typed out.

Nothing here is a proxy service. The disclaimer states the project provides no proxy service and makes no guarantee about the availability or legality of third-party subscription content. That sentence matters more than it looks: SubBoost is a config generator and manager, and the nodes remain someone else's responsibility.

How the conversion pipeline and the relay groups are wired

The repository is a TypeScript monorepo. package.json declares npm workspaces over packages/* and local, with the UI and server split into @subboost/ui, @subboost/core, @subboost/server-core and @subboost/config, and the runnable application living in the local workspace. Prisma with the PostgreSQL adapter (@prisma/adapter-pg) is a top-level dependency, so the managed state, subscriptions, node metadata and refresh results, is persisted in a database rather than in memory.

The flow implied by that layout: subscriptions and node links are imported, parsed into nodes, stored, then filtered and grouped according to the rules you configure in the UI, and finally rendered into a Mihomo profile that a client fetches. Automatic refresh re-runs the import on a schedule and, per the README, intelligently matches nodes during refresh, which is the part that keeps a renamed node from breaking the group it belonged to.

Chained proxies are the feature worth understanding before you commit. The README says chained proxies and relay proxy groups are configured visually in one click. A relay group is not a filter: traffic enters one node and exits another, so latency and throughput are the sum of both hops, and a failure in either hop kills the chain. SubBoost makes this easy to configure. It cannot make the underlying path fast.

Installing SubBoost and producing a first aggregate profile

There are two supported routes. The README points to a public service at subboost.org with no deployment required, and to two deployment documents: one-click deployment, described as pulling an image to build, faster with lower requirements, and advanced deployment, described as compiling from source, slower with higher requirements. The platform badge says Linux plus Docker, and the badge row references a GHCR image, so the one-click path is a container on a Linux host. The README does not state the port the container listens on, so take that from the deployment page rather than guessing.

If you are working on SubBoost itself rather than deploying it, the development notes give the source route. The engines field requires Node 22.13 or newer within the 22 line, or Node 24 or newer, so check your Node version first.

npm ci
npm run dev

npm ci installs from the lockfile across the workspaces, and npm run dev delegates to the local workspace, which is where the application entry point lives. The README does not document the URL the dev server prints, so read the terminal output.

The checks the README lists are worth running once before you change anything, because they tell you whether your environment matches what the project expects:

npm run lint
npm run test:unit
npm run check:local-app

lint runs ESLint over local and packages with --max-warnings=0 and then a UI consistency script, so a single warning fails the command. test:unit runs Vitest. check:local-app runs the local workspace's own check script.

After that, the first real use is the one the README describes: import your subscription links, filter the nodes into groups by source or region, enable the proxy groups you want, and let SubBoost render the aggregate profile. The README does not give a worked example of the import screen, so the field names come from the UI itself.

Where SubBoost stops being the right tool

The deployment surface is narrow. The platform badge reads Linux plus Docker and nothing else, and neither the README nor package.json mentions a native Windows or macOS build. If you wanted a desktop application that manages subscriptions locally without a server and a database, this is not it: the Prisma and PostgreSQL dependency means there is state to host and back up.

Rule management is the second boundary. The README lists reordering rules as a feature for advanced users, and that phrasing is honest about the cost. Once you start reordering rules you are maintaining a routing table, and SubBoost's value is that it shows you that table, not that it removes the need to understand it. A user who wants sensible defaults and never wants to see a rule list should leave the ordering alone and accept what the generated profile gives them.

Automatic refresh is the third. It is the feature that keeps a profile current, and it is also the feature that can change your configuration while you are not looking. The README does not document a rollback or a diff view for refresh results, so if a provider renames nodes in a way the matching logic handles badly, the README gives you no stated way to revert to the previous profile. Treat the generated profile as something you can regenerate, and keep your own copy of a known-good config.

SubBoost against hand-written YAML and against proxy-providers

The obvious alternative is doing nothing: write the Mihomo config yourself and use the proxy-providers feature to pull subscriptions directly. That approach has real advantages. There is no extra service, no database, and no third party in the path between your provider and your client. What it does not give you is aggregation with per-source filtering, batch renaming, or a relay group you can assemble by clicking. With proxy-providers, merging two subscriptions into one filtered group means writing filter expressions by hand and keeping them correct as providers change.

A second alternative is a general-purpose subscription converter that takes one subscription URL and returns one config. Those tools solve conversion. SubBoost's README frames the project around conversion plus enhancement plus management: persistent subscriptions, scheduled refresh, node metadata you can edit, and the visual configuration layer. If all you need is a one-off conversion, a stateless converter is less to run. If you need the profile to stay correct over months across several providers, the state SubBoost keeps is the point.

One comparison the README does not make: SubBoost does not replace the Mihomo client. It produces the configuration the client consumes. You still need a client that speaks the Mihomo config format.

Licence, upgrade cost and the maintenance signal

SubBoost is licensed AGPL-3.0 only, stated in both the README and package.json. The README spells out the practical consequence itself: if you modify SubBoost and provide it to users over a network, AGPL-3.0 requires you to offer those users the corresponding source code. Running an unmodified container for yourself does not raise that question. Forking it, changing the UI and hosting it for others does. This is a description of the licence text, not legal advice; read the LICENSE file in the repository for the terms that bind you.

Upgrade cost comes from two places. The first is the workspace layout: packages/core, packages/ui, packages/server-core and packages/config are separate, and the application in local consumes them through file: dependencies, so version skew between a package and the app is possible in a fork. The second is the database. Prisma is in the dependency list and the repository exposes local:db:generate, which implies schema migrations are part of the workflow. The README does not document an upgrade procedure or a migration command for an existing deployment, so check the deployment docs before pulling a new image over a live database.

On maintenance, the facts are concrete: the repository is not archived, the last push was on 2026-09-13, and v2.8.1 was released on 2026-08-24. The project also keeps a release-notes file at docs/release-notes.md and points changelog questions at subboost.org/faq, so release history is documented in the repository rather than only in the UI.

Editorial conclusion

SubBoost fits people who already run Mihomo and want relay groups, per-source node filtering and rule ordering without hand-editing YAML, and who accept AGPL-3.0 plus a Linux and Docker deployment. It is the wrong tool if you want a desktop client, if your nodes come from a single subscription you never intend to merge, or if your provider forbids relaying traffic between nodes. Before adopting it, check the one-click and advanced deployment pages at docs.subboost.org against your host, and confirm that the DNS settings SubBoost writes match what your own resolver expects, because the README describes the default DNS configuration only as helping to prevent leaks.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. SubBoost/subboost on GitHub