XRay core explained: the engine behind censorship-resistant VPNs

People keep calling XRay a VPN protocol. It is not. XRay is a proxy platform. Think of it like nginx, but instead of routing HTTP requests to backend servers, it routes entire network connections through encrypted tunnels using whatever protocol you want.

VLESS is a protocol. Reality is an authentication layer. WireGuard is a protocol. XRay is the thing that runs VLESS and Reality on the server side. Getting this distinction right matters if you want to understand why the censorship-resistance ecosystem works the way it does.

Where XRay came from

The story starts with V2Ray, a project created around 2015 by someone using the pseudonym "Victoria Raymond." V2Ray introduced the VMess protocol and a modular architecture where you could swap transports (TCP, WebSocket, gRPC) independently from the proxy protocol itself. It was a good idea and it gained traction fast, especially in China where people needed tools that could survive the Great Firewall.

By 2020, V2Ray's original creator had gone quiet. The V2Fly community maintained a fork called v2fly-core. A developer known as RPRX contributed XTLS, a performance optimization that let proxy traffic skip redundant TLS encryption layers. It was a significant technical contribution.

Then things got messy.

In November 2020, RPRX's XTLS code was removed from v2ray-core over a licensing dispute. The details are complicated and somewhat political, but the result was clean: RPRX forked v2fly-core (from commit 9a03cc5) and created xray-core. A clean break.

XRay moved faster after the split. RPRX shipped XTLS Vision, then Reality, then XHTTP. The project currently sits at 35,900+ GitHub stars versus V2Ray's roughly 22,000. The community voted with their commits. Most active development in the anti-censorship proxy space now happens in xray-core or projects built on top of it.

What XRay actually does

XRay is a Go binary. You feed it a JSON config that defines inbounds (listeners) and outbounds (destinations), and it proxies traffic between them. That's the whole model.

The power is in what you can combine. XRay supports multiple proxy protocols:

• VLESS, which is lightweight with no encryption overhead (it relies on the transport layer for that)
• VMess, the original V2Ray protocol with AES-128-GCM encryption (MD5 auth was recently removed)
• Trojan, which mimics HTTPS traffic using password-based auth
• Shadowsocks-2022, the modern rewrite with AEAD-2022 ciphers

Each of these can run over any of XRay's transports:

