Xray-core: A Configurable Proxy Core for Encrypted Tunnels
Xray-core is an open-source proxy core that routes network traffic through encrypted tunnels you control, running as a single executable on both servers and client machines. Everything is described in one JSON configuration file: inbounds that accept connections, outbounds that forward them, and routing rules that decide which traffic takes which path. Its original protocols, including VLESS, XTLS, XUDP, XHTTP, and REALITY, sit alongside familiar ones such as VMess, Trojan, Shadowsocks, SOCKS, HTTP, and WireGuard, so one instance can bridge very different network conditions. Because each layer is independent, a protocol can be combined with any flow-control mode, transport, and routing scheme, letting you direct traffic by domain, IP, port, process, or user without reconfiguring the applications that generate it.
Deployment is deliberately undemanding. A minimal configuration can be a few dozen lines of JSON, and the project keeps everything in one process, so there is no separate control daemon to install and no runtime to bootstrap first. Operators who need more reach out for add-ons: a statistics API exposes per-user counters, fallback lets one port serve both a proxy and a legitimate website, and reverse proxy bridges machines that cannot reach each other directly. Provisioning a virtual LAN for private file sharing and remote desktop access is a different job, which is where a tool like Hamachi fits, while Xray-core stays focused on tunneling traffic that has to survive inspection and stay fast under load.
Benefits of Using Xray-core
The biggest benefit is control. Xray-core does not guess what your traffic should do, and it applies the same rules no matter which application opened the connection. Because routing can match on domain, IP, port, network type, process, and user, one instance can send streaming traffic directly while pushing everything else through an encrypted tunnel, with no per-application settings to maintain. The protocol layer is equally flexible: VLESS removes redundant encryption to cut overhead, REALITY borrows a real site’s TLS handshake so the connection does not stand out, and XTLS flow control reduces forwarding cost enough that modest hardware remains a practical endpoint. Sharing a server between accounts is straightforward thanks to per-user identifiers and statistics, so an administrator can see exactly what each account consumed. Finally, the configuration is plain, portable text that can be version-controlled, reviewed, and templated, which keeps large deployments predictable instead of hand-tuned.
Xray-core Software Information
- Developer: XTLS
- Current Version: 26.3.27
- File Size: 19.9 MB
- License: Open Source
- Language: en-US
- Downloads: 481K
- Platform: Windows Desktop
System Requirements
- Processor: 2-core CPU
- RAM: 2 GB RAM
- Storage: 1 GB available storage
- Graphics / GPU: Not required
Visit the official Xray-core website
Xray-core Features
VLESS Protocol
VLESS is a stateless protocol that removes the extra encryption layer VMess carries, leaving confidentiality to the TLS or REALITY handshake underneath. The result is lower overhead and fewer round trips per connection, which matters on slow links and modest hardware. Each client is identified by an identifier and an optional email label, so a single inbound can serve many accounts.
REALITY Security Layer
REALITY lets a server present the TLS handshake of a real, reachable website instead of one of its own certificates. Clients verify that identity, so the session resembles ordinary HTTPS traffic to that site. It also removes the need to obtain and renew server certificates, which keeps small self-hosted setups simple to operate.
XTLS Flow Control
XTLS provides several flow-control modes that change how data is copied between the client and the destination. Vision handles nested TLS setups and preserves the original record structure, while Splice avoids unnecessary copies when both ends can forward in place. The practical effect is lower processor load and steadier latency on busy servers.
Flexible Routing Engine
Routing rules match traffic by domain, IP range, port, network, inbound tag, user, and platform-dependent cues such as process name. Rules are evaluated in order and can dispatch a request to different outbounds, block it outright, or chain it through another proxy. Country and service-level rule sets add broad matching without hand-written lists.
Multiple Transport Layers
The same protocol can travel over TCP, WebSocket, HTTP/2, gRPC, QUIC, mKCP, XHTTP, or a local domain socket. That choice determines what the traffic looks like on the wire, so operators can pick a transport that blends into their network or tolerates packet loss on unstable links. Changing transport never requires rewriting routing rules.
Fallback and Port Sharing
Fallback lets a VLESS inbound hand unmatched connections to another service, such as a web server, based on path, ALPN, or other request properties. A single port can therefore serve both the tunnel and a genuine website at the same time. Casual inspection and automated scanners see an ordinary site rather than a dedicated endpoint.
Statistics and Management API
The built-in API reports traffic counters, online users, and runtime controls such as adding or removing accounts without restarting the process. The same executable also provides utility commands, so no separate control program is required. Administrators can feed these counters into monitoring dashboards, alerting, or simple usage scripts.
Single Self-Contained Executable
Xray-core ships as one self-contained program with no external runtime dependencies, so deployment does not involve installing a language runtime or library stack. A configuration file plus that single program is enough to start serving traffic. Because the configuration format stays consistent across builds, a setup prepared in one environment transfers easily to another.
Xray-core Old Versions
Version 26.2.6 Updated: February 6, 2026 Download
Version 26.2.4 Updated: February 4, 2026 Download
Version 26.2.2 Updated: February 2, 2026 Download
Version 26.1.31 Updated: January 31, 2026 Download
Version 26.1.23 Updated: January 23, 2026 Download
Xray-core FAQs
What is Xray-core used for?
It builds encrypted tunnels between a client and a server and routes selected network traffic through them. Typical uses include protecting traffic on untrusted networks, reaching services blocked locally, testing how proxy protocols behave under real conditions, and deciding which applications take which path. It runs as a single process, so it suits both full servers and small devices.
How does Xray-core differ from V2Ray?
Xray-core began as a fork of v2ray-core but has evolved independently, so it should not be treated as a fully compatible drop-in replacement. Configuration structures still look familiar, yet environment variables, API prefixes, and many features differ. Xray-core adds VLESS, XTLS flow control, REALITY, XHTTP, and ships as one executable that includes its management commands.
Is Xray-core the same thing as a VPN?
Not exactly. A virtual private network normally encrypts all traffic from a device and places it on a virtual network with its own addressing. Xray-core works at the level of individual connections, so it can route some traffic through a tunnel and leave the rest untouched. That granularity is useful when only part of your traffic needs protection or a different path.
Does Xray-core need a separate client program?
No. The same executable acts as server or client depending on the configuration it receives, because inbounds and outbounds define network behavior in both roles. A local configuration can expose a SOCKS or HTTP inbound that other applications use without knowing anything about the tunnel. Management and utility commands are built into the same program as well.
Can one Xray-core instance serve multiple users?
Yes. A single inbound can list many accounts, each with its own identifier and optional email label. Traffic counters are then reported per account through the statistics API, which helps with quotas, billing checks, and troubleshooting. Accounts can be added or removed at runtime through the API, so busy servers do not need to restart when users change.
What is REALITY and why would you use it?
REALITY is a security layer that lets a server present the TLS handshake of a real, accessible website rather than its own certificate. Clients confirm that identity, so the connection looks like ordinary HTTPS traffic to that site. It reduces fingerprinting and removes the work of issuing and renewing certificates, which keeps maintenance light for self-hosted deployments.