How to Set Up Xray (VLESS + Reality) on a VPS with 3x-ui

Reality is the current answer to deep-packet inspection, and it works by refusing to have an identity of its own. Rather than presenting a certificate you bought for a domain you registered, your server relays the handshake of a real website. Here is how to set up Xray on a VPS, and the parts people get wrong.

Why Reality changed the game for censored networks

Every stack before it needed a name: a domain you registered, a certificate you issued, VLESS or Trojan behind it. That holds until a censor probes your IP and finds a lonely domain with one visitor and a week-old certificate — at which point the block is not a guess but a confirmation. Reality removes the name: your server relays any handshake it cannot authenticate to a real site, which answers with its own certificate.

• No domain and no certificate — nothing in DNS or a transparency log points at your server.
• Active probing fails by design: a prober without the key gets the genuine camouflage site.
• Traffic sits on port 443 inside a real TLS 1.3 session, the dullest class online.
• The client mimics a browser's TLS fingerprint via uTLS, so the handshake reveals no proxy.

Be precise about the boundary; overestimating it is how people get caught. An observer sees your IP, the server's IP, port 443 and the name of the site you imitate — what visiting it for real looks like. What stays visible is shape: one long session to one foreign IP for eight hours a day is unusual whatever carries it. Reality defeats protocol fingerprinting and active probing, not traffic analysis, and it is not anonymity.

What you need before you set up Xray on a VPS

Choosing a location, and paying without an identity

Two variables decide how well this holds: where the box sits, and whether buying it points back at you. For speed, pick the nearest country that does not filter. For durability, pick a jurisdiction that will not surrender the server on request. Compare regions on /locations, and see /offshore-hosting for what jurisdiction changes.

ChainVPS runs 15 locations, six of them privacy-tier: the Netherlands, Switzerland, Romania, Iceland, Moldova and Luxembourg. Plans start at $3.49/mo for 1 vCPU, 1 GB of DDR5 and 20 GB of NVMe Gen4, with unmetered bandwidth, DDoS protection and deployment in under 60 seconds. Balances are funded with seven coins: Bitcoin, Monero, Ethereum, Litecoin, USDT, TRON or Solana. The ladder is on /vps, the policy on /no-kyc-vps, the top-up flow on /pay-with.

Installing Xray on the VPS with the 3x-ui panel

You can run Xray-core from its own config.json, and if you are comfortable there, do. For most people 3x-ui is the better call: it generates the key pair, builds the client links and QR codes, manages users, and installs Xray as a systemd unit.

1. 1

   Harden first, not last

   apt update && apt full-upgrade -y, create a sudo user, install your SSH key, then set PasswordAuthentication no and PermitRootLogin no — before anything listens on 443.

2. 2

   Install the panel

   As root: bash <(curl -Ls https://raw.githubusercontent.com/MHSanaei/3x-ui/master/install.sh). It fetches Xray-core, registers a systemd service, and prompts for credentials, a port and a URL path. Accept the random ones it offers — scanners look for the classic 54321 on a bare root.

3. 3

   Reach the panel over SSH

   Forward it instead of exposing it: ssh -L 2053:127.0.0.1:PANELPORT to the server, then open 127.0.0.1:2053 locally. The panel never needs an inbound connection.

4. 4

   Create the inbound

   Inbounds, Add Inbound: protocol VLESS, port 443, Security set to Reality. Leave the transport on raw TCP — with the Vision flow it is fastest and least distinctive.

Generating the Reality key pair and picking a camouflage domain

Reality rests on two choices: an x25519 key pair and the site you imitate. The panel generates the pair with one click; on bare Xray the command is xray x25519. The private key never leaves the server, the public key goes into every client link with a short ID. The camouflage target — Dest and SNI in the panel — is what gets people blocked.

• It must support TLS 1.3 with X25519, and ideally HTTP/2. Reality cannot borrow a handshake it cannot speak.
• It must not be blocked where your users are — imitating a site your own censor filters defeats the exercise.
• It should be plausibly close to your server. A box in Amsterdam imitating a name that only resolves to Asian datacenters is an anomaly.
• Prefer something ordinary, and recheck it monthly. Forum lists of "recommended dest" get sampled by censors precisely because they circulate.

Building the client link and connecting your devices

The panel produces a vless:// URI and a QR code per client. The parameters that matter are the public key (pbk), the short ID (sid), the SNI, the uTLS fingerprint (fp, where chrome is a safe default) and the flow, which is xtls-rprx-vision on a TCP inbound.

Locking down the panel so it is not the weak point

A correct Reality inbound is a hard target. A panel on a predictable port behind a reused password is not, and it holds every key on the machine. Most compromised Xray servers are lost through the panel, not the protocol.

• Keep the panel on loopback, reached over an SSH tunnel. If it must be public: random high port, long random path, real certificate.
• Replace the installer's credentials with a passphrase you have not used anywhere else.
• Run a default-deny firewall: 443/tcp and your SSH port, nothing else. The full checklist is on /guides.
• Give every device its own client entry rather than one shared UUID, so you can revoke one alone.
• Update Xray-core and the panel regularly, and snapshot once it works.

Verifying the camouflage, and staying unblocked

Do not assume the disguise holds. Three checks will tell you.

• Ask openssl for the camouflage name: openssl s_client -connect YOUR.SERVER.IP:443 -servername your-chosen-domain.example. You should get that site's real certificate chain; a self-signed one or an error means Reality is not working.
• Visit the bare IP over HTTPS in a browser. A stranger should land on something unremarkable, never a panel login.
• On the server, ss -tulpn should show xray on 443 and nothing unexpected.

Reality is ahead today, which is a statement about now rather than forever. When blocking arrives it usually comes from somewhere other than protocol detection: IP reputation, an ASN-wide block, or the observation that one line moves a lot of data to one host.

• Keep a second protocol installed and idle — a WireGuard endpoint on a UDP port costs nothing and is your instant fallback.
• Keep the config private. Endpoints shared into public groups get collected and blocked; that is how most die.
• If the IP is blocked, rebuild rather than argue with it. /cheapest-no-kyc-vps keeps a spare region cheap.
• Availability and visibility are separate problems: /ddos-protection keeps the box reachable, Reality keeps it uninteresting.

Xray, WireGuard, Shadowsocks or a Tor bridge

Reality is the right default under aggressive filtering, but each alternative still wins somewhere. Many people run two: one 1 GB instance carries a Reality inbound on 443 and a WireGuard endpoint on UDP without strain.