Xray-core is a command-line proxy engine that speaks VLESS, VMess, Trojan, Shadowsocks, and WireGuard, using rule-based routing and traffic camouflage to carry selected connections through a server you control.
Xray-core is a proxy platform that runs as a single command-line program and is configured with a JSON file. You define inbound listeners, outbound connections, and routing rules; the core then decides per connection which outbound to use and how to transport it. That model suits a local client setup, a self-hosted server, or a gateway in front of a whole network, without changing the program itself. The project focuses on protocols it develops in-house, such as VLESS, and on traffic patterns that resist fingerprinting, so the same engine handles both ordinary proxying and situations where detection is a real problem.
Deployment usually means pairing Xray-core with a front end, because the core ships without a graphical interface. Desktop users typically run a GUI wrapper that edits the configuration and starts the process, while server operators write the file themselves or use a panel. Anyone moving from an older setup should note that the core has diverged from the v2ray configuration it originally branched from, so older files may need adjustment rather than copying. If your needs stop at routing browser traffic through a simple tunnel, a dedicated desktop client such as shadowsocks-windows is easier to live with than a configurable engine, and it takes far less time to set up.
The main advantage of Xray-core is that one process covers jobs that usually need several tools. It can terminate connections as a server, dial out as a client, or sit in the middle as a gateway, and it supports both its own protocols and familiar ones such as Trojan, Shadowsocks, SOCKS, HTTP, and WireGuard on the same instance. Routing decides where each connection goes using domain, IP, port, protocol, process, or user, so split tunnelling becomes a configuration detail instead of an extra program. Overhead stays low because VLESS skips redundant encryption layers and Splice shortens the forwarding path, which is why the core runs comfortably on routers and single-board computers rather than only on servers. Because it is configuration-driven, one file captures the whole deployment, making it reproducible and easy to version alongside the rest of your infrastructure.
Key capabilities and highlights.
VLESS is a lightweight protocol that drops the redundant encryption layer and relies on the transport for security, while XTLS flow control modes such as Vision keep the tunnel efficient. The combination reduces overhead and behaves like ordinary TLS traffic, which helps on constrained links.
REALITY lets a server borrow the TLS identity of a real, unmodified website so client handshakes are indistinguishable from ordinary browsing to an observer. That removes the need for a domain and certificate of your own while reducing fingerprints that detection systems look for.
Route each connection by domain, IP address, port, protocol, process name, or user, and send it through a different outbound as needed. Splitting local traffic from remote traffic is the common case, and the same rules handle blocking, redirection, and per-application policy.
Speak VLESS, VMess, Trojan, Shadowsocks, SOCKS, HTTP, and WireGuard from a single process, mixing protocols between inbounds and outbounds. That means one deployment can serve modern clients, legacy clients, and internal services without running a separate daemon for each.
DNS queries can be resolved locally, forwarded upstream, or answered from a static mapping depending on the rule that matches. Keeping DNS decisions inside the same configuration prevents leaks and stops routing rules from being defeated by a resolver returning an unexpected address.
TCP, mKCP, WebSocket, HTTP/2, gRPC, and XHTTP transports can be paired with the proxy protocols, letting you pick a shape that survives the network you are on. Changing transport is a configuration edit rather than a rebuild.
Inbound users are defined individually, so a server can hand out separate credentials and apply different routing or limits per account. A built-in API exposes statistics and runtime control, which is what panels and monitoring scripts connect to when managing many users.
Xray-core ships as one executable that also provides control functions, so installation means placing a file and pointing it at a configuration. That makes deployment on routers, small boards, and containers practical, and it keeps upgrades simple.
Browse historical releases and previous builds.
Common questions about Xray-core.
It carries network traffic through a proxy you control. Common setups are a desktop client that tunnels browser and app traffic, a server that accepts connections from your own devices, and a gateway that routes an entire network. Routing rules decide which connections are proxied and which go out directly.
No. The core is a command-line program, and the graphical experience comes from separate front ends that write the configuration and start the process for you. Server operators often skip a front end entirely and manage the configuration file together with the built-in API.
It supports its own protocols, including VLESS and the XTLS flow-control modes, and it also speaks VMess, Trojan, Shadowsocks, SOCKS, HTTP, and WireGuard. Because inbounds and outbounds are configured separately, several protocols can be mixed inside a single deployment.
REALITY is a camouflage mechanism that lets the server present the TLS identity of an existing website instead of one you obtained yourself. Client traffic then looks like an ordinary visit to that site, which reduces the fingerprints detection systems rely on and removes the need to register a domain for the tunnel.
Yes. Routing rules match on domain, IP address, port, protocol, process, or user, and each match can point to a different outbound. A typical configuration sends local and regional destinations directly while proxying everything else, and unmatched traffic falls through to a default outbound.
Not fully. The project started from v2ray-core but has evolved independently, and some configuration structures differ. Simple client files often work after review, but environment variables, API prefixes, and several protocol options have changed, so expect to edit rather than copy older files unchanged.
You need something to connect to. The core can run on a remote machine you control and accept incoming connections, or it can act purely as a client that dials an endpoint operated by someone else. Without a matching server or compatible endpoint, the configuration starts but no traffic flows.
Yes, that is one of its design goals. VLESS avoids a redundant encryption layer and the Splice forwarding path shortens data handling, so the core stays usable on routers, single-board computers, and containers where a heavier proxy stack would exhaust the available hardware.
Xray-core is a command-line proxy engine that speaks VLESS, VMess, Trojan, Shadowsocks, and WireGuard, using rule-based routing and traffic camouflage to carry selected connections through a server you control.
v2rayN is a desktop GUI that drives Xray, sing-box, and other proxy cores, letting you import subscriptions, test server latency, choose routing rules, and enable system proxy or TUN mode from one window.
sing-box is a configurable proxy platform that runs as a single binary, accepting traffic through inbounds, matching it against routing rules, and forwarding it through outbounds that can speak dozens of protocols.
Clash Verge Rev is a desktop GUI for the Mihomo rule-based proxy core, letting you import subscription profiles, switch nodes, edit rules visually, and route traffic through system proxy or TUN mode.
Surfshark is a VPN service that encrypts internet traffic, masks the user’s public IP address, and combines selective routing, tracker blocking, multi-server connections, and automatic protection for everyday privacy.
Comments