What is Xray-core, and who develops it?

An app's description may say “powered by Xray-core”, while a different name appears on screen. You buy a subscription from another service, and the profile uses VLESS. These are not three names for the same product. They are different parts of the system.

Xray-core is a software engine that performs network tasks. It can run inside an app or on a server. To understand who develops it and what trusting it means, first separate the engine from the interface, protocol and connection provider.

What core means

Here, a core is the program that accepts connections, applies configuration and sends data onwards. Another application may provide the buttons, location list and notifications you interact with.

Browsers offer a useful comparison: you choose an app with a particular interface, while an embedded engine processes pages. Knowing the engine's name explains part of the software, but not everything its developer does.

Xray-core can run on the user's side and on the server. Those instances do not have identical jobs: one may relay a connection to an intermediary, while the other accepts it and contacts the destination. They need compatible settings to work together.

The engine itself does not include paid access to a network of servers. It is a software tool that others use to build applications and services.

Xray-core, VLESS and a VPN service

It helps to divide a familiar connection into roles.

Using Xray-core does not identify the person operating a particular server. Likewise, an app supporting VLESS does not necessarily use Xray-core: other software can implement the protocol.

This separation also helps when something fails. An account sign-in error, an incorrect profile and a network-engine problem need different responses. Reporting the symptom is more helpful than assuming every failure comes from the core.

Where the project came from

Xray-core originated from v2ray-core. Developers created a separate branch and continued developing it independently. In open-source software, this is called a fork: a way of taking an existing codebase forward with different priorities.

The official Project X chronicle records the project's start on 23 November 2020 and the first Xray version on 25 November. Those dates appear in the project's history.

Shared origins do not mean complete interchangeability today. The developers explicitly explain that Xray-core has evolved independently and should not be treated as a fully compatible replacement for v2ray-core. Instructions for one engine therefore do not automatically apply to the other. The official Project X site makes this distinction.

For an everyday user, the history mainly explains familiar-looking terms and settings. Similar names are not a reason to substitute an arbitrary app for the compatible client recommended by your service.

Who develops Xray-core?

Xray-core is developed within Project X. Its public repository belongs to the XTLS GitHub organisation, where you can find source code, discussions, changes and releases. It uses the open-source Mozilla Public License 2.0, as stated in the official repository.

One prominent public developer is RPRX, an account that publishes Xray-core releases and participates in developing its networking mechanisms. The release history provides direct evidence of that activity.

The work is not limited to one person. Other community participants contribute code, fixes, tests and documentation. Public accounts show contribution histories; they are not grounds for inventing real names, employers or a hidden organisation behind pseudonyms.

If you purchase a subscription from a service, that service remains your supplier. Xray-core's developers do not automatically become a party to your purchase or responsible for a server simply because it runs their software.

That distinction is useful when seeking help. Questions about payment, available locations or a particular account belong with the operator. A reproducible software defect may eventually belong with the relevant app or core project, usually after the provider has helped identify it.

What the engine does with traffic

An important Xray capability is routing: choosing the next path according to configured rules. Different destinations can receive different treatment if the app developer or administrator sets that up. The routing documentation describes the available conditions.

Another part is DNS, which obtains addresses for domain names. Built-in features allow this process to be configured. Their presence alone does not guarantee that a particular app avoids leaks: the way it connects DNS handling, system traffic and routing matters. The DNS guide describes the engine's capabilities.

Imagine a profile that sends some requests through the server and others directly. Different websites may then see different exit addresses. That is not necessarily an engine fault. First establish what the configuration is meant to do.

You do not need to read every rule yourself. The useful distinction is between “the engine supports this feature” and “the feature is correctly enabled in my setup”. Those statements need different evidence.

Does open source mean secure?

Open source allows people to inspect how a program works, discuss changes and propose fixes. It creates opportunities for review that are more limited in a completely closed implementation.

Available source code does not prove an absence of bugs. It also does not establish that the app you downloaded was built from the expected code, configured safely or released without additional data collection.

Trust has several parts: the engine's origin, the app developer's work, the connection settings and the server operator's behaviour. Check the part about which a claim is being made. A statement about the quality of an open-source engine does not verify a commercial provider's privacy policy.

Logging illustrates the point. Xray includes logging settings, described in its log configuration documentation. Consequently, “we use Xray” does not mean “we record nothing”. The operator and configuration determine the actual policy.

Nor does having the same core make two apps interchangeable. Their interfaces, profile handling, update processes and system integration may differ. Evaluate the application you will actually use, not just the familiar component in its description.

Why the engine version can matter

New features may require updates at both ends of a connection. An app with an older embedded engine may not understand a profile containing newer parameters.

The app version and core version are different numbers. If support asks for both, look in the About section or connection information. That helps distinguish a compatibility problem from an unavailable server.

Updating an embedded core through the app's supported process is usually the sensible route. Replacing files using instructions for another program can break the integration even when the replacement is an official build.

Releases can also carry a pre-release label. The newest build is not automatically the right choice for a connection you rely on. The app's guidance and compatibility with your service matter more than having the highest version number.

What to check before using it

Obtain the app from a source linked by its developer or your service. Get profiles from an operator you trust and keep access credentials private. After connecting, try your normal activities and check whether routing exclusions apply.

The name Xray-core answers a useful question: which engine is working inside? Choosing a service requires further answers: who supplies the servers, how data is handled and where to get help. Understanding these roles lets you use the technology without unrealistic expectations or the need to configure it from scratch.

You don't have to run a networking core or maintain a server yourself: for everyday VPN use, you can connect your device to 2Wisp.