# all_subs updates two files every minute and asks you not to use the subscription if you have no restrictions

> A public-domain collection of VPN configurations for use when Russian mobile operators deploy white-list filtering. Most of its entries are CIDR configs, it offers a random endpoint that returns a different set on every fetch, and the author explicitly asks you to set it up before you need it rather than during an outage.

**solovyov-jenya2004/all_subs** — Бесплатные, автообновляемые VPN‑конфигурации для использования при развёртывании белых списков мобильного интернета в Российской Федерации.

- Repository: https://github.com/solovyov-jenya2004/all_subs
- Website: https://solovyov-jenya2004.vercel.app/final_sorted
- Stars: 73 · Forks: 3
- Language: Unknown
- License: CC0-1.0
- Published: 2026-08-21 · Updated: 2026-08-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/solovyov-jenya2004-all-subs

## The documentation asks you not to use it while you are unfiltered

The most unusual instruction in the documentation is a request to stand down. If you currently have no restrictions, you are asked not to use the subscription, and instead to update it in advance so it is ready for the next time the filtering comes back. That is a deliberate choice rather than modesty: the endpoints carry free public servers, and a subscription that everyone holds constantly would concentrate load on whichever configurations happen to be working. The same paragraph handles the opposite failure. If none of the named sites open at all, you are most likely under a full internet shutdown rather than a white list, and the collection will not help you there. The diagnostic it offers is concrete: Yandex, VK, Gosuslugi, Ozon and Rutube open while Google, the App Store, Wikipedia and Steam do not.

## A white list is a security measure, switched on during drone attacks

The filtering regime is described with its stated reason, which is worth knowing because it explains the timing you will notice it. A white list is a mode where everything is prohibited except sites approved by the Russian Ministry of Digital Development, and it is switched on by mobile operators for security reasons, with attacks by unmanned aerial vehicles named as an example of when it happens. That framing has two practical consequences. First, the restriction is not a permanent property of your network and does not follow your SIM card to another region, so a configuration that stops working may be blocked for a reason that expires on its own. Second, because the list is operator-side and can be enabled quickly, the useful moment to subscribe is in advance. The documentation is explicit that SNI configurations, which disguise the real address behind an allowlisted one, are rarely needed, because such blocks are seldom used in practice.

## CIDR is the config type that survives the strictest filtering

Two techniques appear in the collection and they are not interchangeable. CIDR configurations are recommended as the most reliable approach under maximum restrictions, and the reason is structural: when an operator allows only a short set of address ranges, the tunnel is built over those allowed ranges themselves rather than trying to reach a blocked one. SNI configurations instead mask the real address behind an allowlisted one, which is a different mechanism for a different kind of block. The guidance is that most entries here are CIDR, and the practical instruction is to look for the CIDR marker in the configuration names when picking servers. That marker is doing real work at the point of selection, because a list mixing both types will otherwise get sampled at random and the SNI entries are the ones that will not help.

## Two files, refreshed every minute, in plain and Base64 form

The repository holds the entire subscription in two files at its root, and a workflow regenerates both every minute. One contains all configurations with one per line, which is what most clients read directly. The other holds the same set encoded in Base64, which exists because some clients expect the subscription body in that form rather than as raw lines. Both are served directly, so the only choice a client makes is which of the two URLs you subscribe to. The repository root also contains two provenance files, one listing current sources and one listing sources that are no longer used, which together explain where the configurations come from and what has been retired. Two workflow badges sit above the documentation for the main run and for a separate check on those source files.

## The random endpoint returns a different set on every fetch

The mobile endpoint behaves unlike the static files and is the part most worth understanding. Where the plain files always return the whole collection, this endpoint returns a new random selection from that same pool each time it is called, and the stated reason is twofold: it spreads load more evenly and it finds working servers faster. The default size is 100 configurations. You can ask for a different count by adding a query parameter, with the number after it, so a request for 50 returns 50 and a request for 200 returns 200. The consequence for a client with auto-update is that each refresh produces a different composition rather than the same list re-served, which is the behaviour you want against a filter that changes, and the behaviour you would not want if you were pinning a known-good server. The three endpoints are:

```
https://solovyov-jenya2004.vercel.app/final_sorted/
```
```
https://solovyov-jenya2004.vercel.app/final_sorted_base64/
```
```
https://solovyov-jenya2004.vercel.app/random/
```

The first two are static content rewritten on a schedule. The third is generated per request, which is why the count parameter applies to it alone.

## The same two files are mirrored across a dozen separate hosts

The documentation spends more space on mirrors than on the subscription itself, and the reason follows from the premise. If you need these configurations, you are on a network most likely to be throttling or blocking the host that serves them, so a single origin is a single point of failure exactly when it matters. The mirrors are listed as nested groups: the GitHub raw endpoints, then a content delivery network with three of its own regional entry points, then several independent proxies, then two deployments of the same application on serverless and container platforms. Each mirror group carries the plain and Base64 links, and the ones that proxy the random endpoint repeat the identical behaviour, including the count parameter. The grouping makes the redundancy legible: several routes to the same origin, plus several routes that terminate the request somewhere else entirely.

## There are no releases, and the licence is public domain

The repository publishes continuously and has no tagged versions at all, which is consistent with an artefact that is rewritten every minute. There is nothing to install and nothing to pin: a client subscribes to a URL and the content behind that URL changes under it. The licence is CC0, a public-domain dedication, which is the simplest possible answer to what may be redistributed, and it is paired with an explicit acknowledgement to the creators of the current subscriptions whose configurations formed the basis of the collection. The default branch is main and the most recent push is dated 30 September 2026, so the files are being regenerated as of that date. Taken together, the publishing model is closer to a feed than to a package, and reading it that way tells you where the maintenance burden actually sits.

## Conclusion

Set all_subs up before you need it if you are on a Russian mobile network and want a fallback ready, because the subscription is refreshed every minute but the author's own advice is to configure it in advance rather than during a restriction event. Do not expect it to help if nothing loads at all, because a total shutdown is a different problem from a white list and the documentation says so plainly. When you import, look for the CIDR marker in the configuration names, since those are the ones built for the strictest filtering, and use the random endpoint rather than the static file if you want the load spread across servers. And note that the collection is published under a public-domain licence with no releases, so there is no version to pin and no changelog to check.

## FAQ

### What do I subscribe to in all_subs?

Two files, both refreshed every minute: final_sorted holds all configurations one per line, and final_sorted_base64 holds the same set in Base64 form. Pick whichever your client expects.

### How many configurations does the all_subs random endpoint return?

One hundred by default. You can set the count with a query parameter, so appending ?n=50 returns 50 configurations and ?n=200 returns 200. Each fetch returns a different random selection from the pool.

### Will all_subs help if my internet is completely blocked?

No. If none of the listed sites load at all you are under a full internet shutdown rather than a white list, and the documentation states this collection cannot help with that.

### Which configurations should I pick from all_subs?

The CIDR ones. They are recommended as the most reliable under maximum restrictions, most entries in the collection are of that type, and the configuration names carry a CIDR marker you can filter on.

## Sources

- [Official documentation](https://solovyov-jenya2004.vercel.app/final_sorted)
- [Official README](https://github.com/solovyov-jenya2004/all_subs#readme)
- [Project repository](https://github.com/solovyov-jenya2004/all_subs)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/solovyov-jenya2004-all-subs