anti-AD: a Chinese-region DNS blocklist that ships in ten formats

What anti-AD actually is: a list, not a program

anti-AD does not intercept traffic. It is a blocklist that other software consumes. The README describes the pipeline plainly: the project merges well-known hosts files, ad filter lists and adblock lists, deduplicates them, then applies a series of abstractions such as dropping dead domains, optimizing EasyList fuzzy matching, and strengthening the allow and deny list mechanism, and finally emits the list. Every rule in the published lists comes from upstream lists and from issues filed by users, according to the README.

The target audience is narrow and specific. If your browsing is mostly Chinese-language sites, TV box apps and mobile apps, the upstream English lists cover less of that surface. anti-AD exists to raise the hit rate there. If your traffic is mostly English-language web browsing with a desktop content blocker installed, this project is solving a problem you may not have.

One structural detail matters more than the marketing line. The blocklist operates at the domain resolution layer. That means it can stop a request before it leaves your network, and it cannot rewrite a page after it loads. Domain-layer blocking and in-browser content blocking are different mechanisms with different failure modes, and anti-AD only does the first.

The build pipeline and why the output comes in ten files

The repository root holds the generated artifacts: adblock-for-dnsmasq.conf, anti-ad-easylist.txt, anti-ad-adguard.txt, anti-ad-domains.txt, anti-ad-surge.txt, anti-ad-surge2.txt, anti-ad-clash.yaml, anti-ad-smartdns.conf, anti-ad-quanx.txt, plus md5 files for two of them. The source of the generation is not in the default branch. Version history v4.5.1 states that the build scripts were moved to a separate branch, adlist-maker, to keep the default branch tidy. So the default branch is a distribution channel; the recipe lives elsewhere.

That split has a practical consequence. Reading the default branch tells you what the lists contain, not how they were produced. If you want to audit the deduplication, the dead-domain removal or the fuzzy matching optimization, you have to go to the adlist-maker branch, and the README does not describe that branch's layout.

The multiple output formats exist because DNS filtering tools disagree about syntax. AdGuardHome accepts the EasyList-style file. dnsmasq needs its own conf format. Pi-Hole wants a plain domain list. Surge has two variants, and the README notes that the DOMAIN-SET format in anti-ad-surge2.txt performs better. Clash Premium and similar tools take YAML. smartdns takes a conf file. sing-box and mihomo take compiled binary rule sets, which is why those two have minimum version requirements rather than a syntax caveat.

Installing anti-AD in AdGuardHome and dnsmasq

There is nothing to compile. You subscribe to a URL. The README recommends the official site addresses over the raw GitHub links because they are faster and more stable.

For AdGuardHome, add the EasyList-format file as a blocklist. The README maps anti-ad-easylist.txt to AdGuardHome DNS filtering, with the official address at https://anti-ad.net/easylist.txt. In the AdGuardHome UI you add it under Filters, then DNS blocklists, by pasting the URL.

# AdGuardHome blocklist URL (DNS filtering)
https://anti-ad.net/easylist.txt

After the subscription refreshes, queries for blocked domains should return the block response AdGuardHome is configured for. The README warns against using this particular file in AdGuard or uBlock Origin, because it contains regular expression rules and those tools match the URL path, so a specific URL can be wrongly blocked.

For dnsmasq and its derivatives, use the conf file. The README gives the official address https://anti-ad.net/anti-ad-for-dnsmasq.conf and points at adblock-for-dnsmasq.conf in the repository.

# dnsmasq-format list, official address
https://anti-ad.net/anti-ad-for-dnsmasq.conf

Point your dnsmasq configuration at that file and restart the service. The README does not document a reload command or a rollback procedure, so keep the previous file if you have one.

If you use Pi-Hole or another tool that wants a bare domain list, the README points at anti-ad-domains.txt and also links a separate whitelist file hosted in the dead-horse repository. That whitelist is a separate download, not part of this repository's default branch.

Binary rule sets for sing-box and mihomo

Two of the ten outputs are not text lists. anti-ad-sing-box.srs is a compiled rule set for sing-box, and the README states it requires version 1.10.0 or above. mihomo.mrs is the equivalent for mihomo, requiring 1.18.7 or above. Both are hosted on the anti-ad.net domain and, for the raw links, in the anti-ad.github.io repository rather than the main one.

The version floors are the interesting part. A compiled rule set is tied to the loader that reads it, so an older sing-box will not consume a newer .srs file. If your router firmware pins an older sing-box build, this format is closed to you and you should fall back to a text format your tool accepts, or skip anti-AD for that device.

