# This Clash ruleset blocks ads at DNS and at routing, and republishes every 20 minutes

> A generated rule-provider rather than a program: adblock_reject shipped as YAML, MRS and TXT, each behind a GitHub raw link plus two CDN mirrors, produced by two PowerShell scripts from a whitelist and a list of upstream sources. The example config re-fetches on a 120-minute interval, not the publish cadence.

**REIJI007/AdBlock_Rule_For_Clash** — An ad-domain-blocking RULE-SET for Clash (Premium and Mihomo cores), updated every 20 minutes.

- Repository: https://github.com/REIJI007/AdBlock_Rule_For_Clash
- Website: https://github.com/REIJI007/AdBlock_Rule_For_Clash
- Stars: 368 · Forks: 14
- Language: PowerShell
- License: NOASSERTION
- Published: 2026-08-23 · Updated: 2026-08-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/reiji007-adblock-rule-for-clash

## Three formats, three hosts each, and no version anywhere in the URL

The repository is a distribution point, not an application. It publishes three files and nothing else at runtime: adblock_reject.yaml, adblock_reject.mrs and adblock_reject.txt.

Each file gets three subscription links. A GitHub raw URL, a jsDelivr URL of the form cdn.jsdelivr.net/gh/REIJI007/AdBlock_Rule_For_Clash@main/..., and a Statically URL with the same path. Offering three hosts for the same file is the practical part: the fetch does not depend on one of them being reachable from the network your client runs on, and you pick the mirror in your own configuration.

The formats are not interchangeable, which is why all three exist. The YAML file is what the rule-provider example consumes. The TXT file is a plain list for anything that reads lines. The MRS file is the binary form, and the repository root contains mihomo.exe next to it, which is a strong hint about the core that produces it.

Every URL points at main and carries no tag or commit. That is a deliberate trade: subscribers always get the newest list without touching their config, and a bad generation is pushed to everyone at once. If you need reproducibility, pin to a commit yourself rather than relying on the link as given.

## The example config rejects at routing and returns rcode://success at DNS

The configuration block is short, and each part of it does something different.

```yaml
dns:
  enable: true
  nameserver-policy:
    'geosite:category-ads-all': rcode://success

rule-providers:
  adblock:
    type: http
    behavior: classical
    url: https://raw.githubusercontent.com/REIJI007/AdBlock_Rule_For_Clash/main/adblock_reject.yaml
    path: ./ruleset/adblock_reject.yaml
    interval: 120
    timeout: 30
```

Two layers are at work. The DNS layer turns resolution on and maps the geosite category for advertising to rcode://success, which answers the query with a successful but empty response instead of letting the request leave. The routing layer is the rule-provider plus the rules that come after it.

The provider is type http with behavior classical. Classical is the full rule syntax rather than a bare domain list, which is what lets one file carry more than hostnames. The local path is ./ruleset/adblock_reject.yaml, so the downloaded copy sits inside your working directory rather than in a system path.

Then the two rules that use it.

```yaml
rules:
  - GEOSITE,category-ads-all,REJECT
  - RULE-SET,adblock,REJECT
```

The first rejects the built-in geosite category outright. The second rejects whatever the subscribed provider matched. Both use REJECT, so the request is dropped rather than proxied, and the DNS policy covers the case where the request never got as far as the routing table.

## interval 120 is how often Clash refetches, and it is not the 20-minute publish cadence

The repository description states that the list is updated every 20 minutes. The example configuration says interval: 120.

Those are two different clocks, and only one of them is under your control. The publisher regenerates on a 20-minute cycle, which is why timestamp.txt exists at the root. The client-side interval is what your Clash instance uses to decide when to download the file again, and the example sets it to 120.

So out of the box you are polling far less often than the list changes. If you care about picking up a newly blocked domain quickly, lower interval. If you would rather not hit the CDN or your mirror that often, 120 is a perfectly reasonable number and the staleness costs you little, because ad domains do not usually appear and disappear within two hours.

timeout: 30 sits next to it, which is the number of seconds a fetch may take before it is treated as failed. That matters for the mirrors: a slow CDN response leaves you with the previous copy rather than an empty ruleset, which is the failure mode you want.

One more detail in the same block. The provider is named adblock and stored under ./ruleset/, while the file on the network is adblock_reject.yaml. The name inside your configuration is yours to choose; the path is where Clash writes what it downloaded.

## Two PowerShell scripts generate the lists, and mihomo.exe sits beside them

The build is two scripts, one per text output: adblock_rule_generator_txt.ps1 and adblock_rule_generator_yaml.ps1. PowerShell is the primary language of the repository for a reason, and the generators are the only real code in it.

The committed mihomo.exe is the interesting artefact. A rule generator for Clash does not usually need to ship a core binary, so its presence points at the MRS output being produced or validated by running mihomo itself rather than by hand-writing the format.

Around the scripts sit three files that describe the output rather than the code. timestamp.txt records when the current list was generated, which is how you tell whether the twenty-minute cycle actually ran. whitelist is a directory, which is the exclusion side of the pipeline: domains that would otherwise be blocked can be kept out. Referencing rule sources.txt is the upstream list, the answer to the question every filter-list subscriber should be able to answer, which is where the domains came from.

Read together, those three tell you the shape of the pipeline: collect from the referenced sources, subtract the whitelist, write YAML and TXT, produce MRS, stamp the timestamp. The scripts are short because the interesting decisions live in the data files next to them.

