LM-Firefly Rules is a personal Clash routing set, kept as a list of intentions

A rule collection rather than a proxy client

LM-Firefly/Rules describes itself as a personal backup of Clash policy groups and rules together with Subconverter related resources, and that framing is accurate. There is no client, no daemon and no server code here. What there is, is a set of routing decisions expressed as lists, and the repository topics make the intended audience explicit, with clash, quantumult, quantumultx, surge, rule, ruleset and subconverter all listed. The primary language recorded for the repository is Go Template, which fits a collection of rule and configuration templates, and the homepage points at sub.koyeb.app, a conversion backend the author runs. The practical appeal for a reader is granularity. Instead of one enormous ruleset downloaded from a single URL, the repository splits routing by intent, so you can take the streaming list and leave the corporate cloud list alone, or exclude the lists that route around a measurement service while keeping the rest. That granularity is also the maintenance burden, since each file is a separate thing to review, and the files are maintained by one person as a personal backup rather than as a published product.

Nineteen lists, each with a stated purpose

The README tabulates the files and what each one contains, and reading the table is the fastest way to understand the scope. Adblock.list holds common advertising domains, including advertising networks, and Special/App-Activation.list holds software activation domains, with Adobe products given as the example. Special/DNS.list collects commonly used DNS servers. The service lists are Apple.list, Microsoft.list, Google.list under PROXY, Game.list, GlobalMedia.list for common overseas streaming services, PROXY.list for common foreign services, Domestic.list for company services common in mainland China, SpeedTest.list for Ookla SpeedTest servers, and CCC-CN.list and CCC-Global.list for cloud computing companies in China and globally. The Special directory adds the entries that make or break a home network. Local-LAN.list holds LAN address ranges, LAN-Special-Apps.list covers local network applications such as screen casting and broadcast, NTP-service.list lists common NTP services with a note that routers may need a fake-ip-filter entry, and TeamViewer-CIDR.list holds the remote IP ranges for TeamViewer that need a direct connection. Two entries in the same directory deserve a mention because of what they contain. Special/Video-Crack.list lists pirated video parsing sites, and Special/DMCA-Sensitive.list holds DMCA sensitive domains, described as mainly aimed at airport audit trackers and Xunlei.

The small slice directories are not mirrors of the main lists

One piece of housekeeping in the README deserves to be read carefully, because it prevents a wrong assumption. The Domestic-Services and Global-Services directories are described as small slices listed only for reference, and the documentation states explicitly that they are not one to one with Domestic.list and GlobalMedia.list, with the actual containment relationship to be taken from the comments inside each list. That is a common source of confusion in rule set collections. A reader who assumes the directory listing is authoritative will route traffic differently from what the file author intended, because a domain in the slice directory might not be in the main list, or might sit in a different policy group. The same pattern applies to the per-topic directories in the tree, with Apple, Game, GlobalMedia, PROXY, CCC-CN and CCC-Global each having a directory alongside its .list file, and separate markdown files such as Apple.md, Game.md and GlobalMedia.md that the README points to for the details of the Apple, game and streaming entries. The rule of thumb is simple. The comments inside a .list file are the contract, and the directory structure is navigation.

Two rule set directories for two output formats

The repository tree carries two directories that matter for anyone loading the rules into a client: Clash-RuleSet-Classical and Clash-RuleSet-MRS. The names describe the two deliverable formats, one in the classical textual rule set form and one in the mrs form, so the same routing intent is available in whichever shape a given client expects. This is worth understanding because the choice is not cosmetic. A client that supports the mrs format can consume a compact binary artefact instead of a long text file, and the text form remains useful for clients that do not read the binary variant or for people who want to read the rules in a diff. The rest of the tree supports the same goal from different angles. Adblock holds the advertising entries, Special holds the network-level and home-network entries, CN-IP.list sits at the root as a China address list, and Subconverter-base holds the material for the conversion backend, which is the piece that makes the format conversion described in the next section possible.

Subconverter is the bridge to formats Clash cannot read

The README has a section on flexible conversion, and it is the part that makes the collection usable outside the client the author happens to use. If you need a special format, the documentation points to Subconverter and its rule conversion documentation, notes that there are many public free services you can use, and offers the author's own backend at sub.koyeb.app. A Docker Subconverter template is linked in a separate repository, LM-Firefly/Firefly-sub, for anyone who would rather run the converter themselves than send their configuration to a third party. The relevant reference for one common case is also included, the Telegram CIDR list published by Telegram itself, which is the kind of external source a rule set needs to track. The overall arrangement is a reasonable division of labour. The lists in this repository are the source of truth for intent, Subconverter reshapes them into whatever syntax a particular client wants, and the conversion service is interchangeable, which means a rule set that depends on somebody else's backend can be moved to a self-hosted converter without rewriting the lists.

No stated licence, and the file names are not the documentation

Two practical cautions close the picture. The first is licensing. The licence field in the repository metadata is empty, so the platform reports the licence as unknown, and the README does not name one either. For a collection of domain lists that is unusual and worth thinking about before you redistribute it or build a product on top of it, because the default assumption for a repository with no stated licence is that you do not have permission to do either. The second is that the file names are labels, not specifications. A list named for a company may contain a couple of domains and a comment explaining why, a list named for a network service may be a single IP range, and the README's own warning about the slice directories shows how easily a name can be misread as a contract. The right way to use this repository is the way the author describes it, as a personal backup of routing decisions, and to read the comments before importing. It is a useful starting point for a configuration, not a finished one. The last push was on 2026-10-14, so the lists are being changed, and a list that was correct for your network a year ago may not be correct for it now.

Editorial conclusion

Adopt this repository if you run Clash or a compatible client and want a starting rule set that is organised by intent rather than by domain, and if you are willing to audit the entries yourself before routing traffic through them. Do not treat it as a vetted source, because the licence is not stated in the repository metadata and the README describes the lists as personal, and do not assume the file names describe the contents, since the documentation warns that the small slice directories do not map one to one onto the main lists. Before you import anything, read the comments in the individual .list files, check how the domain entries are written, and decide which of the special-purpose lists, from the ad domains to the DMCA sensitive domains, belong in a configuration you actually maintain.

Frequently asked questions

Official sources

1. Issues
2. LM-Firefly/Rules on GitHub
3. Project website
4. README