barry-far/V2ray-Config: A Continuously Refreshed Subscription Feed for V2Ray Clients

What a config aggregator actually solves

V2Ray clients do not ship with working endpoints. A user installs V2rayN on Windows or V2rayNG on Android and then has to supply a server address, port, UUID, transport and TLS settings before anything connects. The repository's answer is to collect those parameter strings from public sources, write them into text files, and publish the files as URLs a client can subscribe to. The README states the collection is refreshed every 15 minutes through a GitHub Actions workflow (main.yml), so a client that re-pulls the subscription sees new endpoints without the user editing anything.

The audience is narrow and specific. It is people in networks where direct access to a given service is blocked, who already know which client they run, and who accept that a public endpoint may disappear within hours. The topics list names Iran explicitly, and the README links Persian, Chinese, Russian and Turkish translations, which matches that audience rather than a general developer one. If you want a tunnel you control, this is the wrong shape of tool: nothing here provisions a server.

How the subscription files are assembled and served

The layout is flat and deliberately simple. All_Configs_Sub.txt is the combined list, All_Configs_base64_Sub.txt is the same content base64-encoded for clients that expect that format, and Sub1.txt through Sub16.txt are numbered slices. Splitted-By-Protocol/ holds one file per protocol: vmess.txt, vless.txt, trojan.txt, ss.txt and ssr.txt. A Base64/ folder and a Files/ folder sit alongside them.

The update path is a scheduled GitHub Actions job, which means the refresh cadence is bounded by GitHub's scheduler rather than by any server the project runs. The README tells users to subscribe rather than to copy a single entry, and that advice is consistent with how the files are structured: the numbered Sub files exist so a client can pull a smaller list, not so a user can freeze one. The Python in the repository is the glue that fetches, deduplicates and rewrites these text files; the README does not describe the fetching sources or any validation step between collection and publication.

Importing a subscription into V2rayN, V2rayNG or Hiddify

There is nothing to install from this repository. The README's usage section says to open configs.txt in the root directory, copy the link of the configuration you want, and import it into your client. The subscription URLs themselves are the thing you paste. The README also warns that if the main link does not work, the base64 variant is the fallback.

The combined subscription URL, as given in the README:

https://raw.githubusercontent.com/barry-far/V2ray-config/main/All_Configs_Sub.txt

If your client expects base64, the README gives this alternative:

https://raw.githubusercontent.com/barry-far/V2ray-config/main/All_Configs_base64_Sub.txt

On Windows the README recommends Hiddify or V2rayN. In Hiddify you open the program icon and choose "Add profile from clipboard"; in V2rayN you right-click the tray icon and choose "Import from clipboard". On Android the README recommends V2rayNG, HiddifyNG or NekoBox, and describes tapping the "+" icon and selecting "Import Config from Clipboard". On Apple devices it recommends Streisand, where you tap "+", choose "import from clipboard", then hold the subscription entry and pick "Latency" to test the configs before connecting. What you should see after import is a list of profiles; the README's advice is to test latency and connect to the first working one, which is the honest expectation to set, because the list is unordered and unverified.

Public endpoints you did not choose

The most important limitation is not a bug, it is the model. Every entry points at a server operated by someone else, published so that strangers will use it. The README offers no statement about who runs those servers, how long they stay up, or what they log. A subscription that updates every 15 minutes is a good fit for churn and a poor fit for trust: you are repeatedly accepting new endpoints from an automated pipeline.

Operationally, expect the list to contain dead entries at any moment. The README's own instruction to test latency and pick the first working config is an admission of that. There is also no rollback story. The README does not document versioned subscription snapshots, so if an update introduces entries your client cannot parse, the practical recovery is to import a different Sub file by hand. For a tunnel carrying logins, payment pages or work traffic, the appropriate choice is a paid or self-hosted endpoint with a named operator, and this repository should not be used at all.

Against a self-hosted V2Ray server

The obvious alternative is running your own V2Ray instance on a VPS and generating the config yourself. The difference is not quality of software, it is who holds the endpoint. A self-hosted server gives you a fixed address, credentials only you know, and a log you can read. It also costs money monthly, requires you to keep the server patched, and can be blocked by address, which is exactly the failure mode a rotating public list is designed to survive.

A second alternative is a commercial subscription provider, which typically sells a fixed set of servers with a support channel and an uptime claim. That trades the free, unstable, anonymous pool for a contract and a bill. The repository sits between the two: cheaper than a VPS, more volatile than a paid provider, and with no party accountable for any individual endpoint. Which of the three is correct depends on whether you need the tunnel to still exist tomorrow morning.

Licence, maintenance and what an upgrade costs

The repository is MIT licensed, and the LICENSE file sits at the top level. MIT covers the code and text files in the repository. It grants nothing with respect to the remote servers the configs reference, and it offers no warranty about whether those endpoints work or are safe to use. That distinction matters here more than in a typical library, because the artefact users actually depend on is a list of third-party addresses.

Maintenance is the part that needs checking rather than assuming. The last push to the default branch was on 2026-09-28, and the repository is not archived, so the update job was running as of that date. There are no retrieved releases, which is consistent with a project that ships through file updates rather than versioned tags. Upgrading is trivial by design: your client re-fetches the subscription URL, so there is no migration step and no changelog to read. The real cost is diagnostic. When a connection fails you cannot tell whether the client, the network or the endpoint is at fault, and the project provides no status page to narrow it down.

Editorial conclusion

Adopt it if you already run V2rayN, V2rayNG, Hiddify, NekoBox or Streisand and want a subscription URL that your client re-pulls instead of a list you paste by hand. Do not adopt it for a stable tunnel, for anything carrying credentials, or where a provider contract and support channel are required, because every endpoint is a third-party server you did not choose. Before pointing a client at Sub1.txt, open All_Configs_Sub.txt and confirm the entries parse, then check the Actions tab to see whether the main.yml update job is still running. The MIT licence covers the repository's own files only; it says nothing about the servers the configs point to, and the README does not document any vetting of them.

Frequently asked questions

Official sources

1. barry-far/V2ray-Config on GitHub
2. Issues
3. License: MIT
4. README