The README does not state how often the binary files are rebuilt relative to the text lists, and it does not describe a compatibility matrix beyond those two version numbers. If you run a pinned version, check it against the floor before subscribing.

Disputed domains are your problem, not the list's

The repository carries a discretion/ directory with its own README. The README explains that some domains are associated with advertising or tracking but also serve other purposes, so blocking them can cause collateral damage. The project documents some of these and leaves the decision to you: add your own rules to allow or block them.

This is the honest limitation of any domain-layer blocklist, and anti-AD states it rather than hiding it. A domain that serves both ads and a login endpoint cannot be split by a DNS rule. The failure mode is not a broken list; it is a working list that breaks something you needed, and the only remedy is a local allow rule.

Two more constraints follow from the design. First, because filtering happens at resolution, anything served from the same domain as legitimate content survives. Second, first-party ads on a site's own domain are invisible to this approach entirely. If your problem is a site serving ads from its own hostname, a DNS blocklist is the wrong tool and no amount of list tuning will fix it.

The README also notes that anti-AD considers itself a small, non-mainstream project and that the author will not respond to challenges made without reading the code. That is a stated posture, not a support guarantee.

How anti-AD differs from uBlock Origin and AdGuard's own filters

The obvious alternative is a content blocker in the browser: uBlock Origin or AdGuard. The difference is where the rule is evaluated. A browser extension sees the full URL and the page DOM, so it can block a path, hide an element, or neutralize a script after the fact. anti-AD sees only a domain name, and only if your DNS resolver or proxy consults it.

That makes the two complementary rather than competing. A DNS list covers every device on the network without installing anything per device, including TVs, set-top boxes and phones where extensions do not exist. A browser blocker covers the page-level cases a DNS list structurally cannot reach. Running both is normal; the README's warning about not feeding anti-ad-easylist.txt into URL-matching tools is exactly the boundary between the two approaches.

The second alternative is assembling your own list from the same upstreams anti-AD credits, which include AdguardFilters, easylist.to, fanboy-annoyance, notracking hosts-blocklists-scripts, v2fly/domain-list-community, malware-filter/urlhaus-filter, AWAvenue-Ads-Rule and others. Doing that yourself gives you control over the merge and the update cadence. It also means you own the deduplication, the dead-domain pruning and the fuzzy matching work. anti-AD is essentially a maintained merge of that set, and the trade is control for effort.

Maintenance, licence and what the release history says

The repository is not archived, and the last push was on 2026-09-20, so the list artifacts are being regenerated. That is the part that matters for a blocklist: the generated files are current even though no release has been tagged.

The release history is a different story. The most recent release listed is v4.3, dated 2020-02-04, followed by v4.2.2 on 2020-02-03 and v4.2.1 on 2020-01-19. Version 4.5.2, dated 2022-12-15, appears in the README's version history rather than in the releases list, and it notes that the project code switched to PHP 8 and is not fully compatible with older PHP versions. If you consume the published lists, the release gap is cosmetic. If you intended to run the build scripts yourself, the PHP 8 requirement and the move to the adlist-maker branch are the two things to check before you start.

The licence is MIT. That is permissive and imposes no copyleft obligation on the lists or on the tooling, though the README states that the rules are aggregated from upstream lists, and those upstream projects carry their own terms. If you plan to redistribute anti-AD's output commercially, review the upstream licences rather than assuming MIT covers the whole chain. This is a description of the licence file, not legal advice.

Upgrade cost is close to zero for subscribers: your resolver refetches the URL on its own schedule. The cost sits in the exceptions. Every false positive you hit becomes a local allow rule you maintain, and the discretion/ directory exists precisely because that set is not empty.

Editorial conclusion

Adopt anti-AD if you already run a DNS resolver or proxy that accepts one of its ten published formats and you want Chinese-language ad and tracker domains covered without assembling upstream lists yourself. Do not adopt it if you need URL-path filtering, per-page cosmetic rules, or a project that cuts tagged releases, since the newest release listed is v4.3 from 2020-02-04. Verify first: which file matches your component, whether your sing-box is 1.10.0 or newer or your mihomo 1.18.7 or newer if you want the binary formats, and whether the domains in discretion/README.md that you rely on are being blocked.

Frequently asked questions

Official sources

1. License: MIT
2. privacy-protection-tools/anti-AD on GitHub
3. Project website
4. README
5. Releases