ACL4SSR: Ad-Blocking ACL and Clash Rule Fragments for Shadowrocket and SSR

What ACL4SSR actually ships, and who the README says should use it

ACL4SSR is a repository of routing and filtering rules. It is not a proxy client, not a subscription provider, and not a daemon you install. The README describes two distinct products living in one repo: a set of .acl files that an SSR client can consume directly, and a Clash/ folder of rule fragments plus a subconverter config that you feed into a conversion pipeline. The stated audience is narrow. The README says it is only recommended for unrooted Android phones, and the feature list is written around that: blocking Xiaomi and Flyme ROM system ads, blocking splash-screen ads in some apps, blocking carrier-injected floating ads, and intercepting tracking and analytics traffic from common apps. If you are on desktop, on iOS, or rooted, the repository does not claim to be aimed at you. The Homepage field points at a Telegram channel, https://t.me/ACL4SSR, which the README calls the subscription address for the channel. There are no releases retrieved for this repository, so versioning is by branch state rather than tagged artifacts. The last push was on 2026-09-21.

The eight .acl variants and what each one routes

The core of the repo is a table of .acl files, and the differences between them are routing policy, not feature flags. banAD.acl is the default proxy mode with ad blocking on, LAN direct, China IP ranges direct, common China domains direct, and common foreign domains proxied. onlybanAD.acl keeps the ad blocking but drops the China IP and China domain lists, so everything not explicitly handled goes through the proxy. nobanAD.acl turns ad blocking off entirely and proxies globally. backcn-banAD.acl sends China IP ranges to the proxy instead of direct, which is the variant you want if your proxy node is inside China and you need domestic traffic to exit through it. gfwlist-banAD.acl flips the default to direct and proxies only the GFW list, with ad blocking kept. fullgfwlist.acl is the same shape without ad blocking, and the README states plainly that original SS can use this rule and only this rule. gfwlist-user.rule is the C# GFWList user rule file for SSR. Picking the wrong one is the most common way to get a bad result: choosing onlybanAD.acl when you wanted split routing will proxy domestic sites, and choosing nobanAD.acl when you wanted ad blocking will silently do nothing about ads. The README does not document a way to merge two variants, so the choice is effectively exclusive per client profile.

Clash rule fragments and the subconverter pipeline

The Clash/ folder is a different delivery mechanism. The README calls these rule fragments and says they are meant to be combined with a subscription conversion. The fragments are split by purpose: BanAD.list holds common ad keywords and ad networks and is described as having no side effects; BanProgramAD.list holds app-level ad rules and the README warns it may have mild side effects, with the note that if a site's function conflicts with an ad rule, the ad rule is deleted. BanEasyListChina.list carries the China-domain portion of AdblockPlus lists. LocalAreaNetwork.list, ChinaDomain.list, ChinaCompanyIp.list, ChinaIp.list, Download.list, Apple.list, Microsoft.list, OneDrive.list, GoogleCN.list, Telegram.list, Netflix.list, ProxyGFWlist.list and ProxyLite.list cover direct-connect and proxy routing. GeneralClashConfig.yml is a full Clash config file with Chinese comments, and pref.ini is a subconverter config that the README says changes base settings so the rules become ACL4SSR. The conversion itself is not part of this repo: the README points at sub-web as the front end and subconverter as the back end, both open source, and notes that for a self-hosted setup building only the back end is enough. The supported conversion types table lists clash, clashr, quan, quanx, loon, mellow, ss, sssub, ssd, ssr, surfboard, surge with a ver parameter, trojan and v2ray as both source and target, with HTTP/Socks links supported only as a source via &url=.

Installing the rules: a first working setup

There is nothing to install in the package-manager sense. You point your client at a raw file URL, or you point a subconverter instance at it. For a client that reads .acl directly, the README gives the raw GitHub URLs as the update addresses. The whitelist variant is the default recommendation:

https://raw.githubusercontent.com/ACL4SSR/ACL4SSR/master/banAD.acl

Paste that into your SSR client's ACL or rule-update field and trigger an update. What you should see is the client reporting a successful rule fetch and then routing common China domains direct while proxying common foreign domains. If your client is original SS rather than SSR, the README is explicit that it can use only one file:

