Aethersailor/Custom_OpenClash_Rules: OpenClash Configs, Rulesets and Overwrite Modules

What Custom_OpenClash_Rules actually provides

This is not a proxy tool. It is a repository of configuration material for people who already run OpenClash, the OpenWrt plugin, and who want the routing decisions inside it to be deliberate. The README frames the project as a maintained collection around OpenClash: setup documentation, subscription conversion templates, YAML configs, rulesets, remote overwrite modules and helper scripts.

The audience is narrow and the README is explicit about it. The project targets OpenWrt and OpenClash for technical study, and the Wiki is only available in Chinese. If you run Clash Meta on a desktop, or Mihomo behind a container, the files may still be readable but the documented workflow does not describe your setup. The README also states that the whole configuration needs only OpenClash, with no additional proxy or DNS plugin and no nested setup.

The practical value is that the same routing design is maintained in three delivery forms: a subscription conversion template, a remote YAML overwrite module, and a YAML file you download and edit yourself. The README notes that when you pick the same version and do not modify it, policy group placement, rule order and split-routing logic should stay consistent across the three, though the file structure and loading path differ, and results also depend on the conversion backend and your OpenClash version.

How the cfg, rule and overwrite directories fit together

The repository is organised by artifact type rather than by feature. The cfg directory holds subscription conversion templates and YAML configs under cfg/yaml. The overwrite directory holds remote YAML overwrite modules under overwrite/yaml. The rule directory holds the project's own supplementary rulesets, with a separate rule/game_rule subdirectory for manually curated game rules.

The rule pipeline is the most concrete mechanism visible in the README. Files ending in .list are the source of truth. A workflow generates Classical YAML, Domain YAML, IP-CIDR YAML and MRS derivatives from them, for use either by the subscription conversion templates or by Mihomo rule providers. That means editing the .list is the intended way to change behaviour; the YAML and MRS files are build outputs. The README states that for game rules the workflow generates the derived files but does not update rule content and does not load them into the main config, so you have to check the applicable server region, update time and actual matches yourself before relying on them.

Direct-connection rules are collected from the maintainer and community users. There are several submission paths: a public Rule-Bot instance on Telegram for small manual lookups, a Rule-Bot Client described in its own Wiki for continuous collection of domains that Mihomo ultimately handles with MATCH, a pull request against rule/Custom_Direct.list for batches of verified domains, or an issue form when Rule-Bot is unavailable or you need to attach evidence. The README asks that you search existing rules, issues and pull requests first, and warns against posting subscription URLs, tokens or node credentials in public pages.

Installing and a first run: templates, YAML and the shell scripts

There is no package to install. The resources are consumed inside OpenClash, and the README points first-time users at the project Wiki for the full configuration flow rather than at a binary. What you can install is the plugin itself, and the shell directory provides scripts for that: installation, update, and CPU architecture detection, supporting OpenWrt and ImmortalWrt and adapting to both OPKG and APK package managers.

The README states these scripts may temporarily switch software sources, overwrite and reinstall the plugin, change UCI settings and invoke OpenClash's built-in update flow. Read the directory documentation before running anything. A typical invocation looks like this:

cd shell
ls
# read the README in this directory before executing any script

If you prefer not to touch the shell scripts, the lightest first step is the subscription conversion template. OpenClash dev currently ships all eight of the project's templates, covering the standard, lightweight, minimal GFW and heavy split-routing versions, plus the corresponding failover variants whose filenames end in _Fallback. Select one in the subscription conversion interface and generate a config from your own subscription. Older builds may not list them; the README says you can enter the remote template address manually, and the address and method are documented in cfg.

The third path is the remote YAML overwrite module: point OpenClash at the module in overwrite/yaml, and it downloads the matching YAML, writes it into the subscription and switches the configuration. The manual path is to download a YAML from cfg/yaml, edit it and import it directly. Whichever you choose, the README's DNS section sets a verification condition rather than a promise: avoiding local DNS leaks requires Fake-IP, traffic takeover and DNS settings to be in effect per the Wiki, and the client's DNS requests and related traffic to pass through OpenClash. The README states the result must be checked by testing, not inferred from a completed configuration.

