rjsxrd: an hourly refreshed collection of public proxy configs with verification built in

What the generator actually produces

rjsxrd is a collection of automatically updated public VPN configs. The formats it gathers cover V2Ray, VLESS, Trojan, VMess, Reality, Shadowsocks, ShadowsocksR, Hysteria, Hysteria2 and TUIC, and each config is delivered as a TXT subscription that can be imported into almost any modern client, with v2rayNG, NekoRay, Throne, v2rayN, V2Box, v2RayTun and Hiddify named as examples.

The refresh schedule has two channels. Configs update every hour from a VPS, which is the primary channel, and every two days through GitHub Actions as a fallback. The reasoning is availability rather than secrecy: if one channel is blocked, the other keeps the files fresh.

The output is not a single list. By default the generator creates only verified configs in the bypass directory, and the other sets, including default, bypass-unsecure, split-by-protocols, tg-proxy and the raw files, are turned on with feature flags named in the documentation as --enable-*. The files are published on GitHub and referenced as raw URLs, so a client subscribes by fetching a text file over HTTP.

The quick start is three steps: copy the link you need from the configs section, import it into your client, pick the server with the lowest ping and connect. The repository also carries a docs directory with the quick start, generated file reference, import guides for Android, iOS, Windows and macOS, custom server instructions, installation, architecture, security and FAQ pages, plus qr-codes for scanning a subscription on a phone.

The security filter is the part worth reading

The filtering rules are per protocol, and they are unusually detailed for a project of this kind. For VMess the checks cover insecure, allowInsecure, security=none and alterId greater than zero, plus TLS SNI validation. For VLESS the checks cover allowInsecure, insecure, security=none and encryption=none, plus Reality public key validation. For Trojan the checks cover allowInsecure and insecure with Reality public key and SNI validation.

The Shadowsocks rule is a cipher allowlist rather than a denylist: only ciphers that Xray understands, meaning the AEAD and 2022-blake3 families, reach the verified files. Weak ciphers such as RC4, DES, CFB, Salsa20 and Chacha20 non-IETF are rejected before verification, and unknown ciphers are discarded, with empty passwords rejected too.

ShadowsocksR is handled with the same cipher list, and the documentation explains the practical consequence: a node still configured with aes-256-cfb, the default for ssserver, is not loaded by Xray at all, so it will not appear in the verified files. Those entries are converted to Shadowsocks instead, and empty passwords are rejected.

Hysteria2 is verified with the hysteria outbound at version 2, where TLS is mandatory. A node with insecure=1 and no pinSHA256 is not verified at all, because Xray removed allowInsecure and the compatibility filter rejects such a config. Hysteria version 1 is refused before verification with an explicit reason, since Xray only supports version 2. TUIC is not supported by Xray-core, since there is no implementation and the parser returns None.

A shared set of general checks applies on top: verify=0, verify=false and insecure=1 are all refused. The point of this whole apparatus is that a public list of free proxies is a hostile input, and this project treats it that way.

Two tiers of verification and how they differ

The verification system is layered, and the first layer is where the speed comes from. Configs can be checked with a quick TCP ping through the --tcp-ping option, or tested through Xray-core with sorting by speed so the fastest nodes come first.

The second layer is the file layout. Raw files hold untested configs in raw subdirectories, and verified files hold the ones that passed testing, sorted by ping. Users who want the fastest connections take the verified set; users who want maximum coverage and do not mind a broken node take the raw set.

Two maintenance behaviours protect the source list over time. URLs with three or more consecutive failed downloads are automatically removed from URLS.txt, and configs in servers.txt with three or more consecutive verification failures are removed as well. The generator also keeps a URL health report that collects statistics per source URL, including config counts, verification results and dead URLs, which turns a silent decay of the list into something visible.

Parallel downloads are used to speed up fetching, and the project reports progress with a progress bar and a processing rate during both config verification and Telegram proxy collection, with an estimated time to completion computed from a sliding window and a timeout floor.

Configuration lives in environment variables

The generator is configured through environment variables, with a .env.example file in the repository root documenting them. The GitHub token is required for pushing configs, falls back to the MY_TOKEN variable for backward compatibility, and the target repository is given in owner/repo form:

