# igareck/vpn-configs-for-russia: How to Use the VLESS and Shadowsocks Subscriptions

> A repository of auto-tested VPN subscription files for Russia, filtered into black CIDR/SNI and whitelist categories. Here is how the files are organised, how to import them, and where the approach breaks down.

**igareck/vpn-configs-for-russia** — 🗽Бесплатные и проверенные VPN конфигурации, работающие в РФ ⚪ Белые списки / обход белых списков ⚪ Free and checked VPN configurations that work in Russia ⚪ Whitelists bypass

- Repository: https://github.com/igareck/vpn-configs-for-russia
- Website: https://t.me/igareq
- Stars: 8,991 · Forks: 446
- Language: Unknown
- License: GPL-3.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/igareck-vpn-configs-for-russia

## What igareck/vpn-configs-for-russia actually distributes

This is not a VPN service. It is a distribution point for subscription files. The repository holds plain text lists of proxy configurations in VLESS, Trojan, Shadowsocks, Hysteria2, VMess and Tuic formats, and each list is meant to be pasted into a client as a subscription URL. The README frames the target audience narrowly: users inside the Russian Federation who need to reach blocked resources, and who have found that conventional VPN protocols no longer connect. The README states plainly that OpenVPN, WireGuard and similar protocols have not worked for a long time, and that paying for a subscription does not change that. The project's answer is protocol-level rather than vendor-level: use configs that were tested from a server located in Russia, and refresh them often. Two categories exist side by side. The BLACK_* files are aimed at ordinary blocking conditions, while the WHITE-CIDR-RU-* and WHITE-SNI-RU-* files plus Vless-Reality-White-Lists-Rus-Mobile.txt are aimed at whitelist regimes, where only a defined set of destinations is reachable at all. That split is the most useful thing about the repository. A single "working VPN list" would be useless to someone whose traffic is filtered by destination CIDR, and the maintainer has separated those cases into different files. A TOR-BRIDGES directory and a QR-codes directory sit alongside, for users who prefer scanning over copying URLs.

## How the subscription files are filtered and refreshed

The README describes a pipeline rather than a static list. Configs are collected, then tested on a server inside Russia before publication, and slow or dead entries are dropped. The stated cadence is every two to four hours, with the interval depending on the subscription type. The README claims the tests cover reachability, latency and speed, and distinguishes this from plain aggregation plus deduplication. It also gives a timeline: from 13 November to 28 December 2025 the process was manual, and on 28 December a script was finished that automated the checks while, in the maintainer's words, preserving the same high manual result. The README says the script undergoes regular audit. Treat that as a claim from the maintainer, not an independently verified benchmark; no test methodology, sample size or measurement tool is published. The filtering dimension is what matters operationally. Files are separated by black CIDR, black SNI and whitelist categories, so the file you choose has to match the filtering you are actually behind. Choosing a black-list file while your connection is in whitelist mode will produce a list of endpoints you cannot reach. The repository has no releases, so updates arrive as commits to the text files on the main branch rather than as versioned artefacts.

## Installing nothing: importing a subscription into Karing, v2rayN or Happ

There is no package to install. Setup means copying a raw URL into a client. The README names Karing, Clash Verge Rev, Clash Mi, v2rayN, Happ, Streisand and Throne as clients that accept these subscriptions, and notes the files are TXT, YAML or JSON depending on the file. The critical step, and the one the README spends the most space on, is which host you fetch from. The project warns that GitHub may be blocked in Russia and asks users to switch the raw links in their clients from raw.githubusercontent.com to a mirror. The mirrors listed are GitLab, Codeberg, Gitea, SourceHut, Bitbucket, GitHack and a Yandex plus Bitbucket combination. GitLab is described as the best mirror. GitHack is described as working even for users who see a blocked-IP or blocked-country message elsewhere. The Yandex plus Bitbucket pairing is specifically for whitelist mode, and the README warns that other Yandex pairings break the configurations. The README states that subscribers verified configs loaded through Yandex plus Bitbucket in Karing, Clash Mi and v2rayN/v2rayNG while in a whitelist regime. To get a raw link from a mirror, the README says to open the same-named txt file, click the button labelled RAW, Open Raw, View Raw or the Russian equivalent, then copy the address bar. The repository also publishes ready-made links in a MIRRORS.md file and a mirrors section of the README. What you should see after adding a subscription URL in your client is a list of VLESS entries with host, port and transport parameters populated. If the list is empty or every entry fails, the mirror URL is the first thing to change, not the client. The repository also ships QR codes, so a phone client can be configured by scanning instead of pasting a URL. For whitelist networks, the file to start from is one of the WHITE-CIDR-RU-* or WHITE-SNI-RU-* lists, or Vless-Reality-White-Lists-Rus-Mobile.txt for mobile.

## Where this approach fails

Public configs are shared infrastructure, and the README says so directly: they appear quickly and stop working quickly, which is why auto-refresh exists. The consequence is that any single endpoint is disposable. If you need a stable IP for a whitelisted service, a corporate allowlist entry, or a long-lived session, this repository is the wrong tool. There is no uptime commitment, no support channel beyond a Telegram channel, and no way to know how many other users share an endpoint at any moment. The testing claim is also unverifiable from what is published: the README says tests run on a server in Russia and cover latency and speed, but publishes no thresholds, no failure criteria and no audit report. A config that passed at 04:00 may fail at 08:00, and the two-to-four-hour refresh window is exactly the gap in which that happens. Protocol coverage is another boundary. The README's position is that OpenVPN and WireGuard do not work in this environment, so anyone whose client or router only speaks WireGuard cannot use this repository at all. Finally, the whole distribution model assumes you can reach a mirror. If every listed mirror is unreachable from your network, the project has no fallback beyond the Yandex plus Bitbucket proxy for whitelist mode, and that pairing is documented as fragile.

## Compared with running your own Xray or VLESS Reality server

The real alternative is not another list of configs. It is renting a VPS outside Russia, installing Xray yourself, and generating your own VLESS Reality inbound. The difference in approach is ownership of the endpoint. With a self-hosted server, the IP is yours alone, it does not rotate, and nobody else's traffic affects your latency. The trade-off runs the other way: a single static IP is also a single point of failure, and if it is blocked you have to obtain a new address, which is exactly the churn this repository absorbs for you by rotating through many configs. Self-hosting also requires you to keep the server patched and the Reality parameters current, whereas here the maintainer's script does the filtering. A second alternative is a commercial VPN with a proven obfuscation layer, but the README's stated position is that paying does not help if the protocol itself is detected, which is the argument for the config-based route. The honest summary is that this repository trades stability for variety. You get many endpoints that are individually unreliable but collectively refreshed; a self-hosted server gives you one endpoint that is reliable until it is not.

## Licence, mirrors and the cost of staying current

The repository is licensed GPL-3.0. That matters if you intend to reuse the file formats, the filtering scripts or the repository structure in your own project: GPL-3.0 carries copyleft obligations for derivative works, and the licence text in the repository is the authoritative source rather than any summary here. For a user who simply imports a subscription URL into a client, the licence is not the operative concern. The maintenance cost is real, though it falls mostly on the maintainer, not the user. The README describes an automated script that tests and republishes every two to four hours, and says that script is audited. From the user's side the recurring task is smaller but not zero: you must keep the subscription URL pointed at a reachable mirror, and you must re-check that choice if GitHub access changes. The mirror list is the part of this project most likely to need your attention, because it exists precisely for the case where the primary host is unreachable. The last push to the repository was on 2026-09-21, and the repository is not archived. There are no releases, so there is no version to pin; you are tracking the main branch's text files whether you intend to or not.

## Conclusion

Adopt this repository if you are in Russia, already run a client like Karing, Clash Verge Rev, v2rayN or Happ, and want a rotating pool of configs rather than a single paid tunnel. Do not adopt it if you need a service level agreement, a static endpoint, or a guarantee that any given config still works tomorrow: the README itself describes public configs as appearing and dying quickly. Before you point a client at it, open the mirror table in MIRRORS.md, replace any raw.githubusercontent.com subscription URL with a mirror raw URL, and confirm the file you picked matches your network mode (black CIDR, black SNI, or whitelist).

## FAQ

### Which VPN configs in igareck/vpn-configs-for-russia are still available in Russia?

The repository does not mark individual configs as available or unavailable. Instead it publishes whole subscription files that were tested on a server in Russia before publication, with slow and non-working entries removed, and refreshes them every two to four hours depending on the subscription type.

### What VPN should I use in Russia according to igareck/vpn-configs-for-russia?

The repository does not recommend a single VPN service. Its position is that OpenVPN, WireGuard and similar protocols no longer work in Russia regardless of whether the subscription is paid, so it distributes VLESS, Trojan, Shadowsocks, Hysteria2, VMess and Tuic configurations that were tested for that environment.

### How do I get Russia VPN configs from igareck/vpn-configs-for-russia?

Open one of the txt subscription files in the repository or a mirror, take its raw URL, and add that URL to a client such as Karing, Clash Verge Rev, Clash Mi, v2rayN, Happ, Streisand or Throne. The README recommends replacing raw.githubusercontent.com links with a mirror, and the repository also publishes QR codes.

### Can I get a v2ray configuration for Russia from igareck/vpn-configs-for-russia?

Yes. The repository distributes VLESS, Trojan, Shadowsocks, Hysteria2, VMess and Tuic configurations, and the README lists v2rayN and v2rayNG among the clients that accept its subscriptions. The v2ray-family files include BLACK_VLESS_RUS.txt and BLACK_VLESS_RUS_mobile.txt.

## Sources

- [igareck/vpn-configs-for-russia on GitHub](https://github.com/igareck/vpn-configs-for-russia)
- [Issues](https://github.com/igareck/vpn-configs-for-russia/issues)
- [License: GPL-3.0](https://github.com/igareck/vpn-configs-for-russia/blob/main/LICENSE)
- [Project website](https://t.me/igareq)
- [README](https://github.com/igareck/vpn-configs-for-russia/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/igareck-vpn-configs-for-russia