• Raw TCP
• mKCP (UDP-based, like KCP but modified)
• WebSocket
• HTTP/2 (h2)
• gRPC
• QUIC
• XHTTP (XRay's own multiplexed HTTP transport, added in 2025)

So you can run VLESS over WebSocket behind a CDN, or Trojan over gRPC through Cloudflare, or VLESS over raw TCP with Reality authentication. The protocol and the transport are independent. Mix and match based on what your network environment allows.

XRay also has a routing engine. You can write rules that send traffic for certain domains through one outbound, block ads through another, and direct everything else through the proxy. It's closer to a programmable network stack than a simple tunnel.

XTLS and why performance matters

Standard proxy setups have a problem. When you visit https://example.com through a proxy, the TLS encryption happens twice: once between your browser and example.com (inner TLS), and once between your client and the proxy server (outer TLS). You're encrypting already-encrypted data. That's wasted CPU and added latency.

XTLS Vision fixes this. When XRay detects that the inner connection is already TLS 1.3, it stops encrypting the payload at the proxy layer after the handshake completes. The inner TLS provides confidentiality. The outer layer only needs to handle the initial negotiation.

XTLS splice goes further on Linux. It uses the kernel's splice() syscall to forward TCP data directly between file descriptors without copying it through userspace memory at all. The data moves from the network socket to the tunnel socket entirely in kernel space. XRay's Go process barely touches it.

The result: proxy throughput that's within a few percent of a direct connection. On a server with a 1 Gbps link, XTLS splice can saturate it. Traditional double-encrypted proxies top out well below that.

This is why VLESS with Reality performs so much better than older circumvention tools. The protocol is lightweight, the transport is efficient, and XTLS eliminates the redundant encryption tax.

The ecosystem around XRay

XRay is the engine. A whole ecosystem of tools has grown around it.

Server management panels like 3X-UI give you a web interface for configuring XRay inbounds, managing user accounts, and monitoring bandwidth. They're popular for personal proxy servers because they remove the need to hand-edit JSON configs. If you've seen screenshots of someone's proxy setup with nice graphs and user lists, it's probably 3X-UI or a fork of it.

Desktop clients like V2RayN (Windows) and V2RayA (Linux) wrap xray-core with a GUI. They read subscription links, manage server lists, and handle routing rules. Most users in censored countries interact with XRay through one of these clients, not the raw binary.

sing-box is the interesting one. It's a newer proxy platform written from scratch by the SagerNet developer. It supports all of XRay's protocols (VLESS, VMess, Trojan, Shadowsocks) plus Hysteria2, TUIC, and others. More importantly, it compiles to a mobile library via gomobile. That's what makes VLESS Reality possible on phones. You can't reasonably run xray-core on iOS or Android, but you can embed sing-box's libbox into a native app.

The ecosystem splits roughly along these lines: xray-core dominates on servers, V2RayN/V2RayA on desktops, and sing-box on mobile. They all speak the same protocols.

How Fexyn uses XRay

We run xray-core on our VPN servers. Each server has a VLESS Reality inbound on port 443 (TCP with Reality authentication) and an XHTTP inbound on port 8444 (for environments where raw TCP to port 443 is filtered but HTTP-based transports get through).

On the server, our Fexyn Agent manages the xray-core process, handles key rotation, and provisions per-user UUIDs. When you connect with VLESS selected, the agent generates your credentials and the client receives a config that points to the right server with the right Reality keys.

The client side is where things get interesting. On Windows, we don't use xray-core at all. Instead, we create a Wintun TUN adapter and run tun2socks to route all system traffic into a SOCKS5 proxy that xray-core provides. Actually, we run a stripped-down xray-core in SOCKS proxy mode, and tun2socks captures packets from the TUN interface, reconstructs TCP/UDP sessions, and forwards them through that SOCKS proxy. The operating system sees a normal network adapter. All traffic goes through it. No app-level proxy configuration needed.

On Android and iOS, we use sing-box compiled as a native library. It handles the same VLESS Reality protocol but runs inside the OS's VPN framework (Android's VpnService, iOS's NEPacketTunnelProvider). sing-box was the right choice here because xray-core doesn't build cleanly for mobile platforms, and sing-box's libbox was designed for exactly this use case.

The result is the same across all platforms: your traffic looks like someone browsing microsoft.com (or whatever SNI the Reality config targets). DPI systems see a TLS 1.3 connection to a legitimate domain. Active probes against our server get redirected to the real site. The protocol comparison with WireGuard comes down to exactly this: WireGuard is faster but trivially fingerprintable, while VLESS Reality sacrifices a bit of throughput for near-total invisibility.

XRay compared to other tools

The anti-censorship space has a lot of projects. Here's where XRay fits.

Shadowsocks was the original. Simple, fast, single-purpose encrypted proxy. The 2022 rewrite (Shadowsocks-2022) fixed old cryptographic weaknesses, but Shadowsocks has a detection problem: the GFW can identify its traffic patterns through statistical analysis of packet lengths and timing. It still works in some regions. It's less reliable than VLESS Reality in heavily censored ones.

V2Ray (v2fly-core) is XRay's ancestor. Still maintained, still works. But it lacks XTLS Vision, Reality, and XHTTP. If you need those features, and in 2026 you almost certainly do, you need xray-core.

Trojan-GFW was clever when it launched. It disguises proxy traffic as HTTPS by running a real web server alongside the proxy. Reality took this idea further by eliminating the need to own a real TLS certificate for the target domain.

Hysteria 2 uses QUIC (UDP-based) with obfuscation. Great throughput, but QUIC-based protocols are getting more attention from censors. Some networks now block or throttle QUIC entirely. TCP-based tools like VLESS Reality are harder to blanket-block because you'd have to block HTTPS itself.

NaiveProxy uses Chrome's network stack to generate traffic that's statistically identical to a real Chrome browser. Very hard to detect, but the client-side setup is more complex and it doesn't have the same ecosystem of panels and clients.

XRay's advantage is not that it does one thing better than every alternative. The advantage is that it is a platform. It runs multiple protocols, supports multiple transports, has a mature routing engine, and has the largest active community. When the GFW develops a new detection method, xray-core gets a countermeasure within weeks. That's the benefit of 35,000+ stars and an active maintainer who treats this as an arms race.

Where it's going

XRay's development hasn't slowed down. Recent releases stripped out legacy code: VMess MD5 authentication is gone, MTProto support was removed. The codebase is getting leaner.

Two upcoming features stand out. XDRIVE is a transport that disguises proxy traffic as cloud storage operations. XICMP uses ICMP packets as a transport layer. Both are experimental, but they represent the same pattern that's defined XRay's evolution: find a traffic type that censors allow, and build a transport around it.

The version scheme tells you something about the pace. XRay uses vYY.M.DD format. Version v26.2.6 means February 6th, 2026. Releases are frequent. The project moves fast because it has to. The Great Firewall doesn't wait for quarterly release cycles.

If you're building anything that needs to survive in a censored network, XRay is the engine you probably want running on the server side. It's not the only option. But it's the one with the most momentum, the broadest protocol support, and the fastest response to new censorship techniques. That's why we chose it for Fexyn.