Serverless-for-Iran, Xray subscription configurations and their limits

A configuration repository, not an application

The repository description is in Persian and translates to direct, intermediary-free access to the open internet, and the README is written in Persian too. What the repository contains is not an application but a set of configuration files and the script that publishes them. The description line of the project is a JSON subscription file, and the usage notes tell the reader to enter the subscription address into the v2rayN, v2rayNG, PattN or PattNG application. The target audience is therefore an individual with a device and a client, not a platform team, and the way to evaluate the project is to read the configuration notes rather than the code. The README also links a separate repository, patterniha/MITM-DomainFronting, for a variant of the approach that adds man in the middle and domain fronting, which tells you that the configurations here are one technique among a set rather than a general purpose network.

The subscription URL is the interface

There is one thing a user needs, and it is the subscription address. The documentation gives it as a raw GitHub URL pointing at a JSON file in the Subscription directory of the main branch, with a fragment identifier naming the specific configuration profile.

https://raw.githubusercontent.com/patterniha/Serverless-for-Iran/refs/heads/main/Subscription/Serverless-for-Iran.json#Patterniha-S

Pasting that into a client means the client fetches the configuration and updates it on its own schedule, which is the whole point of the subscription format. It also means the configuration is not pinned to a commit, since the URL points at the main branch, so a change to the published file reaches every client that refreshes. The repository is not archived, the last push was on 2026-10-04, and there are no GitHub releases, so the subscription file on the main branch is the only artefact a user actually consumes.

The client requirements, read as a checklist

The usage notes are numbered and read like a preflight checklist, and every item is a condition under which the configuration will not work. The first is the core: the Serverless configuration needs Xray-core at least version 26.6.27, which means v2rayNG and PattNG at least version 2.2.6. The third is the port, since in the v2rayNG and PattNG settings you must make sure the default port 10808 has not been changed. The fourth is the geo data files, and the documentation asks you to make sure they are up to date, which in v2rayNG and PattNG is the Asset files section and in v2rayN and PattN it is the Help and Check Update section. The fifth is IPv6, which is recommended for a better experience, and on mobile you also need IPv6 enabled in the phone's access point settings. The sixth is a detail that will save an afternoon of confusion, since on Android it is better to turn off Private DNS in the Android settings and Use secure DNS in the Chrome settings, to avoid interference with the DNS and sniffing behaviour of the configuration.

What the configuration cannot reach

The second usage note is the most important paragraph in the README and it is a limitation, not a feature. Services and sites whose IP addresses are broadly blocked from the Iranian side are not directly reachable with this method, and because services outside the country see the Iranian IP address, the services and sites that have sanctioned Iran are not directly reachable either. The second half of that sentence is the one that surprises people, since a proxy normally hides the origin, but the configuration here is a direct path rather than a relayed one, so the exit address is the Iranian one and the sanction list applies to it. The seventh note closes the loop on testing. Do not test with a configuration test, because the result of a connectivity test has nothing to do with whether this kind of configuration works or does not. Both points mean the project is best read as a convenience for a specific use case rather than a general solution, and an evaluator who expects it to behave like a commercial VPN product will be disappointed.

Two fragments and a generator script

The top level listing shows four things beyond the documentation. Generate-subscription.py is the script that produces the published file, and the two JSONC files, Serverless-fragA.jsonc and Serverless-fragB.jsonc, are the configuration fragments, with the .jsonc extension indicating that they are JSON with comments, which is a practical choice for a file that a human edits. The Subscription/ directory holds the published output that clients fetch. The arrangement is a small, legible build system: fragments in, one generated artefact out, and a reader can diff the fragments to see what a configuration change actually was. The licences are worth a note, since the repository carries a LICENSE file and the project is under the GNU Affero General Public License version 3, which for a set of configuration files is a stricter grant than most people expect, and an organisation that intends to redistribute or rebrand the configurations has to look at that rather than assume the MIT terms of neighbouring projects.

The project is funded by its users

There is no company behind this and no release process, so the support model is the interesting part. The README asks for support in Persian if the author's work has given you access to the open internet, and then lists three donation addresses: a USDT address on BEP20, a USDT address on TRC20, and a TON address, with the handle at the end. That is a common pattern for projects like this one, where the person maintaining the configuration absorbs the hosting and the updates without a commercial operator. The consequence for a user is straightforward. There is no SLA, no changelog and no semantic versioning, the configuration changes when the author changes it, and the practical way to keep up is to make sure your client's geo files and the core are current and to re-import the subscription after a change. For an evaluator, the honest summary is that this is a well documented, single maintainer project whose value is its configuration knowledge rather than its code.

Editorial conclusion

Serverless-for-Iran fits an individual in Iran who already runs an Xray or v2ray client and wants a working configuration without assembling one by hand, and it fits a reader who wants to understand what a publishable Xray subscription looks like as a repository. It does not fit an organisation that needs a guaranteed, monitored path to specific blocked services, because the documentation states that services and sites broadly blocked at the IP level from Iran are not directly reachable this way, and neither are services that sanction Iranian IP addresses. Verify three things before you rely on it: that your client meets the stated minimums, since the configuration needs Xray-core 26.6.27 or newer and the matching v2rayNG release, that the default port 10808 is unchanged on your device, and that you do not test reachability with a configuration test, since the documentation says the result of such a test tells you nothing about whether this kind of configuration works.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. patterniha/Serverless-for-Iran on GitHub
4. README