Where the design stops working

The DNS claim is deliberately bounded, and that boundary is the honest part of the documentation. The README lists what falls outside the scheme's control: a client enabling private DNS or DoH, devices or some traffic not being taken over, plugin or firmware behaviour diverging from the documentation, or you overriding the DNS configuration yourself. None of those are fixed by importing a template.

The second limitation is version coupling. The eight built-in templates are listed in OpenClash's dev branch sub_ini.list, and the README warns that if OpenClash later changes that built-in list, the interface may differ from the documentation, while the project's templates remain usable through the remote address. So the smooth path depends on a branch and a list you do not control.

The third is scope. Game rules are shipped as-is: the workflow generates derivations but never updates their content or loads them into the main config. And the README states plainly that the content is the maintainer's own experience, not authoritative, and is not the only or recommended way to use OpenClash. If you want a project that takes responsibility for your traffic decisions end to end, this one explicitly declines that role.

How it differs from a general ruleset project

A general-purpose ruleset project, of the kind that publishes domain and IP lists for Clash and Mihomo, hands you a list and stops. You decide where it goes, how it is ordered, and what happens to traffic that matches nothing. Custom_OpenClash_Rules is built the other way around: the Wiki explains the reasoning for a complete OpenClash configuration, and the directories exist to deliver that reasoning as files. The rulesets in rule/ are supplements to a specific routing design, not a neutral catalogue.

That difference has consequences. A neutral list is portable; you can drop it into any Clash-compatible client. This project's material assumes OpenClash's LuCI interface, its subscription conversion pipeline, and its overwrite mechanism. The three delivery paths exist precisely because the configuration is opinionated and needs to arrive intact. If you only want a China-direct domain list, taking rule/Custom_Direct.list and its generated derivatives into another client is technically possible, but you leave the design that gives those rules their context, and the README's DNS and takeover conditions no longer apply.

The trade-off is maintenance surface. A neutral list can be consumed and forgotten. Here, matching the documented behaviour means tracking which template version you selected, whether your OpenClash build lists it, and whether anything in your client overrides DNS. The repository gives you the material to do that; it does not do it for you.

Licence, maintenance and upgrade cost

The repository is licensed CC-BY-SA-4.0, a content licence rather than a software licence. It permits sharing and adaptation with attribution, and it requires derivative works to carry the same licence. For configuration files and documentation that is a coherent choice. For anyone who wants to fold these YAML files into a closed product, or into a repository under a different licence, the share-alike term is the constraint to read carefully. This is a description of the licence text, not legal advice; if redistribution matters to your use, get your own reading.

The last push to the default branch was on 2026-11-01, and the repository is not archived, so the material is current as of that date. The repository has no published GitHub releases, which fits a repository of files consumed by URL rather than by version tag. That shapes the upgrade cost: there is no version number to pin. You follow a branch, and a template you imported last month may have changed. The README's own warning about the OpenClash built-in template list is the same problem from the other side. Practically, upgrades mean re-importing a template or re-pointing an overwrite module, then re-verifying DNS behaviour, because the README treats verification as part of the setup rather than an optional check.

Editorial conclusion

Adopt it if you already run OpenClash on OpenWrt and want subscription conversion templates, overwrite modules and supplementary rulesets that follow one documented design. Do not adopt it if you expect a plugin, a one-line installer, or English documentation: the Wiki is Chinese-only, the shell scripts may temporarily switch software sources and reinstall the plugin, and the README states the project targets OpenWrt and OpenClash only. Verify first that your OpenClash build exposes the template you intend to use (the dev branch ships eight of them, older builds may not list them), that your client is not sending DoH or private DNS outside the tunnel, and that the licence terms of CC-BY-SA-4.0 suit how you plan to redistribute a modified config.

Frequently asked questions

Official sources

1. Aethersailor/Custom_OpenClash_Rules on GitHub
2. Issues
3. License: CC-BY-SA-4.0
4. Project website
5. README