## The whitelist and the source list are the two files worth reading before you subscribe

A generated ruleset is only as good as its inputs, and this repository ships its inputs in plain text, which is rarer than it should be.

Referencing rule sources.txt is the provenance record. Before you point a DNS policy at a list of thousands of domains, you can read which upstream feeds contributed and decide whether you trust each one. That matters more than it might appear: whatever domains those sources assert end up in a file that your client downloads and applies without further question.

whitelist is the correction mechanism, and its existence tells you the maintainer expects false positives. Ad-blocking lists are generated from other people's blocklists, and a domain that one source flags and another needs is exactly the kind of breakage a whitelist prevents. If a site you rely on stops resolving, this directory is the first place to look, followed by your own local rules.

Neither file is documented in prose. There is no explanation of the whitelist format, no statement of how often the sources are re-read, and no note about what happens when an upstream changes shape. So the honest position is that the two files are readable but unexplained, and reading them is your own verification step.

The repository description is in Chinese and describes the set as ad domain blocking for Clash, for both the premium core and mihomo. The home page is the GitHub repository itself.

## Two licence files at the root, and neither is named as the applicable one

The repository root carries LICENSE-CC-BY-NC-SA 4.0 and LICENSE-GPL 3.0 as two separate files. That pairing is unusual enough to need care, and the README does not explain it.

The difference that matters is the non-commercial clause. CC BY-NC-SA 4.0 permits sharing and adaptation with attribution provided the use is non-commercial, while GPL 3.0 is a copyleft licence without that restriction. If one of those two terms covers the rule files and the other covers something else, that difference decides whether you may use the list in a commercial deployment.

Nothing in the documentation maps licences to artefacts, and no licence identifier is attached to the project in the repository record. Which means the correct move is to read both files and work out the terms yourself, or to ask the maintainer, before you redistribute anything derived from the list. This is not a legal opinion, it is the observation that two conflicting-looking licences with no mapping is a question, not a settled answer.

The practical risk for a filter list is narrower than it looks. Pointing your own client at a subscription URL is not redistribution. Shipping a bundled copy inside a product or an appliance image is, and that is where the licence question stops being academic.

## Nothing is versioned, so the branch name is the only stability guarantee you have

There are no GitHub releases and no tags in any of the subscription links. Every URL resolves to the main branch, and the last push to the repository was on 2026-09-25.

For a file that is regenerated on a twenty-minute cycle that is defensible, because a ruleset has no use for a version history and a stale copy is worse than a fresh one. The trade is that you have no way to tell a good list from a broken one except by testing it, and no way to roll back without pinning to a commit yourself.

Two failure modes follow from that, and both are worth planning for. A generator that produces an empty or malformed file propagates to every subscriber on the next fetch, so watch the file size after a sudden drop rather than assuming a network problem. And a source that starts returning garbage can enter the list without any review, which is the argument for reading Referencing rule sources.txt once rather than trusting it forever.

The default branch is main, the tree is otherwise flat, and the only automation visible at the top level is a .github directory. There is no CI configuration in the repository listing, so whatever regenerates these files runs somewhere this repository does not show you, which is another reason to treat the output as untrusted input.

## Conclusion

Adopt this ruleset if you run Clash premium or mihomo, you want ad domains rejected rather than resolved to a dead address, and you would rather not maintain a filter list by hand. Be aware of three things before you rely on it: the subscription URLs point at the main branch with no version in the path, so a bad regeneration reaches subscribers immediately, the example config fetches every 120 minutes even though the files change every 20, and the root carries both a CC BY-NC-SA 4.0 file and a GPL 3.0 file without saying which covers which artefact, which matters if you redistribute anything built on the list. Check that your core accepts the format you subscribe to, that the whitelist directory is what you expect for the sites you use, and that Referencing rule sources.txt names the upstreams you are willing to trust with your DNS. The last push was on 2026-09-25 and there are no releases.

## FAQ

### How do I use AdBlock Rule For Clash in my Clash config?

Add a rule-providers entry with type http, behavior classical, the URL of adblock_reject.yaml from GitHub raw or one of the two CDN mirrors, a local path such as ./ruleset/adblock_reject.yaml, an interval and a timeout, then add RULE-SET,adblock,REJECT to your rules. The example also enables DNS and maps geosite:category-ads-all to rcode://success.

### What is the difference between the YAML, MRS and TXT files?

All three are the same generated ad-blocking list in different formats. The YAML file is what the rule-provider example consumes, the TXT file is a plain line-based list, and the MRS file is the binary form, with mihomo.exe committed in the repository root.

### How often does the adblock list update, and how often does Clash refetch it?

The list is regenerated every 20 minutes, with the generation time recorded in timestamp.txt. The example configuration sets interval: 120, which is the client-side refetch cadence, so by default your client polls less often than the list changes.

### Can I exclude sites from the ad-blocking ruleset?

The repository ships a whitelist directory, which is the exclusion side of the generation pipeline. Beyond that, the list is applied as a rule-provider you subscribe to, so local rules in your own configuration are the last line of defence.

## Sources

- [Official documentation](https://github.com/REIJI007/AdBlock_Rule_For_Clash)
- [Official README](https://github.com/REIJI007/AdBlock_Rule_For_Clash#readme)
- [Project repository](https://github.com/REIJI007/AdBlock_Rule_For_Clash)
- [Release notes](https://github.com/REIJI007/AdBlock_Rule_For_Clash/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/reiji007-adblock-rule-for-clash