Xray-core in plain terms: how it differs from a regular VPN
Xray-core is a server and client core, an evolution of the v2ray-core project. It is not a “VPN” in the classic sense: it does not create a network adapter and does not encrypt all system traffic. Xray-core is a proxy engine with a set of modern DPI-circumvention protocols: VLESS, VMess, Trojan, Shadowsocks, plus the unique XTLS and REALITY modules.
The main difference from WireGuard or OpenVPN: those are tunnel VPNs with a fixed transport that can be identified by the signature of the first packet. Xray-core with REALITY makes the connection indistinguishable from ordinary HTTPS to a legitimate external site. That is why a significant share of working configs in Russia relies on it.
Below: what Xray-core can do, how it compares with other tools, and why in 2026 it is so often mentioned in connection with bypassing blocks.
In short
- Xray-core is a proxy core based on v2ray, not a classic VPN.
- It does not create a VPN adapter: it works as a proxy that individual applications use, or everything can go through TUN.
- It supports VLESS, VMess, Trojan, Shadowsocks; the unique features are XTLS-Vision and REALITY.
- REALITY is masking as another site’s TLS; XTLS is optimization of TLS proxying.
- It differs from WireGuard by having a more flexible transport and built-in masking as HTTPS.
- One Xray server can simultaneously run several different protocols on one port.
What Xray-core is, and why it is not a VPN
A classic VPN (WireGuard, OpenVPN, IPsec) is a tunnel protocol. It creates a virtual network interface on your device and wraps all system traffic into it. From the outside, this is a recognizable stream in one format.
Xray-core is built differently. It is a proxy process: applications talk to it over SOCKS5 or HTTP, and it repackages their traffic into the selected protocol (VLESS, VMess, Trojan, SS) and sends it to the server. On the server, a second Xray unpacks it and forwards it to the internet. Details are in the xray-core repository and in the XTLS documentation.
Which protocols it supports
In Xray “out of the box”: VLESS (native transport, lightweight, without its own cryptography), VMess (an older protocol with built-in encryption), Trojan (TLS masking as HTTPS), Shadowsocks (including AEAD), plus the service components dokodemo-door, freedom, blackhole.
XTLS-Vision
An optimization for VLESS+TLS: it reduces the overhead from double encryption (TLS outside and TLS inside the tunnel). It is useful for heavy video traffic. Today it is often replaced by REALITY, but Vision remains relevant as a “lightweight” option.
REALITY
The main “secret sauce” of Xray-core. Instead of its own certificate, the server returns the real certificate of someone else’s popular site, which it fetches from that site on the fly. From the outside, this looks like HTTPS to a legitimate domain. DPI has almost no signals by which it can distinguish this traffic from a real HTTPS browser.
How it differs from WireGuard and OpenVPN
WireGuard and OpenVPN are “all or nothing” tunnels with a fixed format that DPI recognizes from the first packet. Xray with REALITY has no “face” of its own: it pretends to be HTTPS. The price is configuration complexity and dependence on an external target site.
What can break in an Xray config
| Symptom | Possible cause | What to check |
|---|---|---|
| The client says “config parse error” | Incompatible JSON format | Compare the core version with the config |
| There is a connection, but sites do not open | The client’s DNS is bypassing the proxy | Enable proxy DNS / fakeip on the router |
| Some sites go without the proxy | routing rules were triggered | Check the routing block in the client config |
| A working VLESS+REALITY suddenly dropped | The TLS of the cover site changed | Change the target to a current one |
| Speed is low on VMess+TLS | Double encryption is consuming CPU | Switch to VLESS+XTLS-Vision or REALITY |
| The client shows “handshake failure” | Incorrect public key or sid | Compare with the server config |
How to check right now
If your Xray-core config has stopped working, first separate an “only me” problem from an “everyone” problem. Freedom Checker shows how popular protocols behave by operator and region, without advertising specific services.
If a protocol is unavailable at scale on one operator but works on another, filtering has almost certainly intervened. If the protocol does not respond anywhere, the error is either in the config or on the server itself.
Failure or blocking?
An Xray server failure usually looks like a complete outage: nothing connects, all your protocols on this VPS are down. Often the cause is a crashed process or an expired certificate for the REALITY cover site.
Blocking appears selectively: VMess does not work, but VLESS+REALITY does; one IP does not respond, another one does. This is a typical picture of filtering on TSPU (ТСПУ) equipment: outdated protocols or specific IPs are cut off, while more resilient combinations get through.
What to pay attention to
- The core version on the client and server must be compatible — the config format gets updated.
- In REALITY, public key, sid, and fingerprint must match.
- Sid (short id) can be any hexadecimal string of 0–8 characters.
- Target must be a real domain with working HTTPS, preferably large and “safe”.
- Do not publish your configs: they contain secrets equivalent to a password.
- For management, it is convenient to use a panel such as 3X-UI, but it is just a GUI on top of the same core.
- If you plan to bypass mobile DPI, keep a backup outbound on Hysteria2 or sing-box.
Conclusion
Xray-core is not “just another VPN”, but a flexible proxy core with a set of modern protocols and strong TLS masking. Its main strengths are REALITY and XTLS-Vision, which make it possible to make traffic practically indistinguishable from ordinary HTTPS.
If you are just starting out, it is more convenient to take a ready-made client on Xray-core (Hiddify, v2rayNG, NekoBox) and connect a ready-made config. Server setup is a separate subject that you can return to later.