# free-vpn-anti-rkn: a trimmed subscription feed for VPN clients > This repository republishes public VPN server lists as short subscription files, capped at 300 nodes each, so that client apps stop stalling on thousand-entry feeds. It solves a client performance problem, not a trust problem, and the nodes themselves remain unverified third-party infrastructure. **Hidashimora/free-vpn-anti-rkn** — Бесплатные VPN-конфиги без лагов 🚀 - Repository: https://github.com/Hidashimora/free-vpn-anti-rkn - Website: https://hidashimora.github.io/free-vpn-anti-rkn/ - Stars: 1,051 · Forks: 121 - Language: HTML - License: not declared - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/hidashimora-free-vpn-anti-rkn ## Why a thousand node list stalls the app before it stalls the network The problem this repository addresses is not reachability, it is client performance. Public lists of VPN server configurations often carry more than a thousand entries, and the project notes that an app downloading and parsing that volume becomes slow to draw, slow to list, and in the worst case exits. The user experience people describe is a familiar one: the app opens, the server list spins for a while, and by the time it appears the connection is already stale. The audience is therefore narrow and specific. It is someone who has already found working configurations elsewhere, already has a client that supports vless, trojan, vmess, shadowsocks or hysteria2 links, and wants a feed that loads quickly enough to be usable on a phone. It is not for someone who needs a service agreement, a static address, or a provider who answers when a node stops working. The fix is arithmetic rather than clever. Where the upstream list is short, everything is kept. Where it is long, the file takes every fourth entry and stops at 300 lines. That reduces the parse load for the client, and the project puts it in more direct terms: fewer configs mean less work for the application and steadier behaviour. What this approach does not do is improve the quality of the sample. Every fourth line is a positional slice, not a latency ranking, so a trimmed file can contain plenty of dead servers and skip perfectly good ones. The benefit is a smaller download and a lighter client, nothing more. ## The sampling rule: every fourth entry, never more than 300 The rule is applied per source list, which matters because the files are named by source index. For each of the 26 lists taken from AvenCores/goida-vpn-configs and each of the 8 lists taken from igareck/vpn-configs-for-russia, the project prepares its own shortened file. If the source list holds fewer than 300 configurations, the shortened file contains all of them. Otherwise it contains roughly a quarter of the entries, taken as every fourth line, capped at 300. The result is a set of numbered pairs. For the 26 AvenCores indexed sources the shortened file and the complete file sit side by side, for example 1.1.txt next to 1.2.txt, and the second one holds every server from that source. A handful of numbered sources have only a shortened variant, which is what the directory layout shows for the entries 27, 29, 30, 31 and 34. Three of the indexed sources, listed in the project notes as BLACK_VLESS_RUS, WHITE-CIDR-RU-all and WHITE-CIDR-RU-checked, also appear with both a short and a full file. Only certain protocol lines are considered when the files are produced. The counted set is vless, trojan, vmess, ss and hy2, and anything outside that set is left out. A counts.json file sits alongside the configs and records how many servers each file holds, together with a totalUnique value that excludes duplicates. That file is the only sanity check the project offers a reader, and it is worth reading before you import anything, because a shortened file that has recently been truncated upstream can look plausible while containing far less than the 300 lines its name suggests. ## The configs directory is the actual product, not the page The repository is small and mostly text. The top level holds a README file, an index.html page that links to the configs, a workflows folder, the configs folder itself and an icon file. The primary language tag on the repository is HTML, which matches the fact that the browsable artefact is a static page hosted on GitHub Pages at hidashimora.github.io/free-vpn-anti-rkn. For anything other than browsing, the useful address is the raw path into the configs directory: ```bash https://raw.githubusercontent.com/Hidashimora/free-vpn-anti-rkn/main/configs/ ``` Each numbered file is a plain text subscription that a client can fetch directly, and the project lists the individual raw links for every numbered entry. A single file, the shortened variant of the first source, looks like this: ```bash https://raw.githubusercontent.com/Hidashimora/free-vpn-anti-rkn/main/configs/1.1.txt ``` The index.html page is a convenience for humans who want to click through the table of links rather than assemble a raw URL by hand. If you are wiring the feed into a client, use the raw URL and skip the page. The full lists are worth understanding before you ignore them. The complete variants are marked as not recommended, on the grounds that they can make the device slow, which is the same reason the shortened files exist in the first place. The shortened file is the default choice, and the full file is the fallback for when a trimmed source happens to have dropped the one server that worked for you. ## A workflow that runs every minute instead of releases There are no GitHub releases in this repository, and there is no version history a user would consume in the usual way. Freshness is handled entirely by automation: a workflow file at .github/workflows/update-vpn-config.yml is scheduled to run every minute and check the upstream sources, so a change in the source repositories appears in the trimmed files shortly afterwards. That design has an obvious upside. A subscription feed that refreshes once a minute can track a field where server addresses churn, and the client can be told to pull often without the operator doing anything. It also explains why the file names are stable: a client can keep pointing at the same URL forever and still receive new content. The cost of the same design is that there is no pinned version. When a feed changes, it changes for everyone at once, and the only way to know what changed is to look at counts.json, which reports per-file counts rather than a diff. Anyone who needs reproducibility has to copy a file locally and manage it themselves. Maintenance is active in the sense that commits continue. The last push to the repository was on 2026-10-19, which is recent, and the repository is not archived. The licence is not declared in the repository metadata, and the project instead carries a section asking for donations to three addresses, one on BNB Smart Chain, one on Tron and one on Ethereum. That is a donation request rather than a licence grant, so anyone planning to reuse the code or redistribute the files has no permission statement to point at. ## Importing a subscription: the four steps the quick start gives The quick start is short, and it is worth following literally, because the order matters. First, open the main page or copy the link you need from the table of subscriptions. Second, in your VPN client add a subscription by URL, using the Subscription or Import by link menu entry. Third, refresh the list, and if you want to, run the latency check. Fourth, pick a server and connect. The first step is where the choice of file matters. You are choosing between a shortened file capped at 300 entries and a complete file for the same source, and the complete one is the variant that may slow your device. Reach for the full list only when the short one has thrown away the server you actually needed. The second step is where the format of the URL matters. The client pulls the file over plain HTTPS from the raw GitHub path and parses the lines as server entries, so the file has to be the one your client expects rather than a page of links. The index.html page and the raw files serve different purposes for that reason. The third step is the one most people skip. The latency check is not a quality filter applied by this project, it is a client side measurement of the servers it just downloaded, and it is the only mechanism in the whole pipeline that tells you which of the trimmed nodes are worth trying. Given that the trimming is positional, running that check is how you recover the quality the trimming cannot give you. ## Where a free config feed is the wrong tool The largest limitation is not technical. These are server configurations collected from public lists, published by people who are not the operators of the servers, and the project does not claim any of the nodes are audited, owned, or stable. A VPN connection of this kind terminates somewhere you did not choose and cannot inspect, and that fact is unchanged no matter how neatly the list is trimmed. Anyone treating such a feed as a privacy tool has the wrong model of it. A second limitation is that a positional sample is a blunt instrument. Taking every fourth line assumes the source file is ordered in a way that makes a quarter of it representative, and nothing the project publishes supports that assumption. The practical symptom is a short file that looks full while missing the region or the protocol you depend on. Third, the protocol filter narrows the set to vless, trojan, vmess, ss and hy2. If your client and your local network only work with a protocol outside that list, this repository has nothing for you, and the upstream sources are the only place to look. Fourth, there is a real operational hazard in how the files are published. A subscription URL that is imported into a client is a URL that the client fetches repeatedly, and if the client supports remote configuration of the subscription itself, a host that serves the file can also change what the client does with it. The topic tags on the repository point at the client families this feed is meant for, including v2rayNG, Hiddify and NekoRay, so read the import settings of the client you use before you point it at a raw URL. ## How this differs from the upstream lists and from a paid provider The obvious alternative is to skip this project and subscribe to the two upstream lists directly, AvenCores/goida-vpn-configs and igareck/vpn-configs-for-russia. The difference in approach is exactly the trimming described above. The upstream lists give you everything, in one file per source, which is what you want if you run a client that handles large feeds well, or if you want to run your own filtering on the raw data. This project gives you a smaller, already-sliced file per source, which is what you want if the problem is client load and you would rather not write the filter yourself. The trade is that you have given up the ability to choose which quarter you get. The other alternative is a paid VPN subscription. A paid provider operates its own infrastructure, gives you a consistent set of locations, and offers someone to contact when a node is down. This repository offers no such thing. There is no account, no payment, no support, and no obligation to keep a node running. What you get in exchange is the opposite property: a feed that is free to fetch, refreshed on a one minute schedule, and that contains servers the provider knows nothing about. The sensible use is the narrow one. Use a trimmed file from this repository to keep a client responsive, then pick a node with the client latency check and move on. If you need a stable path for daily work, the absence of any guarantee is a reason to look elsewhere, not a detail to accept. ## Conclusion Adopt this repository if you already use a client that imports subscriptions by URL and your main complaint is that a full upstream list makes the app slow or crash. Do not adopt it as a privacy solution, because the traffic still passes through servers this project does not own or audit. Before you rely on any of it, open counts.json to see how many nodes a given short file actually contains, and check that the trimmed file for your source is still being refreshed by the scheduled workflow. ## FAQ ### What does free-vpn-anti-rkn do differently from the source lists? For each source list it publishes a shortened file that keeps every entry when the source has fewer than 300 configs, and otherwise takes every fourth entry up to a limit of 300. The complete variants of the same lists are published too, and they are marked as not recommended because they can slow the device. ### How do I add a free-vpn-anti-rkn subscription to a VPN client? The quick start describes four steps: open the main page or copy a link from the subscription table, add a subscription by URL in the client using the Subscription or Import by link menu, refresh the list and optionally run a latency check, then select a server and connect. ### How often are the config files updated? The workflow file at .github/workflows/update-vpn-config.yml is scheduled to run every minute and check the upstream sources, so changes appear in the files shortly after the upstream repositories change. The repository has no GitHub releases, and the last push was on 2026-10-19. ## Sources - [Hidashimora/free-vpn-anti-rkn on GitHub](https://github.com/Hidashimora/free-vpn-anti-rkn) - [Issues](https://github.com/Hidashimora/free-vpn-anti-rkn/issues) - [Project website](https://hidashimora.github.io/free-vpn-anti-rkn/) - [README](https://github.com/Hidashimora/free-vpn-anti-rkn/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/hidashimora-free-vpn-anti-rkn