Xray-core: the Project X engine behind REALITY, and the ecosystem its README points to

One engine from the XTLS protocol family, with REALITY as a separate repository

Project X describes itself as originating from the XTLS protocol and providing a set of network tools, with Xray-core and REALITY named as the two headline projects. Xray-core is the engine; REALITY lives in its own repository at XTLS/REALITY and is pulled into the core as a Go dependency. The repository description adds that Xray is "also the best v2ray-core", which is the project's own claim about its lineage rather than a measured comparison.

The practical consequence is that this repository is not where you learn to run Xray. The README page is mostly a directory: links to the official documentation site at xtls.github.io, to Telegram groups (Project X, the Project X Channel, Project VLESS in Russian and Project XHTTP in Persian), to example configurations and to dozens of installers and clients. Treat the GitHub page as an index, and plan to read xtls.github.io and the example repositories before writing a configuration.

Only two install paths carry the Official label

The installation list mixes official and community options, and the README marks the difference explicitly. On Linux, XTLS/Xray-install is marked Official; tempest, from team-cloudchaser, is an alternative that supports systemd and OpenRC and is Linux-only. For containers, ghcr.io/xtls/xray-core is the Official image, while teddysun/xray on Docker Hub and wulabing/xray_docker are community builds. Magisk users get two community modules, Magic_V2Ray and Xray_For_Magisk. On macOS and Linux with Homebrew, the listed command is:

brew install xray

The distinction matters because an installer runs with the privileges needed to place a network daemon on your system, and a container image decides which binary you actually execute. If you want the shortest chain of trust back to the XTLS organisation, stay with the Xray-install script or the ghcr.io image and treat every unmarked entry as someone else's packaging that you need to audit separately.

Web panels and one-click scripts are someone else's code on your server

A large share of the install list is management software rather than Xray itself. The web panels named are Remnawave, 3X-UI, PasarGuard, Xray-UI, X-Panel, Marzban, Hiddify, TX-UI and CELERITY. The one-click scripts include Xray-REALITY, xray-reality, reality-ezpz, Xray_bash_onekey, XTool, VPainLess, v2ray-agent, Xray_onekey and ProxySU. None of these carry the Official label.

For an operator, that changes what you are trusting. A panel holds your server configuration and user credentials and decides when the underlying core is upgraded. A one-click script makes choices about protocol, ports and system services on your behalf. If one of those projects stops updating, your server stays on whatever Xray-core build it last pulled, regardless of what XTLS releases. Choosing a panel is therefore a decision about a second maintainer, not a convenience layer you can ignore, and its release history deserves the same scrutiny as Xray-core's.

Date-stamped releases arrive every few weeks

Xray-core versions are named after their release date. The three most recent are v26.9.30 on 2026-09-30, v26.10.21 on 2026-10-21 and v26.10.31 on 2026-10-31, and the main branch was last pushed on 2026-11-02. The version string tells you when a build was cut, which makes it easy to see how old the core inside a client or panel is.

That cadence has a cost for anyone depending on bundled cores. Graphical clients and panels each ship their own copy of Xray-core, so the core you run on a phone or router is whatever that client last packaged, not the latest tag here. Features discussed in the project's linked threads, such as VLESS Post-Quantum Encryption in pull request 5067 or the XHTTP: Beyond REALITY discussion 4113, only reach you when your client updates its bundled core. Check the date in the version string before assuming a feature is available.

go 1.27 and pseudo-version pins on REALITY, uTLS and QUIC

Building from source means meeting the go.mod requirements. The module path is github.com/xtls/xray-core and the file declares go 1.27, so an older Go toolchain is not enough. Several of the most security-relevant dependencies are pinned to pseudo-versions taken straight from commits rather than tagged releases: github.com/xtls/reality at v0.0.0-20261014101318-83f621788ca8, github.com/refraction-networking/utls at v1.8.3-0.20260301010127-aa6edf4b11af, and github.com/apernet/quic-go at v0.61.1-0.20260806010916-184d081eef3e.

Other dependencies show the breadth of the core: golang.zx2c4.com/wireguard and wintun, google.golang.org/grpc v1.85.0, github.com/miekg/dns v1.1.73, github.com/gorilla/websocket v1.5.3, github.com/pion/stun/v3, and two Lua packages, github.com/yuin/gopher-lua and layeh.com/gopher-luar. For packagers, the pseudo-version pins mean you cannot swap in a distribution's tagged uTLS or REALITY build and expect identical behavior; build against the exact commits go.mod names.

The source tree splits proxy/ from transport/

The top level of the repository is a Go project with no installer or packaging scripts of its own: app/, common/, core/, features/, infra/, main/, proxy/, testing/ and transport/, plus go.mod, go.sum, LICENSE, SECURITY.md and CODE_OF_CONDUCT.md. The separation between proxy/ and transport/ in the directory names mirrors how Xray configurations are discussed in its examples, where a protocol such as VLESS is combined with a transport and a security layer, as in VLESS-TCP-XTLS-Vision or VLESS-XTLS-uTLS-REALITY.

For contributors and security reviewers, SECURITY.md at the root is the place to start before reporting an issue. The license is the Mozilla Public License 2.0, which applies file by file, so modified Xray-core source files you distribute stay under MPL-2.0 even when you link them into a larger program under a different license.

Configurations come from example repositories, not from the core

Xray-core does not hand you a working setup. The usage pointers lead to three named examples: VLESS-XTLS-uTLS-REALITY in the REALITY README, and VLESS-TCP-XTLS-Vision and All-in-One-fallbacks-Nginx in XTLS/Xray-examples. Beyond the official example repository, two community collections are linked, chika0801/Xray-examples and lxhao61/integrated-examples, along with English tutorials on REALITY, an Iran-focused REALITY guide, a "steal oneself" REALITY setup and Xray with a WireGuard inbound.

The consequence is that correctness of your deployment depends on which example you copied and how current it is. Community tutorials are dated by their authors, not by Xray-core releases, so an older guide can reference options that newer cores have changed. Start from XTLS/Xray-examples when you can, compare it with the documentation at xtls.github.io, and treat third-party tutorials as context rather than as a configuration to paste.

Every client bundles its own core on its own schedule

Client choice is per platform. OpenWrt routers have PassWall, PassWall 2, ShadowSocksR Plus+ and luci-app-xray; Asuswrt-Merlin has XRAYUI and fancyss. Windows options include v2rayN, Furious, Invisible Man - Xray, AnyPortal, GenyConnect, OneXray and XrayUI-dev. Android has v2rayNG, X-flutter from the XTLS organisation itself, SaeedDev94/Xray, SimpleXray, XrayFA, AnyPortal, OneXray and AsteriskNG. Apple devices have Happ, including a tvOS build, Streisand, OneXray and INCY, while macOS also has V2rayU, V2RayXS, Furious, GoXRay and AnyPortal.

Each entry is a name and a link, not a compatibility statement. To know whether a client can use a protocol your server offers, check which Xray-core release that client ships in its own release notes. Funding for the core itself runs through the sponsor issue 3668, cryptocurrency addresses and Project X NFTs, separate from any client's funding.

Editorial conclusion

Xray-core is the right starting point if you are comfortable assembling a deployment from parts: the core from this repository, an install path from XTLS/Xray-install or ghcr.io/xtls/xray-core, a configuration adapted from XTLS/Xray-examples, and a client chosen per platform. It is a poor fit for anyone who expects one vendor to own the whole stack, since nearly every panel, one-click script and GUI client on its install list is a separate third-party project. Before deploying, check which entries are marked official, which Xray-core release your client or panel bundles, and whether your build toolchain meets the go 1.27 directive.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes