Shadowrocket configuration files: selective routing rules for iOS

What the repository is, and what it is not

The project description is in Russian and reads as configuration files and lists with automatic updating for the Shadowrocket application. The README expands on that: selective protection of internet traffic on iOS, iPadOS, macOS and tvOS through the Shadowrocket app, for users from Russia, built on refined routing rules that direct traffic through proxy servers for specified domains and ports.

So the object of the project is a set of routing rules, not a networking stack. Shadowrocket itself is the client that reads these files and applies them, and the actual proxy servers are supplied by the user elsewhere. What lives here is the policy: which domains go direct, which go through the tunnel, and which sub-rules handle a popular service correctly.

The scope is deliberately about selective routing rather than routing everything through a proxy. The basic profile sends all traffic directly through the operator except for the domains in the list, which use the proxy. That is a different trade from a full-tunnel setup, and it is the design most people in the situation this project targets actually want, because full tunnelling breaks local services and adds latency to everything else.

The repository layout matches the deliverables. There is a `conf/` directory for the finished configuration files, a `rules/` directory for the domain lists, a `modules/` directory for the Shadowrocket modules, a `scripts/` directory, a `source/` directory, and `.github/` for the automation that keeps the lists updated.

The last push to the default branch was on 2026-10-20, and the repository is not archived, so the lists are being maintained even though the most recent recorded release is dated 2025-07-12.

Three profiles, and the choice between them

The README tabulates the ready-made configurations, and the differences between them are the substance of the project.

`sr_ru_basic.conf` is the base configuration where all traffic goes directly through the operator except for the domains in the list, which use the proxy. It includes the lists from the community and the ports for voice traffic.

`sr_ru_geo.conf` inverts the default: everything goes through the proxy except for Russian domains, which stay outside the tunnel. The README describes it as the best option for Telegram, WhatsApp and FaceTime calls, and points to additional geographic databases linked on line 94 of the file. It also warns that page load times from the App Store may increase and that there may be other drawbacks the author has not yet found.

`sr_ru_whitelist.conf` is the third: direct through the provider, everything else through the proxy.

That last pair deserves care, because the naming is not self-explanatory. The basic profile sends most things direct and only the listed domains through the proxy, while the whitelist profile sends most things through the proxy and only the listed ones direct. The two are close to inverses of each other, and the practical difference is what your traffic looks like when the tunnel is slow or down.

There is also `sr_ru_extended.conf`, which the README recommends for adding your own rules when something is not in the lists. The reason it is a separate file is stated plainly: it is convenient that nothing breaks after an update. Your own rules live in a file you control, and the downloaded lists can be replaced underneath it.

A fifth profile, `sr_nonru_basic.conf`, is for people located abroad, proxying all Russian domains and domains written in Cyrillic.

DOMAIN-KEYWORD and DOMAIN-SUFFIX, and why the sub-rules matter

The features section explains the two routing constructs the configuration leans on, and the reason for each.

For popular domains, for example Instagram and YouTube, an additional `DOMAIN-KEYWORD` sub-rule is applied. A keyword rule matches on a substring of the hostname, so it catches the many different hostnames a single service uses, including the ones nobody has added to a list yet.

`DOMAIN-SUFFIX` sub-rules are used for correct operation with subdomains, extending the capability if a new subdomain appears. A suffix rule matches the domain and everything under it, so adding a domain once covers its whole subdomain tree.

Those two mechanisms together are what make a maintainable rule set possible, and the difference in failure mode is instructive. A pure domain list has to enumerate every hostname, so a new CDN endpoint is traffic that quietly goes direct until somebody notices. A keyword rule for a popular service catches the unknown hostnames as a side effect, at the cost of occasionally matching more than intended.

The cost of that is the reason the two are used selectively rather than universally. A keyword rule on a short or common substring can pull in unrelated traffic, which is exactly the kind of mistake a user notices as a slow or broken site. The configuration applies the looser construct only where the service is known to be spread across many hostnames.

The `sr_ru_extended.conf` route completes the picture. Rather than editing a downloaded file, which would be overwritten on the next update, the user points the app at their own file and adds rules there.

Modules for YouTube and certificate handling

The modules section covers two Shadowrocket modules with quite different purposes.

The first is `YT-Premium-V1-RU.module`, for YouTube. The README describes it as available with Chinese subtitles disabled and with the necessary rules, and it requires issuing an HTTPS certificate on the device. The platform note is specific and worth repeating: it works well on iOS, poorly on macOS, and does not work on Apple TV.

The second is the `Certificate` module, and its purpose is practical rather than cosmetic. It is for decrypting certificates, and the README says you will not have to re-issue certificates after every iOS update. The procedure is to create one certificate once and put your own ca-passphrase and ca-p12 into it.

That is a genuinely useful piece of automation. Certificate re-issuing after an OS update is the recurring chore in any setup that intercepts TLS traffic, and a module that survives the update removes it.

Both modules live in the `modules/` directory, and the YouTube module is fetched from a `release` branch of the repository while the Certificate module is linked from `main`, so the two are versioned differently on purpose, with the YouTube one tracking a release line of its own.

The lists, and where more of them come from

The current lists section names three files, and each has a distinct purpose.

`domains_community.list` holds the domains of the community around the Shadowrocket Russian chat, and it includes universal rules for popular domains. `banking.list` is a list of bank and financial service domains taken from the Central Bank of Russia, which is a specific and practical concern for people who need those services to keep working while other traffic is proxied. `domains_ipchecker` covers the checkers used in Russian applications.

That third file is worth a moment's thought, because it shows the design intent. Russian applications often call home to an IP checking service to decide what to show or whether to work at all, and if that call is not routed the same way as the rest of the application the app misbehaves. A rule list that keeps those checks consistent is a small thing that prevents a large annoyance.

The README also points elsewhere for more lists. It recommends the popular lists from Blackmatrix7, giving the Telegram rules as the example, and suggests looking for current lists in different formats on IPlist, noting that the Text format suits Shadowrocket.

So the ecosystem is layered. This repository provides the profiles and the community-specific lists, and pulls in the large general-purpose rule sets from elsewhere, with the `rules/` directory holding what lives here.

The whole point of the automatic updating mentioned in the description is that a rule set maintained by hand goes stale within weeks, and a stale rule set is a proxy configuration that leaks or breaks traffic in ways that are hard to diagnose.

Where this configuration set is the wrong tool

The first wrong-tool case is a client other than Shadowrocket. These are Shadowrocket configuration files with Shadowrocket modules and Shadowrocket rule syntax, and the `DOMAIN-KEYWORD` and `DOMAIN-SUFFIX` constructs are read by that app. A user on a different proxy client needs the equivalent lists in that client's format, and the README says the Text format is the one that suits Shadowrocket, which implies the other formats are not interchangeable.

The second is a user who wants a node list. The repository contains rules and policies, not servers. The generator page linked from the README is where a configuration is assembled, and the README describes that as the way to configure and download a config for your own device, with the ready-made files here as a starting point. A repository of rules cannot route anything without servers behind it.

The third is a platform where the modules do not work. The YouTube module is documented as working well on iOS, poorly on macOS, and not at all on Apple TV, so a tvOS user relying on it will be disappointed, and the certificate module's value depends on Shadowrocket's own TLS interception behaviour on that platform.

The fourth is a situation that needs a per-application decision rather than a domain list. The rules operate on hostnames and ports, so an application that talks to a shared CDN endpoint with other services cannot be singled out by these files, and the README's own answer to that case is for the user to write their own rules into `sr_ru_extended.conf`.

The alternative worth naming is the general-purpose rule sets the README itself points to, such as the Blackmatrix7 lists, which cover far more services and are maintained on their own cadence. The difference in approach is that those are broad and service-agnostic, while this repository is narrow and specific: a small set of profiles, tuned for one country's situation, with the community lists, the banking domains and the IP checkers that a general-purpose set would not have, and a geo profile that a general-purpose list does not provide at all.

Support, updates, and the state of the licence

Support runs through a Telegram chat and a blog rather than an issue tracker, and the README links both. Discussion of the configurations and settings happens in the chat called Про Shadowrocket на русском, the blog carries detailed instructions on setup, usage and additional features, and the project can be supported through a donation link.

The release history in the project metadata shows the naming convention, which is a build timestamp rather than a semantic version: 202507121744, then 202507121726, then 202507121725, all on 2025-07-12. Three builds in about twenty minutes, which is what an automatic regeneration looks like when the lists are rebuilt on a schedule.

That is the right convention for this kind of artefact. There is no API to break, so a timestamp tells you exactly when the rules were current, and the last push on 2026-10-20 says the repository is still being generated even though the recorded release tags are older.

The licensing position needs a caveat. The project metadata records the licence as unknown and the primary language as unknown, and the README does not carry a licence statement. The visible content is a mix of Russian prose, configuration files, and lists, some of which are described as coming from the Central Bank of Russia site and from community sources. So before you redistribute these lists inside a configuration of your own, or use them on a work device, check what the terms are with the maintainer, and consider that a list compiled from another party's data carries that party's terms with it.

The `scripts/` and `source/` directories are the parts to look at if you want to know how the update works, since they hold the generation side, and the `conf/` and `rules/` directories are the parts you actually consume.

Editorial conclusion

Adopt these configuration files if you already run Shadowrocket on iOS, iPadOS, macOS or tvOS and want a maintained set of routing rules for a selective split, since the difference between the basic, geo and whitelist profiles is the whole design of the project and the community lists are updated on their own cadence. Do not adopt it as a client, a proxy server or a source of node configurations, because the repository contains only rules, lists and modules, and node servers are supplied elsewhere. Before you rely on it, check the `conf/` and `rules/` directories for the profile that matches your situation, read the generator page linked from the README rather than hand-editing a file, and note that the recorded licence and primary language are both unknown in the project metadata, so confirm the terms before redistributing the lists inside your own configuration.

Frequently asked questions

Official sources

1. Issues
2. misha-tgshv/shadowrocket-configuration-file on GitHub
3. README
4. Releases