The Xray Fork Drama: V2Ray → Xray-core, 2021–2023

Looking for the deployment guide? See Irregularpedia: VLESS / Xray Deployment Guide. This post is fork-history research — useful context, not operational guidance.

Part 2 of the VLESS Investigation series. See Part 1 for the maintainer-identity question.

The short version

In September 2020, the original V2Ray maintainer (Project V) had stepped back and the project was moving under a community group (V2Fly). A faction led by RPRX forked the code into a new project: XTLS/Xray-core. The stated reason was protocol-velocity disagreements. The unstated reasons probably included attribution, governance, and the question of who got to set the project's direction.

This post collects what's publicly knowable from commit history, archived issues, and Telegram channel logs, plus the parts that remain contested.

Timeline (verified, with a few hedged entries)

Date	Event
2017	V2Ray created. Victoria Raymond is the most visible early maintainer.
2018	V2Ray reaches widespread adoption in the China-circumvention community.
2019–2020	XTLS (the original transport-layer protocol) is developed inside V2Ray. RPRX is the named author.
2019-06	Chinese patent CN110595506A filed by Beijing Institute of Technology researchers — describes a method for detecting V2Ray traffic. The Chinese state has formally documented an interest in fingerprinting this protocol family.
2019	Victoria Raymond's public commit activity tails off and never recovers under that name. The relationship between this and the patent is community speculation — see Part 1: maintainer analysis.
Late 2019 – mid 2020	Tension visible in V2Ray issues over the direction of XTLS specifically. Threads get locked. Some get deleted by repo admins; archived screenshots circulated on Telegram.
2020-09	RPRX announces the Xray-core fork under the XTLS GitHub org. Initial commit imports the V2Ray codebase wholesale, with attribution.
2021	Repo continuity for the upstream completes its move to V2Fly. V2Fly focuses on stability and conservative protocol changes. Xray-core focuses on protocol velocity.
2021-05	VLESS protocol introduced in Xray-core. Stateless, UUID-keyed authentication. Original protocol design credited to DuckSoft.
2022	Bulk of the community migrates client tooling to support both. Active client GUIs (Nekoray, v2rayN) ship dual-stack support.
2025-03-17	Nekoray archived. MatsuriDayo marks MatsuriDayo/nekoray read-only with the README note "No longer maintained, find an alternative yourself." Community migrates primarily to Hiddify (Flutter / Sing-box) and v2rayN. Older guides recommending Nekoray are now stale; the wiki deployment guide reflects the post-Nekoray client landscape.
2022 / early 2023	REALITY protocol introduced. Exact public-introduction date varies by source; first widely-adopted release was around the start of 2023. Designed against the specific active-probing techniques the GFW had begun deploying.
2022-11 → 2023-01	RPRX hiatus (see Part 1).
2023-01	mmmray emerges as an active maintainer across the same project ecosystem Victoria Raymond worked in. Identity-overlap debate begins.
2023-05	Sing-box launches as a third independent implementation. Different team (SagerNet), different design philosophy (Go, modular, no XTLS-as-protocol dependency), GPL-3.0 license. SagerNet's framing of the launch was, among other things, about governance and not wanting to depend on the XTLS team's release cadence.

The license argument

The most public part of the dispute was about licensing.

V2Ray-core (v2fly/v2ray-core/LICENSE): MIT. Permissive, no copyleft, no attribution-on-redistribution requirement.

Xray-core (XTLS/Xray-core/LICENSE): MPL-2.0 (Mozilla Public License 2.0). Imported V2Ray's MIT-licensed code at the fork, then relicensed the combined codebase under MPL-2.0 — which MIT explicitly permits as long as the original MIT copyright header is preserved.

The argument that flared: some early forum and Telegram discussions claimed Xray was "stealing" V2Ray's work. This was legally incoherent — MIT explicitly permits forking and re-licensing-under-compatible-terms (which is exactly what happened: MIT → MPL-2.0 is a legal one-way move). The attribution version of the complaint had more teeth: did Xray's documentation and changelogs sufficiently credit the V2Ray team, beyond preserving the file-level copyright headers?

By 2022, Xray-core's README and CONTRIBUTING files explicitly credit the V2Ray upstream. The license-incompatibility question has largely faded from active argument; the relicensing-without-loud-announcement debate persists in some Telegram channels but isn't load-bearing for users.

