# ClashRule: a Clash routing ruleset where match order decides everything > ClashRule is a personal Clash configuration repository rather than a program: it ships routing rules for common apps plus a guide for converting subscriptions. Its central lesson is that Clash stops at the first matching rule, so the order of the blocks in the configuration matters more than the number of rules in it. **cutethotw/ClashRule** — Clash自用分流规则，涵盖常用APP，长期维护 - Repository: https://github.com/cutethotw/ClashRule - Stars: 938 · Forks: 152 - Language: Unknown - License: not declared - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/cutethotw-clashrule ## A ruleset repository, not a piece of software ClashRule contains no code to build. The top level of the repository is a set of configuration files and folders: GeneralClashRule.ini is the general routing ruleset, GeneralClashConfig.yml is the general configuration, Back.ini holds the tail section, and the directories Rule, Customization and Tailored hold variations. There are also test.ini and test.yml. The repository description says it is a personal Clash splitting ruleset covering common apps and maintained over the long term. That shape matters when you decide whether to use it. You are not installing a package. You are either importing a ruleset into a client or hosting the raw file yourself and pointing a client at it. The people who benefit from it are users of the Clash family and clients that read the same configuration format, including Clash for Windows, Clash for Android, Stash, Choc, ClashXPro, OpenClash, ShellClash and Shadowrocket. The README itself is a tutorial for turning an existing subscription into one that points at these rules. It is written as a walkthrough for a beginner rather than as a specification, and several option lists are still marked as awaiting more entries, which tells you how complete the guidance is. ## Matching stops at the first rule, so position is the whole design The single most useful thing the README explains is that rule matching is collected from the top down, and once a rule matches, evaluation stops. The stated example is YouTube: a YouTube rule has to sit above the broad foreign media rule, because that broader rule already contains YouTube, Netflix and other services, so a large split placed first would swallow the small one. The rule of thumb that follows is simple. A large split rule goes after the small split rules it contains. And the ordering principle the guide gives is a sequence rather than a single rule: important direct connections first, then ad blocking rules, then the small splits, then the large domestic and foreign splits, and finally supplementary rules. This is the difference between a ruleset that works and one that does not. Most complaints about Clash configurations are not about missing rules but about a broad rule sitting above a specific one, which quietly swallows every exception the user spent time adding. ## Policy group modes decide which node a rule lands on A routing rule only tells the client which group to use. What that group does is a separate choice, and the README lists four selection modes with their behaviour. Latency lowest runs a periodic latency test and picks the node with the lowest delay. Failover always takes the first node in the group and only moves to the next when the current one is unusable. Manual selection has no special behaviour beyond picking by hand. Load balancing uses every node in the group, and the guide notes that many subscription providers limit connection counts, so in practice it is rarely used. Those four are not equally useful. Latency testing costs periodic requests to every node in the group, so a group with many nodes and a short interval is the combination to watch. Failover is cheap but picks a fixed first node, which matters when that node is in a region you did not want. The node filtering rules decide what ends up in the group in the first place, so the mode and the filter work together. ## Node filters run as regular expressions over the subscription The advanced options in the conversion form include an include list and an exclude list, and both are expressed as regular expressions matched against node names. The include list behaves as a blacklist of allowed nodes, so only nodes matching the pattern are shown. The exclude list behaves as a whitelist of nodes to remove, so matching nodes are filtered out. The guide gives examples such as keeping only Hong Kong nodes, and dropping the nodes that only carry provider or traffic information. The simplest pattern is the one that matches everything, and it appears on its own in the guide. ```yaml .* ``` Because the expression is matched against the node name, the quality of the filter depends entirely on how the provider names its servers. A provider that labels nodes with the city, the region abbreviation or a status word will match the common patterns, and a provider that uses opaque identifiers will not. This is the practical reason to check the raw node list before trusting a subscription filter, since a filter that matches nothing leaves you with an empty group and a connection that never starts. ## Pointing a client at the general rule file as a remote config The guide's own split rule file is published as a raw link, and the README is explicit that the remote configuration field must be a direct link rather than a page that renders the content. ```yaml https://raw.githubusercontent.com/cutethotw/ClashRule/main/GeneralClashRule.ini ``` You paste that address into the remote configuration field of the conversion form, or into the equivalent field in your client, and the rules are fetched from there. The README also notes that some rule files can be referenced from a profile: a .list file can be referenced directly, while a .yaml file needs the prefix "clash-classic:" added in front of it. Two other referenced rule collections appear in the guide, with a stated difference between them. ACL4SSR is described as comparatively stable with a high rate of correct routing, and blackmatrix7 as updated more frequently with broader coverage. Both are referenced as external lists, which is the difference in approach worth noticing: this repository curates and explains a personal rule set, while those two are larger shared collections. ## Converting a subscription before the rules can apply The rule file is only half of the setup, because the client still needs a subscription that contains the nodes. The guide walks through the conversion form field by field, starting with the subscription link itself. One constraint is easy to miss and expensive to debug: the input subscription must contain node information directly, and an already converted subscription cannot be nested and detected again. The generation type decides the format the output takes. Choosing clash produces a configuration that the Clash family and Shadowrocket can both read. Choosing mixed produces a single base64 encoded blob containing nodes of several types, and the guide says the V2ray family and Shadowrocket can use it. The backend address is a separate field, and the guide observes that most front ends do not let you set your own backend, which is why it recommends the hosted backend it considers the most compatible and stable over long use. You can host both halves yourself. The guide names a front end project and a back end project for that purpose, and a short link service to keep the long generated URL tidy. ## Advanced switches such as UDP and TFO, and what is still undocumented The last group of options covers behaviour rather than routing. Node renaming applies a naming scheme to the servers in the subscription, the subscription name shows up in Clash for Windows while most other clients ignore it, and there are toggles for emoji in node names, for UDP and for TFO. UDP is recommended for proxying games and voice calls, with the caveat that it only helps when the node itself supports it. Emoji is on by default. Several of these option lists end with a note that more entries are to be added, so the documentation is openly incomplete. The remote device field is even flagged with uncertainty about its purpose and a remark that it seems intended for one particular client. On maintenance and reuse: the repository is not archived and the last push was on 2026-10-16, but it has no GitHub releases, so there is no versioned tag to pin. It also states no licence and has no homepage. The practical consequence is that you can read the rules and point a client at them, but the terms for copying or redistributing them are undefined, which is a reason to keep your own fork rather than assume permission to publish them. ## Conclusion ClashRule suits a user of Clash, ClashXPro, Stash, OpenClash or Shadowrocket who wants one maintained set of routing rules instead of hand written policy groups, and it pairs that with a subscription conversion walkthrough. It is the wrong tool for anyone who cannot point a client at a raw rule URL, and it is a poor base for commercial redistribution because the repository states no licence. Verify first that the remote config URL you paste resolves as a direct link, since the guide insists the remote configuration must be a direct link, then check the top of GeneralClashRule.ini to see how the rules are actually ordered before you trust the documented ordering. ## FAQ ### What is ClashRule and what is it used for? ClashRule is a repository of personal Clash splitting rules covering common apps, published as configuration files such as GeneralClashRule.ini and GeneralClashConfig.yml. It is meant to be referenced by a Clash client as a remote configuration rather than installed as software. ### How do I order Clash routing rules correctly? Rule matching is collected from the top down and stops at the first match, so a broad rule placed early swallows the specific rules below it. The documented ordering principle puts important direct rules first, then ad blocking rules, then small splits, then the large domestic and foreign splits, and supplementary rules last. ### Why does my subscription conversion produce no nodes? The input subscription must contain node information directly, because an already converted subscription cannot be nested and detected. A filter expression that matches no node names also leaves the group empty, so check the raw node list against the include and exclude patterns you used. ### What is the difference between the clash and mixed subscription types? Choosing clash generates a configuration that the Clash family and Shadowrocket can both use. Choosing mixed packs nodes of several types into one base64 encoded subscription that the V2ray family and Shadowrocket can use. ### Which Clash policy group modes does the guide describe? Four modes are listed: latency lowest, which tests latency periodically and picks the fastest node; failover, which uses the first node and only moves on when it is unusable; manual selection; and load balancing, which uses every node and is rarely practical because many providers limit connection counts. ## Sources - [cutethotw/ClashRule on GitHub](https://github.com/cutethotw/ClashRule) - [Issues](https://github.com/cutethotw/ClashRule/issues) - [README](https://github.com/cutethotw/ClashRule/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cutethotw-clashrule