AdBlock-Acceleration mirrors ad filter lists for networks that cannot reach them
Accelerated subscription for international/China region ad filtering rules(国际/中国地区广告过滤规则的加速订阅)
At a glance
- What is it?
- Silentely/AdBlock-Acceleration republishes the common ad blocking filter lists through four mirrors, GHUCS, jsDelivr, cosr and gitmirror, refreshed by a GitHub Actions job every six hours, so that a client in the China region can update a list that is normally hosted outside the region. It is a distribution service rather than a filtering tool, and it warns that its links are not for proxy clients.
- Who is it for?
- AdBlock-Acceleration is worth using when your ad blocking client sits on a network where the original filter list hosts are slow or unreachable, since it gives you a single accelerated URL plus a backup mirror for the same list. It is not a proxy configuration and the README says explicitly not to feed these links to Surge, Shadowrocket, Quantumult(X) or Clash.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Adblock Filter List, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A distribution service for lists, not a filtering tool
AdBlock-Acceleration provides an accelerated subscription of advertising filter rules for tools that block ads, in a form described as usable on international and China region networks. The tools it targets are the familiar ones: browser extensions such as AdGuard, uBlock Origin, AdBlock Plus and Adblock, router side software such as AdGuard Home, KoolProxyR, Adbyby and a couple of regional gateways, and the mobile and desktop apps from AdGuard for Android, iOS, Windows and macOS. What the project provides is not a new rule set. It republishes existing lists, such as the AdGuard filters, the Anti-AD easylist, EasyList China, EasyPrivacy, HalfLife and the CJX annoyance and lite lists, together with hosts files and rules such as 1024_hosts.txt, ds_hosts.txt, Malware_host.txt, Hblock_hosts and Steven_hosts. The repository root shows the whole catalogue as plain text files, with names matching the upstream lists, so the project's value is entirely in how those files reach your client rather than in what they contain.
A six-hourly GitHub Actions job and four distribution mirrors
The mechanism is described in the README in a short paragraph. The project uses GitHub Actions to update and download the latest rules every six hours on a daily UTC cycle, then pushes them to the GitHub repository, and the rules are then distributed with several global acceleration CDNs. Four mirrors are named, and they differ in a way that matters. GHUCS and jsDelivr are cached, which makes them fast when the cache is warm. The cosr and gitmirror mirrors are uncached, which makes them more strongly consistent, meaning you get the newest copy rather than a cached one. The stated outcome of the design is that all rule updates complete within seconds. The repository layout supports that story, since a static site is served from the branch with index.html as the entry point, manifest.json carrying the size and update time metadata that the index page displays, checksums.txt for verification, plus robots.txt, sitemap.xml, _headers and a .nojekyll file. A Netlify deploy badge in the README indicates that the site is published from the repository through a static hosting pipeline.
The timing numbers come from the author's own test
The README includes a personal test section, and the numbers there are worth quoting carefully because they are the author's measurement, not a benchmark anyone else has run. Under a normal network with no proxy, in the mainland China network environment, before using the accelerated links, updating 13 rule sets could take up to 5 minutes and 12 seconds with 4 of the updates failing. After switching to the accelerated links, all the rules finished updating within 15 seconds. That is the problem the project sets out to solve, and the framing in the README is about the failure mode rather than the speed. A blocking client that cannot refresh its lists eventually reports a failure, the user clicks through a prompt they do not understand, and the protection silently stops matching new ad patterns. The stated scenario is a filtering tool configured for an older relative, where a stale or failed update is more likely to be dismissed than diagnosed. For your own evaluation, the number to reproduce is the failure count on your network, because the improvement is a function of how your client reaches the original hosts.
Choosing a mirror by speed or by freshness
The index page at the site's homepage is the entry point for the whole project, and it exists to remove the guesswork. It offers mirror selection across the four backends, one-click copy for a single rule, a batch action that copies every visible rule link at once, and instant search by rule name or file name. Each entry in the index shows the original address next to four accelerated addresses, one per mirror, and the sizes and update times come from the manifest.json file in the repository root. The guidance on which mirror to use is specific. If you want speed, prefer the cached GHUCS or jsDelivr mirrors, since their cache hit rate is high. If you need the newest copy, use the uncached cosr or gitmirror mirrors. If a mirror does not work from your network, switch to another one, and the advice for China region networks is to keep an uncached mirror as a backup. The index also supports a deep link that preselects a mirror and copies a chosen file, in the form index.html?mirror=ghucs©=EasyPrivacy.txt, and the page offers a light theme by default with dark and system options.
The import path is different in every client
Adding a list is a three step operation regardless of the client. Open the web index page, choose a mirror, search for the rule you want and click the copy button next to it, then paste the accelerated address into your blocking tool as a custom subscription, custom filter or blocklist URL. The per platform paths differ, and the README lists them. In AdGuard on Android, iOS, macOS or Windows, the route is settings, then filters, then custom filters, then add, then paste the address and save. In uBlock Origin the route is the Dashboard, then Filter lists, then Custom, then import or add custom, then paste the address and apply changes. In AdGuard Home on a router or home gateway the route is Filters, then DNS blocklists, then Add blocklist, then paste the address and save and update. A small tip in the README is worth taking seriously, since the same rule can be added more than once through different mirrors as a redundancy, or one primary mirror plus one backup, which reduces the effect of a single point of failure.
Not for proxy clients, and one list was pulled over licensing
There is a clear warning attached to the whole project, and it is the first thing to read. The rules are not aimed at network proxy tools, and the README says not to use them with Surge, Shadowrocket, Quantumult(X), Clash(X/A) or similar tools. The distinction is easy to miss because a proxy client also takes a list of rules, but these are ad blocking filter lists, and pasting them into a proxy configuration is not what the project is for. The second limitation is more interesting, because it shows the project's constraints honestly. One entry in the table, the cookie warning blocklist from the i-dont-care-about-cookies project, has its CI synchronisation suspended because there may be redistribution licence limits, and only the original address is kept, with users asked to obtain it under its own terms. The corresponding file, I_dont_care_about_cookies.txt, is still present in the repository. So the project redistributes third party content and is bounded by what those upstream licences allow, and the GPL-3.0 licence that covers this repository does not extend to the lists it republishes.
A static site in a repository of filter lists
The repository is unusual in shape, and the file listing explains it. Alongside the filter text files there are assets/ for the site, index.html as the web interface, manifest.json for metadata, checksums.txt, renovate.json for dependency updates on the site tooling, CLAUDE.md, CODE_OF_CONDUCT.md, ANNOUNCEMENTS_CN.md and ANNOUNCEMENTS_EN.md, and both README.md and README_EN.md, with the Chinese README carrying the substantive documentation. The announcements record that on 2025-01-21 the size of the .git directory in the repository was reduced, which tells you the history of many daily commits of large text files is the thing that was being managed. The project is not archived and the last push was on 2026-10-20, with no GitHub releases, so there is nothing to upgrade and nothing to pin. The subscription URLs are stable by design, since they point at a branch and a file name rather than a release, which is exactly why a mirror can serve a newer copy under the same link without the user changing anything.
Editorial conclusion
AdBlock-Acceleration is worth using when your ad blocking client sits on a network where the original filter list hosts are slow or unreachable, since it gives you a single accelerated URL plus a backup mirror for the same list. It is not a proxy configuration and the README says explicitly not to feed these links to Surge, Shadowrocket, Quantumult(X) or Clash. Before you rely on it, check that the list you need is present in the index page and that its upstream licence permits redistribution, and remember the last push was on 2026-10-20 with no tagged releases.
Frequently asked questions
How often are the AdBlock-Acceleration filter lists updated?
The README says the project uses GitHub Actions to update and download the latest rules every six hours on a UTC daily cycle, then pushes them to the GitHub repository for distribution through the mirrors.
Which mirror should I use for the fastest filter list update?
The README recommends the cached mirrors, GHUCS and jsDelivr, when you want speed, and the uncached cosr and gitmirror mirrors when you need the freshest copy. If a mirror is unreachable from your network, switch to another, and keep an uncached mirror as a backup.
Can I use these filter list links with Clash or Surge?
No. The README explicitly warns that these rules are not intended for network proxy tools such as Surge, Shadowrocket, Quantumult(X) or Clash(X/A), and that you should not use them there. They are ad blocking filter lists for clients such as AdGuard, uBlock Origin and AdGuard Home.
Why is the cookie warning blocklist missing its accelerated links?
The table notes that CI synchronisation for that list has been suspended because there may be redistribution licence limits, so only the original address is kept and users should obtain it under its own terms.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/silentely-adblock-acceleration)Was this useful?