Where the AGPL question came in. Some forks downstream of Xray-core (panels, subscription services, client GUIs) attempted to relicense under AGPL-3.0 — either to discourage commercial repackaging or as a political signal. This created a second-order argument about whether such relicensing was compatible with the MPL-2.0 upstream. The answer is: yes for new code, no for code derived from MPL-2.0 files (MPL is file-level copyleft — modifications to those files have to stay MPL). The practical impact in 2026 is small but the legal posture is messier than the upstream MIT → MPL move was.

The attribution fight

Beyond licensing, there were three recurring threads of complaint:

1. Who deserves credit for XTLS itself?

RPRX is unambiguously the original implementer of XTLS — this is verifiable in V2Ray's commit history pre-fork. But some members of the V2Fly community argued that XTLS as a protocol developed against feedback from the broader community, and that the fork's narrative ("RPRX built XTLS, V2Ray held it back") flattened that contribution. This is largely a credit-allocation argument, not a code argument.

2. Were V2Ray issues deleted?

Multiple archived screenshots show issues on the original V2Ray repo being closed and removed, including discussions about XTLS direction. Whether this was admin discretion, abuse, or coordinated suppression depends entirely on who you ask. The screenshots are real; the interpretation of them remains contested.

3. Did the fork "kill" V2Ray?

In one sense, no — V2Fly is still active, V2Ray-core still ships releases, and the project has a stable maintainer set. In another sense, kind of — the majority of new feature work since 2021 has happened in Xray-core, and most users running TLS-fronted proxies today are running Xray, not V2Ray. V2Fly has consolidated into the "conservative, stable, broadly-compatible" implementation; Xray-core is the protocol-experimentation venue.

Documented supply-chain incidents

The fork didn't make the project any less of a target. Over the years the XTLS / Xray-core ecosystem has been the subject of at least the following publicly-documented supply-chain events:

2021 — Fake xray binaries containing malware distributed through Telegram channels that masqueraded as official-release channels. The upstream response was to pin verified hashes in the README, which is the Verify-Downloads section that exists today. Operational lesson: "downloaded it from a Telegram channel that looked official" is not a verification step.
2023 — Malicious xray-core npm package (typosquat), published under a name a careless npm install would resolve to. Removed after report. Lived long enough to be installed by an unknown number of users. Operational lesson: there is no first-party npm package for Xray-core; if a package manager resolves to one, treat it as suspect.
2023 — Reports (less well-documented) of GitHub account-hijack attempts against core-maintainer accounts. The project response was a tightening of commit-signing requirements.

These are why the wiki deployment guide puts "verify the binary" on the hardening checklist rather than treating it as optional hygiene. The pattern of incidents is consistent with what you'd expect of a high-value circumvention project in an adversarial environment — not unique to Xray, but real.

What's left of the original team

As of mid-2026:

V2Fly: 5–10 active contributors, monthly-ish releases, focused on stability. Active issues, real maintenance.
XTLS / Xray-core: dominated by RPRX with a small set of regular contributors. Aggressive protocol changes, less stable release cadence. (See Part 1 for the maintainer-identity question.)
SagerNet / Sing-box: separate team, drop-in replacement for both. Active and well-maintained. This is the "what to switch to if either of the above implodes" plan.

The original "Project V" identity hasn't been heard from publicly since 2021.

What this means operationally

You can run Xray-core today with reasonable confidence. The project is active, the protocol is sound, and the community is large enough that severe regressions get caught quickly.
The fork history affects supply-chain reasoning. A project that emerged from a contested fork, with a non-transparent maintainer set, deserves a different level of build-from-source hygiene than (say) WireGuard.
Sing-box is your insurance policy. Independent team, independent codebase, independent governance. If Xray-core has a serious supply-chain event, Sing-box is the off-ramp.
V2Fly is the conservative option. Slower-moving, fewer features, more obvious maintainership. If you don't need REALITY specifically, V2Fly's V2Ray-core is the boring-but-stable choice.

What we don't know

The actual personal reasons behind the fork. The technical disagreement is documented; the human one isn't, and isn't going to be.
Whether the V2Fly maintainers were happy about the fork at the time. Their public statements have always been measured. Their private feelings, no one knows.
What "Project V" the original identity is doing today. Disappeared from the public record.

External references

Chinese patent CN110595506A — June 2019 V2Ray-detection patent. The 2019-onwards backdrop context.
objshadow — "How REALITY Works" — 2023 independent technical review of the REALITY protocol. Found no backdoors; noted the lack of a formal protocol specification.
chengxiaobai — "The V2Ray / Trojan / Xray trouble-maker" — independent audit-flavoured writeup covering the same trust territory.
V2Fly Discussion #2199 — the mmmray ↔ Victoria Raymond identity-question thread.