Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.
What Are Xray and V2Ray? Proxy Cores Explained
Ryan Foster
October 5, 2026· 10 min read
Xray and V2Ray are software cores that process and forward network traffic using configured proxy protocols and supporting modules. They are not names for a single VPN protocol, and a graphical client that uses one of them adds its own interface and integration choices around the core.［1］［2］
Key Takeaways:
- A core is software; a protocol defines how communicating peers exchange messages.
- Inbounds accept traffic, routing selects a path, and outbounds send it onward.
- A client interface, a loaded core, and an active connection profile have different identities.
- Xray and V2Ray have related origins but are not universally compatible substitutes.
What do Xray and V2Ray actually do?
A core is the engine that interprets configuration and carries out networking work. It can combine entry interfaces, forwarding protocols, routing decisions, and supporting services in one process. A core may run on your device, on a remote server, or at more than one point along a connection; the word “core” describes its software role, not its physical location.［2］［3］
The diagram is a responsibility map, not a compatibility chart or a complete configuration. The client interface sits outside the conceptual core flow. Within the core, an inbound receives a request, routing makes a forwarding decision, and an outbound uses the selected connection method to send traffic onward.
The interface is another component
A graphical application may manage profiles, start a core process, set a system proxy preference, or integrate traffic capture. Those functions are useful, but the interface's name is not sufficient evidence of which core release or connection method is active. Some applications can use different engines across versions or selected profiles.
The VPN fundamentals explanation distinguishes application proxying from device routing. A connect button can hide several decisions behind one action; to understand the resulting connection, identify the traffic entry, loaded configuration, and onward path separately.
Why is a proxy core different from a protocol?
In the proxy core vs protocol distinction, the core is an implementation that can understand several sets of wire rules. A protocol specifies the messages and behavior peers must agree on. Changing the core binary is a software change; changing a profile's protocol is a connection-contract change. Either can affect behavior, but they answer different questions.
Transport and security add more names
A profile may name a forwarding protocol alongside a transport, a security layer, and a flow-control option. Reading these as one interchangeable list loses the job each performs. A routing rule is not encryption, and a transport choice does not itself state how an application is authorized to use a server.
For examples of actual forwarding protocols, the Trojan definition and TLS path and Shadowsocks application-proxy model describe peer exchanges rather than client brands. A core supporting a protocol does not mean every active profile uses that protocol.
The separate protocol, transport, and obfuscation layers provide vocabulary for reading a profile. Avoid translating “supports” into “enabled”: an available capability, a configured capability, and an observed working path are different forms of evidence.
How do inbounds, routing, and outbounds divide work?
An inbound accepts traffic through a configured entry. Routing evaluates the information available for that request and selects an outbound path. An outbound sends data toward a remote proxy or another configured destination; direct forwarding can also be an outbound choice. The architecture places these responsibilities in separate components.［2］［3］
The same words apply at different endpoints
On a device, an inbound might accept a local application's proxy request. On a remote server, an inbound can accept the corresponding remote protocol. The server's outbound then handles the onward path. “Inbound” therefore means entry into that process, not always traffic arriving from the public Internet.
Likewise, “outbound” means leaving that process, not necessarily using a paid remote proxy. A profile can choose a direct route for some requests and a proxy route for others. To understand a destination's path, inspect the routing outcome instead of assuming that starting the core sends every request through one remote server.
Routing may use domains, addresses, ports, or other supported information; the available fields and resolution behavior depend on the implementation and configuration. A rule that relies on a domain also needs the relevant domain information to be available. The presence of a rule does not prove every application request exposes the same inputs.［4］
Entry, decision, and exit form a useful failure map
If the application never sends traffic to the inbound, changing a remote protocol cannot explain that missing local entry. If traffic enters the core but selects a direct outbound, the selected remote proxy may be healthy yet unused. If the expected outbound is selected and fails, the next question concerns that path's identity, authentication, or reachability.
This is a conceptual way to organize evidence, not a prescription to alter routing policy. Keep permitted network use and organizational restrictions in view when interpreting a profile. A configuration should be understood before it is changed, particularly when several applications share the same client.
How are the Xray core and V2Ray core related?
The Xray core originally branched from v2ray-core. Project X's current introduction explicitly describes independent evolution and warns against treating Xray as a fully compatible drop-in replacement. Similar-looking configuration sections are evidence of related design, not a guarantee that all fields, environment variables, APIs, or features are interchangeable.［1］
Compatibility has several dimensions
A V2Ray core profile needs to match the schema and capabilities of the release actually running it. The same principle applies to Xray. Successful parsing is only one dimension: the remote peer must also agree on protocol behavior, authentication, transport, and relevant security options.
Consider an application that imports a profile without an error. That observation establishes that the importer accepted something, but it may normalize fields, omit unsupported options, or select a different engine. It does not establish that every intended option reached the running core or that the remote server accepts the result.
Similarly, a protocol name appearing in both projects' documentation does not prove all extensions or combinations are common to both. Verify the precise feature and release in each project's current documentation. Do not copy a feature list from one project and label it as the other's supported capabilities.
The VLESS, REALITY, and Vision layer explanation develops those names in their own context. It is a separate reference, not a general promise that a profile mentioning them can be moved between all clients or cores.
Does a core automatically provide whole-device VPN coverage?
A core processes the traffic delivered to it. Device-wide coverage additionally depends on application integration, system routing or capture, DNS handling, and the selected policy. A local proxy entry can be appropriate for one application without automatically covering a second program that ignores the system proxy preference.
A VPN interface label does not identify the remote protocol
A client may add an operating-system VPN or TUN interface to collect packets, then translate that traffic into the core's forwarding path. The local interface explains capture; it does not rename the remote exchange. Equally, a remote protocol's encryption does not demonstrate that every device packet entered that interface.
If you use AethoVPN's global-mode setting, its documented on/off traffic scope is the relevant client-level fact; a low-level core label is a different kind of information, and the protocol choice overview helps keep software identity separate from coverage and trust. Do not infer a service's underlying implementation from generic client terminology.
The question of whether VLESS/REALITY is a VPN protocol examines that classification more closely. It separates a protected proxy exchange from additional components that can make an application feel like a device-wide VPN.
Which component owns the behavior you are seeing?
This table is an interpretation aid. It assigns responsibility without assuming a particular graphical application, operating system, or complete feature set. The decisive evidence is the actual loaded software and path, rather than a marketing label attached to a profile.
| Component | Typical responsibility | What its name alone cannot establish |
|---|---|---|
| Client interface | Profile management, process controls, and integration choices | Exact running core version or every effective setting |
| Core executable | Configuration interpretation and supported networking modules | Which available protocol is active for a request |
| Inbound | Accept traffic into that process through an entry contract | Every device application uses that entry |
| Routing | Choose a path using supported rules and available request information | Encryption, anonymity, or successful remote authentication |
| Outbound | Forward through the selected direct or proxy path | All other requests use the same path |
| Protocol, transport, and security settings | Define the peer exchange and protected remote connection | Local traffic capture, service privacy policy, or universal compatibility |
Ask for evidence that can distinguish the owner
A useful description includes the client name, core name and release, active profile's documented layers, affected application, and last established connection stage. When sharing evidence, remove credentials, private keys, subscription addresses, account identifiers, and sensitive destinations. A screenshot can be helpful, but visible names are not a substitute for effective configuration.
If an issue appears after an update, separate the changed interface, importer, core, and server components. A before-and-after observation is stronger when the same application task and network conditions are held constant. Without that separation, attributing the result to “Xray” or “V2Ray” can hide the actual owner of the change.
Summary
- Xray and V2Ray are proxy cores that can implement multiple connection methods.
- Inbound, routing, and outbound are responsibilities within a process, not synonyms for encryption.
- Related origins do not establish universal configuration or wire compatibility.
- Coverage depends on traffic entry and client integration; evaluate the effective path rather than the application label.
FAQ
Are Xray and V2Ray VPN protocols?
Xray and V2Ray are software cores, not single VPN protocols. They can implement proxy protocols and supporting networking modules. A client may add device-wide capture, but that integration does not turn a core's name into the wire protocol used by a profile.
Is Xray a drop-in replacement for V2Ray?
Xray originally branched from v2ray-core, but the projects evolved independently. Current Project X documentation warns against assuming full drop-in compatibility. Check the exact configuration, feature, release, and remote peer requirements instead of replacing an executable based only on related names.
Is a graphical client the same as its core?
The interface and core have different responsibilities. An interface can import profiles and manage integration while a core handles the networking exchange. The application name alone does not establish the running core version or the effective settings of an active request.
Does an inbound always mean a public server port?
An inbound is an entry into the particular core process. On a client device it may accept a local application request; on a server it may accept a remote proxy exchange. Its role is relative to the process, not automatically to the public Internet.
Does routing encrypt traffic?
Routing selects a forwarding path using supported rules and available request information. Encryption belongs to the connection's protocol and security layers. A route can select direct forwarding or a protected proxy path, so a routing rule alone is not an encryption guarantee.
Does successful profile import prove compatibility?
Profile import proves only that the importer accepted the input. The running core must support the effective settings, and the remote peer must agree on the connection contract. Imported profiles can still fail before authentication or forwarding, or omit intended behavior.
Does running a core cover every application?
Running a core does not automatically send every application's traffic into it. Coverage depends on proxy preferences, capture, system routing, DNS handling, and policy. Identify the application's actual entry and outbound path before concluding that all device traffic uses the selected connection.
Disclaimer: This is a component-level explanation, not a configuration or migration guide. Capabilities vary by release and client integration; follow applicable laws and network policies and consult each project's current documentation.
Sources
Sources checked 5 October 2026.
