# Johnshall/Shadowrocket-ADBlock-Rules-Forever: iOS Shadowrocket rules rebuilt daily

> A Python-generated family of Shadowrocket rule files, rebuilt every day at 08:00 Beijing time, that decides which domains go direct, which go through the proxy, and which ads get blocked. The choice between blacklist and whitelist defaults is the decision that matters.

**Johnshall/Shadowrocket-ADBlock-Rules-Forever** — 提供多款 Shadowrocket 规则，拥有强劲的广告过滤功能。每日 8 时重新构建规则。

- Repository: https://github.com/Johnshall/Shadowrocket-ADBlock-Rules-Forever
- Website: https://johnshall.github.io/Shadowrocket-ADBlock-Rules-Forever/
- Stars: 30,691 · Forks: 2,040
- Language: Unknown
- License: NOASSERTION
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/johnshall-shadowrocket-adblock-rules-forever

## What Johnshall/Shadowrocket-ADBlock-Rules-Forever actually solves

Shadowrocket is an iOS proxy client, and it is only as good as the rule file you feed it. The original Shadowrocket-ADBlock-Rules project by h2y stopped being maintained, and the README states that the author took it over because Shadowrocket had no comparably fine-grained rule set left. That is the gap this repository fills: a maintained, regenerated set of rule files rather than a static text file that slowly rots as domains change.

The audience is narrow and specific. You need an iOS device, a Shadowrocket installation, and an existing proxy server. The README is explicit that the rules are plain text and cannot provide proxy connectivity on their own. This is a routing and filtering layer, not a service. If you are looking for a way to get online without a server, this project does nothing for you.

What it adds on top of a bare GFWList is the ad filtering. The build pulls in EasyList, EasyList China, Peter Lowe's ad and tracking list, and the Chengfeng rules, converts them into Shadowrocket syntax, and deduplicates the result. Custom iOS-specific rules for web ads, in-app ads, and video ads sit alongside those. That combination is the reason to pick this over pasting a raw GFWList URL into Shadowrocket.

## How the daily build turns upstream lists into Shadowrocket rules

The repository ships generated .conf files at the top level and keeps the generator in a build branch under a factory directory. The README points contributors at three manual_*.txt files in that factory directory, which is where hand-written additions live; everything else is produced by Python from templates. Pull requests go to the build branch, not to the default release branch.

Upstream inputs are GFWList for blocked domains, the cn-blocked-domain list from Greatfire Analyzer, EasyList and EasyList China, Peter Lowe's list, and the Chengfeng rules. Apple and its CDN domains are handled through an optimized list. A top500 website table drives the whitelist variants, and the README notes that the original top500 detection method stopped working because the ranking list is no longer obtainable without an account, so the table was reconstructed from an older ranking and is now partly manual. That is a real weak point: the whitelist files depend on a hand-maintained list the project is asking contributors to refresh.

The README also addresses a common worry about rule size. It states that Shadowrocket builds a search tree, described as a finite state machine over reversed hostnames, with a hash cache on lookups, so a 2000-line rule file and a 50-line file are both O(1) at match time. That claim comes from the README's account of a conversation with the Shadowrocket author, not from an independent measurement, so treat it as the project's position rather than a benchmark.

## Installing the rules in Shadowrocket and testing a first connection

There is no package to install. The rule files are hosted on the project's GitHub Pages site, and you add one by URL inside the Shadowrocket app. The README gives two methods: scan the QR code with Safari or Shadowrocket, or open the Config tab, tap the plus in the top right, paste the rule file URL, and tap download.

The most common starting point is the blacklist plus ad filtering file. Paste this URL where the app asks for it:

```bash
https://johnshall.github.io/Shadowrocket-ADBlock-Rules-Forever/sr_top500_banlist_ad.conf
```

After downloading, the README says to disconnect and reconnect Shadowrocket once so the new rule file takes effect. Then open a site you know is blocked and confirm it loads through the proxy, and open a domestic site and confirm it does not.

