Shadowrocket-ADBlock-Rules-Forever: Daily-Rebuilt Rule Files for iOS Ad Blocking and Routing
提供多款 Shadowrocket 规则，拥有强劲的广告过滤功能。每日 8 时重新构建规则。
At a glance
- What is it?
- This repository publishes generated Shadowrocket configuration files that combine GFWList routing with EasyList and other ad-block lists, rebuilt every day at 08:00 Beijing time. It is a rule-generation project, not a proxy, and its value depends on whether you accept a maintainer-curated list of which sites go direct and which go through a proxy.
- Who is it for?
- Adopt it if you run Shadowrocket on iOS, want one URL that updates every morning at 08:00 Beijing time, and are comfortable with a curated blacklist or whitelist split rather than per-app rules. Do not adopt it if you need per-application routing, if you rely on video ad blocking inside apps like Youku, or if you object to a rule file that embeds the maintainer's own political framing in its README.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: Shadowrocket ships no routing decisions, only a proxy engine
Shadowrocket on iOS is a proxy client. It does not decide which hostnames should go through the tunnel and which should connect directly. That decision lives in a configuration file, and writing one by hand means maintaining thousands of domain entries against a moving target: sites get blocked, unblocked, moved to new CDNs, and ad networks rotate hostnames. This repository exists to remove that maintenance. It publishes ready-made .conf files that Shadowrocket can download by URL, so the user pastes an address rather than editing a list.
The intended audience is narrow and specific. It is iOS users who already have Shadowrocket installed and a proxy endpoint configured. The README states plainly that the rules are a plain text file and cannot provide the proxy itself: they define which sites are direct and which are proxied. Anyone without a working Shadowrocket setup gets nothing from this repository. The secondary audience is contributors who want to correct a misclassified domain by editing one of three manual_*.txt files under the factory directory on the build branch.
What the generator actually assembles
The README describes the build inputs. The blacklist side is converted automatically from the current GFWList, with domains detected by the Greatfire Analyzer project added. The ad-blocking side converts EasyList, EasyList China, Peter Lowe's ad and tracking list, and the Chengfeng rules into Shadowrocket syntax, with duplicates removed. On top of those, the project adds its own rules aimed at iOS web ads, in-app ads and video ads. Apple and its CDN domains are handled through an optimised list derived from felixonmars/dnsmasq-china-list, specifically the apple.china.conf file.
One input has a known gap. The README says the world top 500 site list can no longer be obtained without an account or payment, so the original top500 detection method stopped working. The maintainer rebuilt a top500 connectivity table from the old list and asks for pull requests against top500_manual.list under factory/resultant on the build branch. That is a real weakness: the whitelist and the two top500 banlist variants depend on a table that is now partly hand-maintained and, by the maintainer's own account, outdated at the source.
Twelve rule files, and how they differ
The README lists twelve published configurations. Four of them are the blacklist and whitelist pairs with and without ad blocking: sr_top500_banlist_ad.conf, sr_top500_banlist.conf, sr_top500_whitelist_ad.conf and sr_top500_whitelist.conf. The difference between blacklist and whitelist is the default treatment of an unknown site. A blacklist file connects unknown domains directly and proxies only what is on the blocked list. A whitelist file proxies unknown domains and connects only the listed ones directly. The README frames this as the main choice a user faces.
Four more cover geography rather than lists: sr_cnip_ad.conf and sr_cnip.conf send Chinese sites direct and foreign sites through the proxy, while the two return-to-China files do the reverse, proxying Chinese sites and connecting foreign ones directly. Two files turn Shadowrocket into a device-wide ad blocker: sr_direct_banad.conf connects everything and only filters ads, and the proxy variant routes everything except LAN traffic through the proxy while filtering ads. The remaining entries are the lazy configurations with and without policy groups, which the README describes as proxying foreign sites and connecting domestic ones.
All twelve, per the README, connect LAN requests directly. The README also notes that a user can download several files and switch between them.
Getting a rule file into Shadowrocket
There are two documented methods. The first is scanning the QR code shown next to each rule with Safari or with Shadowrocket itself. The second is manual: open the Shadowrocket app, go to the Configuration page, tap the plus sign in the top right corner, paste the rule file URL into the url field, and tap download. The README advises disconnecting and reconnecting Shadowrocket once afterwards so the new file takes effect.
For automatic updates, the README gives a Shortcuts workflow. Install the shared shortcut, fill in the rule file address, then open Shortcuts, go to Automation, tap plus, choose Personal Automation, pick Time of Day, set it to 08:05 or later (the README notes rule generation takes time), add an action, choose the Shortcuts app, select Run Shortcut, pick the Shadowrocket rule update shortcut, and optionally turn off Ask Before Running. The 08:05 floor matters because the published files are rebuilt at 08:00 Beijing time; scheduling earlier means fetching the previous day's file.
Two troubleshooting notes are documented. If Safari cannot redirect requests to google.cn, the README says to tap the info icon next to the active rule, open HTTPS Decryption, toggle it off, go back, and toggle it on again. The FAQ gives a longer certificate path for the same symptom: enable HTTPS Decryption, install the certificate, then go to Settings, General, About, Certificate Trust Settings, and enable full trust for the root certificate.
Where the rules fail, by the maintainer's own account
The FAQ is unusually direct about ad blocking limits. The rules do not guarantee filtering all ads, and video ads are called out specifically. The reasoning given is that apps such as Youku can change their ad strategy with any update, so real-time effectiveness cannot be guaranteed. YouTube ads, the README states, cannot be fully removed through simple URL matching. Anyone buying into this project expecting system-wide video ad removal is buying the wrong thing.
A second documented failure is regional Apple Podcasts not loading. The FAQ points to a fix in another project's issue tracker: add podcasts.apple.com, bookkeeper.itunes.apple.com, play.itunes.apple.com and xp.app.com to the proxy list. Note that the README writes xp.app.com in this FAQ entry while the linked issue concerns Apple endpoints, so treat the exact hostname as something to verify against your own Shadowrocket log rather than copying blindly.
A third limitation is structural. Because these are curated lists, any domain the maintainer has not classified falls to the default of whichever file you chose. A blocked site missing from GFWList goes direct and fails. A directly reachable site wrongly listed gets proxied and slows down. The README's own contribution guidance assumes this: when something misbehaves, turn on Shadowrocket logging, find whether a blocked domain went direct or a direct domain went through the proxy, and report it.
How this differs from a general-purpose rule set
The closest comparison in the README is the original h2y/Shadowrocket-ADBlock-Rules project, which the maintainer states is no longer maintained. The stated motivation for this fork is that no other Shadowrocket rule set divides traffic as finely. That is a claim about granularity, and the twelve-file matrix supports it: the split between blacklist and whitelist, between geographic routing and list-based routing, and between ad-filtering and non-ad-filtering variants gives a user more starting points than a single all-purpose configuration.
The practical difference from a general rule set such as a Surge or Clash profile is scope. Those formats target different clients with different matching engines. This project emits Shadowrocket syntax only, and the README states compatibility with Shadowrocket is a design goal. If you are not on Shadowrocket, the files are not portable without conversion.
On the performance question, the FAQ makes a specific technical claim: Shadowrocket builds a search tree, described as a finite state machine over hostnames read from the back, with a hash cache on match results, so a 2000-line rule file and a 50-line rule file are both O(1) at match time. That claim is attributed to a conversation with the Shadowrocket author, not to a published benchmark, and it should be read as the maintainer's report rather than measured evidence.
Maintenance, licence and the parts of the README that are not documentation
The update mechanism is the project's main operational cost, and it is mostly borne by the maintainer. Rules are rebuilt and republished daily at 08:00 Beijing time. For a user, maintenance is close to zero: set the Shortcuts automation to 08:05 and the device fetches the new file. For a contributor, maintenance means editing one of three manual_*.txt files in the factory directory and sending the pull request to the build branch, not the default release branch. The README also documents self-hosting: fork the repository, leave Copy the release branch only unchecked, and enable Actions in your own repository to generate custom rules.
Licensing is unresolved in the material available. The repository is marked NOASSERTION, and the README does not state terms for the generated .conf files. Since the build pulls in GFWList, EasyList, EasyList China, Peter Lowe's list and the Chengfeng rules, the terms that apply to those upstream lists may carry through to the output. That is a question for whoever redistributes the files, and it is not answered here.
The README also contains a lengthy political preamble telling readers to protect themselves and asking opponents to leave the project. It is the maintainer's personal statement and has no bearing on how the rule files work, but anyone evaluating the project for a team or an organisation should know it is there before pointing colleagues at the repository.
Editorial conclusion
Adopt it if you run Shadowrocket on iOS, want one URL that updates every morning at 08:00 Beijing time, and are comfortable with a curated blacklist or whitelist split rather than per-app rules. Do not adopt it if you need per-application routing, if you rely on video ad blocking inside apps like Youku, or if you object to a rule file that embeds the maintainer's own political framing in its README. Before committing, verify which of the twelve published .conf files matches your traffic pattern, and confirm the licence status, since the repository is marked NOASSERTION and the README does not state terms for the generated files.
Community notes