vpn-vless-configs-russia: a proxy config pipeline that refreshes itself

What the repository actually is

vpn-vless-configs-russia is described as an automatic collection of VPN configurations with a focus on Russia and the CIS region, and the description calls it a free VLESS, VMESS and Shadowsocks proxy configuration repository with an automated validation and rotation system. The distinction between a collection and a client is the first thing to understand. Nothing here runs a tunnel, there is no proxy server code, and there is no account system. What there is, is a list of configurations that other clients consume, maintained by a pipeline that runs on a schedule. The stated purpose of the project is educational, for studying cryptographic protocols and network security, and the disclaimer is specific about what it does not do: it does not call for breaking the law, it does not guarantee that the configurations work, it does not take responsibility for what users do with them, and all the data comes from public sources. The homepage is a Telegram channel rather than a website.

The fifteen minute pipeline

The engineering content of the project is the automation, and the workflow diagram in the overview shows four stages. The first is collection, from fifty or more GitHub repositories, from Telegram channels and from RSS feeds. The second is filtering, with deduplication, a geographic filter and validation. The third is saving the results into the clean/ and ru-sni/ directories. The fourth is committing and pushing the output back to the repository, with a GitHub Actions workflow running every fifteen minutes and an automatic commit of the results. There is also a manual trigger through workflow_dispatch, statistics collection, and Telegram notifications. The schedule is the point: a list of free proxy configurations goes stale in hours, so a fifteen minute cycle is not a convenience, it is the minimum for the list to be worth anything. The dependencies are correspondingly small, with the requirements file asking for requests and PyGithub, the latter because writing back to GitHub is part of the pipeline rather than an afterthought.

Filtering, deduplication and the four protocols

The filtering stage is where a collected pile of configurations becomes a usable set. There is a geo filter covering Russia, the CIS and the EU, deduplication by MD5 hash, syntax validation, a priority given to fast servers, and detailed statistics on the result. The four supported protocols each have their own character, and the project describes them as VLESS with XTLS, described as the modern protocol, VMess as the classic V2Ray protocol, Trojan as the Trojan-GFW protocol, and Shadowsocks as a SOCKS5-based proxy. The published statistics in the overview give a sense of the shape of the collection, with 1,247 VLESS configurations of which 342 pass the regional filter, 892 VMess with 198 filtered, 534 Trojan with 87 filtered, and 312 Shadowsocks with 45, for 2,985 in total and 672 after the regional filter. The ratio between the two numbers is the interesting one: the geographic filter is doing most of the culling, which is why the filtered files are the ones worth pointing a client at.

The directory layout is the user interface

The project structure is worth reading because it maps directly onto how a user would consume the data. Under githubmirror/ there is clean/ holding the valid configurations with one text file per protocol, ru-sni/ holding only the regional servers with the same per-protocol split, new/ for newly collected configurations, and ru-sni-local/ for local regional ones. Alongside that, vpn-files/ holds the history of posts in an all_posts.txt and a per-timestamp file for the most recent ones, subscriptions/ holds the subscription formats, and data/ holds service data. The three Python files at the root are named for their jobs, with main.py as the orchestrator, mirror.py as the configuration collector and filter_ru_sni.py as the geographic filter, next to requirements.txt. The GitHub mirror directory name is the giveaway about the design. Rather than asking people to trust one endpoint that can go down, the project publishes the plain text files in a repository, so the raw lists can be fetched from anywhere.

Getting the configurations, three ways

The quick start offers a Cloudflare Worker subscription, direct download from GitHub, or a clone of the repository. The Cloudflare route is the one that is currently switched off, and the reasoning is worth noting because it is the kind of detail that gets glossed over. Cloudflare Workers are partly blocked in Russia, so the subscription through the workers.dev address is temporarily disabled and the links have been removed, specifically so that no dead subscription URLs and non-working configurations are left behind. Until the situation stabilises, the overview directs users to direct download from GitHub or to running the scripts locally. Direct download is two wget commands, one for all VLESS configurations and one for the Russian servers only.

git clone https://github.com/kort0881/vpn-vless-configs-russia.git
cd vpn-vless-configs-russia

cat githubmirror/clean/vless.txt | head -10

The clone route is also the one to take if you intend to run the pipeline yourself, since the requirements are modest, Python 3.8 or newer and Git.

Client setup, and the point about your own endpoint

The client instructions cover Hiddify for Android, iOS, Windows, macOS and Linux, V2RayN on Windows, V2RayNG on Android, and Clash Meta or Mihomo. In each case the import flow is the same, add a profile from a subscription URL, update, then pick a server, and where the client offers a latency test you use it to find a fast one. The important detail is that the instructions tell you to supply your own working subscription URL or a local endpoint of your own rather than pointing the client at a shared one, which follows directly from the fact that the project's own Cloudflare subscription has been withdrawn. The Clash Meta configuration makes that concrete, with a proxy provider of type http pointing at a URL you control, a refresh interval of 3600 seconds, a health check every 600 seconds, and the check URL set to Google's generate_204 endpoint.

proxy-providers:
  vless-sub:
    type: http
    url: "https://<your-own-endpoint>/sub?filter=vless"
    interval: 3600
    path: ./providers/vless.yaml
    health-check:
      enable: true
      interval: 600
      url: http://www.gstatic.com/generate_204

Note also the Hiddify instruction that NookLink-style services needing custom JavaScript APIs cannot run in a plain browser, which is why some clients open those in the app itself.

What the project will not promise you

The honest limits are all over the documentation, and they are worth reading before you build anything on top of it. The configurations are not guaranteed to work, which is not a disclaimer formality when the upstream servers are free proxies scraped from public channels and change without notice. The data comes from public sources, which means the pipeline inherits the quality of whatever is posted there. The Cloudflare subscription is offline because the platform is partly blocked in the region the project targets, which is a reminder that the delivery mechanism is as fragile as the configs. The project is licensed GPL-3.0, the last push was on 2026-10-20, and the repository publishes no GitHub releases, so there is no version stream to pin. The claim of 99.9 percent uptime on the badge refers to the collection pipeline, not to the proxies it lists, and the two should not be confused.

Editorial conclusion

vpn-vless-configs-russia fits a user in Russia or the CIS region who wants a maintained list of proxy configurations rather than a hand-curated subscription, since the collection is refreshed on a fixed fifteen minute cycle and split by protocol and by geography. It does not fit anyone who needs a guarantee of uptime, because the project states plainly that it does not guarantee the configurations work, and the Cloudflare subscription route is currently switched off because those workers are partly blocked in the region. It also does not fit an organisation that needs an audited, contractual path, since the upstream servers are third party and the data is collected from public sources. Before you rely on it, test a configuration on a network you care about, and if you are building a client configuration, use your own subscription endpoint rather than a shared one, because the Clash Meta example in the project points at a placeholder URL for exactly that reason.

Frequently asked questions

Official sources

1. Issues
2. kort0881/vpn-vless-configs-russia on GitHub
3. License: GPL-3.0
4. Project website
5. README