If you want the opposite default, where unknown domains are proxied and only known-direct domains bypass, use the whitelist variant instead:

```bash
https://johnshall.github.io/Shadowrocket-ADBlock-Rules-Forever/sr_top500_whitelist_ad.conf
```

For automatic daily refresh, the README describes installing a Shortcuts automation: add the provided shortcut, enter your rule file URL, then create a personal automation at a specific time of 08:05 or later, because generation takes time, and have it run the shortcut. The README notes that if google.cn redirects fail after an update, you should open the rule file's info panel, toggle HTTPS decryption off and back on. The full certificate-trust procedure for that case is documented in the FAQ section of the README.

## Blacklist or whitelist: the choice that decides your experience

The two families differ only in how they treat a domain that appears in neither list. Blacklist files send unknown domains direct; whitelist files send them through the proxy. The README frames this as the main selection question and suggests downloading both and switching if you cannot decide.

In practice the blacklist default is the safer one for a metered or slow proxy, because only known-blocked domains consume proxy bandwidth. Its failure mode is a blocked domain that GFWList has not caught yet, which will silently go direct and fail to load. The whitelist default inverts that: an unknown domain always gets proxied, so nothing blocked slips through, but every new site you visit pays the proxy latency, and a misclassified domestic domain can end up routed abroad.

Beyond those two, the repository offers cnip variants that split by China versus foreign rather than by blocked versus unblocked, direct-only and proxy-only files with ad filtering, a back-to-China pair for people outside the mainland, and an ad-only file. There are also lazy.conf and lazy_group.conf, which the README describes as a lazy configuration with proxy groups. That is a lot of files, and the README's own answer to choice paralysis is to grab the blacklist and whitelist pair.

## Where the ad filtering and the routing both fall short

The README is unusually candid that ad filtering is not complete. It states that the rules do not guarantee 100 percent ad removal, especially for video ads. The reasoning given is that apps like Youku can change their ad strategy with any upgrade, so real-time effectiveness cannot be guaranteed, and that YouTube ads cannot be fully removed through simple URL matching. If your main motivation is a clean YouTube or Youku experience, this project will disappoint you, and the README says so before you download anything.

The routing side has a structural limitation too. The whitelist and blacklist files depend on the top500 table, and the README explains that the automatic top500 detection broke and the table was rebuilt from an older ranking, with a request for pull requests to supply a current one. Until that happens, the direct-versus-proxy split for major sites rests on stale data.

There is also a platform boundary that the related searches around this project keep brushing against. This is an iOS Shadowrocket rule set. The files are Shadowrocket configuration syntax, and the README's install instructions are entirely about the Shadowrocket app on iOS. Nothing in the repository claims Android, macOS, or Windows client support, so if you are looking for a cross-platform rule set, this is the wrong project.

## How it compares with generating your own rules or using a raw GFWList

The obvious alternative is pointing Shadowrocket at the upstream GFWList directly and skipping this project. The difference is conversion and merging. GFWList is in a different format and contains no ad rules at all; this repository converts it, merges four ad and tracking lists into it, deduplicates the result, and republishes it daily in Shadowrocket syntax. If you only need blocked-domain routing and already run a browser ad blocker, the README itself suggests the no-ad variants, which is effectively the raw-GFWList position with better formatting.

A second alternative is forking the repository and running the generator yourself. The README documents this: fork the repo, leave the "Copy the release branch only" option unchecked, and enable Actions in your own repository. That gives you a private rule set you can edit through the manual_*.txt files in the factory directory. The cost is that you now own the build, and the daily 08:00 regeneration becomes your problem rather than someone else's.

A third option is a general-purpose rule set maintained for multiple proxy clients. Those tend to cover more platforms, but they generally do not carry the iOS-specific app and video ad rules that this project adds, and they are not rebuilt on a fixed daily schedule tied to Shadowrocket syntax.

## Licence, maintenance, and what an upgrade costs you

The repository metadata reports the licence as NOASSERTION, which means GitHub could not map the LICENSE file to a recognized identifier. The LICENSE file exists at the top level, so there are terms, but you should read the file itself before redistributing the generated .conf files or reusing them in another product. This is not legal advice, and the practical point is simply that the licence is not a standard one you can assume you already know.

The repository is not archived, and the last push was on 2026-09-09. The single release, v1.0.0, is dated 2022-10-23 and is titled "Time to say Goodbye." That title is misleading in context: releases are not how this project ships. The artifacts are the .conf files on GitHub Pages, regenerated daily, and the README states that all published rules update at 08:00 Beijing time. Judging maintenance from the release list would give you the wrong answer entirely.

Upgrade cost is low by design. You do not install anything, so there is no version to bump. If you use the Shortcuts automation, your client picks up the new file each morning, and the only recurring friction the README documents is the HTTPS decryption toggle after an update. If you fork and run your own Actions build, you inherit the generator and every upstream list change that flows through it.

## Conclusion

Adopt it if you run Shadowrocket on iOS and want ad filtering plus a maintained GFWList-derived split without writing rules yourself. Do not adopt it if you need rules for Android, macOS, or Windows clients, or if you cannot tolerate video ad filtering that the README admits is not guaranteed. Before committing, download both sr_top500_banlist_ad.conf and sr_top500_whitelist_ad.conf, connect once, and check the Shadowrocket log for domains you expect to be proxied that went direct.

## FAQ

### How do I install Johnshall/Shadowrocket-ADBlock-Rules-Forever in Shadowrocket?

Open the Config tab in Shadowrocket, tap the plus in the top right, paste a rule file URL such as https://johnshall.github.io/Shadowrocket-ADBlock-Rules-Forever/sr_top500_banlist_ad.conf, and tap download. The README also allows scanning the QR code with Safari or Shadowrocket. Disconnect and reconnect Shadowrocket once so the new rule file takes effect.

### Do the rules slow down web browsing because they are thousands of lines long?

The README states that Shadowrocket builds a search tree over hostnames with a hash cache, so a 2000-line rule file and a 50-line file both resolve in the same order of time. It attributes this to a conversation with the Shadowrocket author, so it is the project's account rather than an independent measurement.

### Why does Johnshall/Shadowrocket-ADBlock-Rules-Forever not block all video ads?

The README states the rules do not guarantee 100 percent ad filtering, particularly for video ads, because apps such as Youku can change their ad strategy with each upgrade. It also notes that YouTube ads cannot be fully removed through simple URL matching.

### Can I run these Shadowrocket rules on Android, macOS, or Windows?

The repository is built for Shadowrocket on iOS, and the install instructions and rule syntax are specific to that app. The README does not document Android, macOS, or Windows client support, and the rule files are Shadowrocket configuration files rather than a cross-platform format.

### How do I get my own customised version of the rules?

The README says to fork the repository with the "Copy the release branch only" option unchecked and enable Actions in your own repository. Contributions to the shared rule set go through the manual_*.txt files in the factory directory, with pull requests sent to the build branch.

## Sources

- [Issues](https://github.com/Johnshall/Shadowrocket-ADBlock-Rules-Forever/issues)
- [Johnshall/Shadowrocket-ADBlock-Rules-Forever on GitHub](https://github.com/Johnshall/Shadowrocket-ADBlock-Rules-Forever)
- [Project website](https://johnshall.github.io/Shadowrocket-ADBlock-Rules-Forever/)
- [README](https://github.com/Johnshall/Shadowrocket-ADBlock-Rules-Forever/blob/release/README.md)
- [Releases](https://github.com/Johnshall/Shadowrocket-ADBlock-Rules-Forever/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/johnshall-shadowrocket-adblock-rules-forever