Xray VPS Hosting: VLESS, XTLS Reality, and Advanced Proxy Protocols

Xray-core was forked from V2Ray (Project V) in 2020 by the XTLS project team. The primary motivation was to add XTLS, a novel transport that passes through inner TLS sessions without re-encrypting them, dramatically reducing CPU overhead while maintaining security. V2Ray's upstream eventually declined to merge XTLS, leading to the permanent fork. Xray-core now diverges from V2Ray in several areas: XTLS support, the Reality protocol, and performance optimizations that make it faster than V2Ray for equivalent workloads.

The Reality protocol is Xray's most significant addition over V2Ray. Reality solves a long-standing problem with VLESS+XTLS: a server running VLESS+XTLS needs a TLS certificate for a domain, and that domain is what the client presents in the TLS SNI field. Censorship systems can detect that the domain resolves to a VPS IP rather than the legitimate website's infrastructure, flagging it as a proxy. Reality replaces this with a mechanism where the client's TLS handshake targets a legitimate HTTPS server (any public HTTPS site you choose as a "steal" target), and the Xray server presents that site's actual TLS fingerprint and certificate during handshake, passing the connection through to the real site if authentication fails. This makes the traffic completely indistinguishable from a legitimate TLS connection to the target site, at the SNI, certificate, and fingerprint level simultaneously.

In practice, Reality-enabled Xray connections survive blocking attempts that defeat VLESS+XTLS and VMess+WebSocket+TLS. The GFW in China, which has the most sophisticated DPI and active probing infrastructure in the world, cannot distinguish an Xray+Reality connection from legitimate HTTPS traffic to major CDN-fronted services. For users in the most censored environments, Xray+Reality is currently the most effective tool available.

For less aggressive censorship environments (Russia, Iran, Turkey), VLESS+WebSocket+TLS or VMess+WebSocket+TLS through V2Ray achieves similar results with a simpler configuration. Choose Xray+Reality for maximum stealth against active probing; choose V2Ray+WebSocket+TLS for simpler deployment in moderately censored environments.

Install Xray using the official installation script: bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install. This downloads the latest Xray-core binary to /usr/local/bin/xray, installs systemd service files, and creates the configuration directory at /usr/local/etc/xray/. The config.json in this directory is the main configuration file.

For VLESS+Reality configuration, you need: a UUID for authentication (generate with xray uuid), an x25519 key pair for Reality (generate with xray x25519), and a shortId (a random hex string, e.g., 8-16 hex characters). Choose a "steal" target: a major HTTPS site like www.microsoft.com or www.apple.com that has a large CDN infrastructure. The client's TLS handshake will mimic a connection to this site.

The inbound configuration sets protocol: vless, port: 443, and the streamSettings with network: tcp, security: reality, and the realitySettings block containing the x25519 private key, shortId list, and the steal target's serverName and fingerprint (chrome mimics Chrome's TLS fingerprint). Users must be defined with an id (the UUID) and flow: xtls-rprx-vision for the Vision flow control that optimizes XTLS performance.

On the client side, configure Xray-compatible clients (v2rayN, NekoBox, Hiddify, or sing-box) with the server address, port 443, UUID, flow: xtls-rprx-vision, the x25519 public key, shortId, and the steal target serverName. The connection appears as a TLS session to the steal target. Verify functionality by checking your exit IP through the proxy - it should show your VPS's IP. If the connection fails, check that port 443 is open in your VPS firewall (ufw allow 443/tcp) and that no other service (nginx, Apache) is listening on port 443.

Xray's XTLS Vision flow reduces CPU usage by passing through inner TLS data without re-encryption. On a 1 vCPU VPS, XTLS Vision handles 500+ Mbps without CPU saturation, compared to VMess+WebSocket+TLS which may saturate a single core at 100-150 Mbps. Enable Vision flow (flow: xtls-rprx-vision in both server and client user configuration) for the best performance-to-resource ratio.

A single Xray instance can run multiple inbound protocols simultaneously. Common multi-protocol configurations: VLESS+Reality on port 443 for maximum stealth, VLESS+WebSocket+TLS on port 8443 as a fallback that works through CDN proxying, and VMess+WebSocket on port 80 for legacy client compatibility. Each inbound gets its own port and protocol configuration in the inbounds array of config.json. All share the same outbound configuration routing traffic through the VPS's default internet gateway.

Routing rules in Xray support the same geoip.dat and geosite.dat files as V2Ray. Add rules to block connections to known malware C2 infrastructure (geosite:category-ads-all, known botnet domains) at the server level, preventing your VPS from being used as a proxy for malicious traffic. This is important for maintaining your VPS's IP reputation: if your VPS's IP appears in spam or malware traffic, it may be blocklisted by services that your legitimate users need to reach.

Monitor Xray's resource usage with systemctl status xray and journalctl -u xray. Xray logs connection attempts and errors by default at /var/log/xray/. Adjust log level in config.json (loglevel: warning is a good balance between useful diagnostics and log volume). For a production deployment serving many users, integrate Xray logs into a monitoring stack to alert on unusual connection volumes or error rates that might indicate a configuration problem or abuse.