GITHUB_TOKEN=
REPO_NAME=whoahaow/rjsxrd

Telegram notifications are optional and silently skipped when the bot token and chat id are absent:

TELEGRAM_BOT_TOKEN=
TELEGRAM_CHAT_ID=

Performance tuning is documented with defaults shown as comments. The concurrency setting caps simultaneous Xray processes on Linux and WSL, and the comment is candid about the cost, noting each process peaks around 50MB of RAM, that 300 means roughly 15GB at peak, and that the value should be lowered if you see out-of-memory kills. A separate setting caps the threads used for fetching URLs, and two more set the HTTP request timeout and the validation HTTP timeout in seconds.

The fetch security posture is worth reading closely. The documented default refuses TLS downgrades outright, so no request leaves the process without certificate validation and none goes out in the clear, and the comment notes that this costs fetch yield wherever the network interferes with TLS. A separate allowlist setting restricts which destinations a fetch may still reach, accepting an IP literal, a CIDR, a host or a host:port, and the default is to refuse every loopback, private and metadata destination.

Telegram proxies, chained routing and the SNI and CIDR sets

Beyond the VPN configs, the generator collects and verifies Telegram proxies, handling MTProto and SOCKS5 proxies and sorting them by ping, with those results published as their own set. There is also support for proxy chains through the --proxy-chain option, which allows multi-level routing.

The bypass sets deserve their own note, because they are the reason the project exists in its current form. The documentation describes them as special configs for bypassing SNI and CIDR allowlists, and the repository description frames the whole project as allowlist bypass, especially on mobile networks where the filtering rules apply to the domains you can reach rather than the connections you can open. There is a matching set of configs for bypassing SNI and CIDR lists that are explicitly unsafe, and the two are kept in separate directories so that a user chooses knowingly.

Files are split into large batches with a maximum of 300 configs per file for better performance, and separate files are produced by protocol as well as the all.txt and all-secure.txt aggregates. YAML configs are supported and converted into VPN URL format, and daily-updated repositories are handled by searching for configs by date.

Manual entries are supported through the source/config/servers.txt file, where your own servers are filtered and merged with the other sources, so a personal node can live alongside the public pool.

Where this project is the wrong choice

The security objection is the obvious one and it is not a small one. These are free third-party servers. The node operator can observe traffic metadata, and while the filtering removes configs that explicitly disable certificate validation, a node that passes the checks is still a machine run by a stranger. The project publishes an unsafe set alongside the secure one, which tells you the author considers the distinction meaningful and that the secure set is the safer of two imperfect options.

There is also a durability question. The list rotates hourly and prunes sources that fail, so any individual node is temporary by design. A configuration that works today may be gone tomorrow, and an app that depends on one endpoint will break when it does.

The purpose is also narrow. This is a censorship-circumvention and allowlist-bypass tool. It is not a general VPN with a company behind it, it has no account system, no billing and no support, and it deliberately optimises for the case where the network restricts which destinations you can reach.

Compared with running your own server, the difference in approach is that you accept the operator's terms rather than setting them. A self-hosted node gives you the keys, the logs and the location; a public config gives you none of those. Compared with a commercial VPN service, the difference is that you get a rotating pool of nodes instead of one stable one, and the verification machinery in this project is the substitute for the uptime guarantee a paid service would provide.

The repository is actively worked, with the last push on 2026-10-20, and it is MIT licensed with a SECURITY.md file and a dedicated security system documentation page. It is a project with an unusually detailed threat model for its category, and that is worth crediting even as you decide the trust question for yourself.

Editorial conclusion

rjsxrd fits a user on a network with allowlist-style filtering who wants a ready-made subscription file and does not want to run their own proxy server or maintain a client configuration. It does not fit anyone who needs confidentiality from the proxy operator, since the servers are public and the project itself flags the insecure set as a separate output, or anyone who needs a stable long-lived endpoint rather than a pool of rotating third-party nodes. Before importing a file, read SECURITY.md and the security system documentation, keep the verification flags on so the insecure variants stay in their own directory, and treat every node on the list as operated by a stranger rather than by you.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. whoahaow/rjsxrd on GitHub