https://raw.githubusercontent.com/ACL4SSR/ACL4SSR/master/fullgfwlist.acl

For a Clash-style client, you do not paste a .acl. You run the fragments through subconverter, and the repo supplies a starting config at Clash/config/pref.ini plus Clash/config/GeneralClashConfig.yml. The README does not give a full command line for subconverter; it says the front end is sub-web and the back end is subconverter, and that self-hosting the back end alone is sufficient. That is a real gap: the repository documents what the fragments are and which conversion targets exist, but the actual invocation belongs to subconverter's own documentation, which the README links to.

Where the rule set fails: browser ads, side effects, and the wrong client

The README is unusually candid about the ceiling. It states that browsers contain too many internal ads, that a few hundred rules may not filter them all, and asks for understanding about omissions. So if your goal is a clean browsing experience inside an app's embedded webview, this rule set will not deliver it, and no rule set of this shape will. The second limitation is side effects. BanProgramAD.list is flagged as possibly having mild side effects, and the README's mitigation is to delete ad rules when they conflict with site functionality, which means coverage is deliberately traded away to avoid breakage. Third, the Clash folder is not plug-and-play: the README says these are fragments, that how to use them depends on how the corresponding software writes its configuration, and that you should read your own software's documentation to see whether it can use them at all. That is an admission that the repository cannot guarantee compatibility. Fourth, the target audience constraint matters. The README recommends unrooted Android phones and points rooted users elsewhere, to VIA browser, AdAway, neohosts and googlehosts, which is a different mechanism (hosts files) rather than proxy ACLs. If you are rooted, this repository is not the tool it recommends.

ACL4SSR against Loyalsoldier-style rule sets

The natural comparison is with rule collections such as Loyalsoldier's, which people search for alongside this project. The difference is scope and delivery. ACL4SSR bundles ad blocking into the same files as routing: banAD.acl and its siblings make ad filtering a property of the ACL you load, so you cannot get the China-direct routing without also getting the ad rules unless you pick nobanAD.acl or fullgfwlist.acl. A rule set built around a plain GFW list or a geo-based routing list tends to keep filtering and routing as separate concerns, which is cleaner if you want to swap ad blocking independently or if you distrust app-level ad rules. ACL4SSR also commits to a specific conversion path, subconverter with a bundled pref.ini, whereas a plain rule list can be consumed by whatever your client already supports. The trade-off is real in both directions: ACL4SSR gives you a curated, opinionated package with Chinese comments and a documented matrix of variants, and it gives you ad blocking for free if you want it. It also means more decisions up front and a dependency on the subconverter pipeline for Clash users. Neither approach is a superset of the other.

Maintenance, licensing, and what CC-BY-SA-4.0 means for forks

The repository is not archived, and the last push was on 2026-09-21, so the rule files are being touched. There are no retrieved releases, which means there is no changelog to read: you are tracking a branch, and the practical upgrade path is re-fetching the raw URL or re-running your conversion. That has a cost. If you vendor these rules into your own repository, you inherit the job of re-syncing them, and because there is no versioned release, you cannot pin to a tag and diff. The licence is CC-BY-SA-4.0, stated in the README and present as a LICENCE file at the repository root. For a rule file this is workable, but the share-alike term is the part to think about: if you redistribute a modified version of these rules, the licence's ShareAlike condition applies to your derivative. Attribution is required as well. This is a general observation about the licence text, not legal advice; if you are embedding these rules into a commercial product, read the licence yourself or ask someone qualified. The README does not discuss commercial use, redistribution terms, or what happens to downstream forks.

Editorial conclusion

Adopt ACL4SSR if you already run an SSR or Clash-style client on an unrooted Android phone and want a maintained rule set that mixes ad blocking with China-direct routing, and if you are willing to pick one of the eight .acl variants instead of assuming one fits all. Do not adopt it if you expect a client, a subscription service, or a complete ad blocker: the README states that browser-internal ads will slip through, and the Clash folder is described as fragments that depend on your software's own configuration format. Before committing, verify which .acl variant matches your client (fullgfwlist.acl is the one the README says original SS can use), and check whether your client reads .acl files directly or needs the Clash fragments routed through subconverter first.

Frequently asked questions

Official sources

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