VLESS Reality on a VPS Without a Domain or Certificate

Earlier stealth transports like VLESS+TLS or Trojan required you to own a domain, point it at your VPS, and obtain a real TLS certificate (usually from Let's Encrypt). That domain became a permanent paper trail tied to your IP, and the certificate it served could itself be fingerprinted: censors enumerate certificates, watch for self-signed or fresh Let's Encrypt certs on residential-looking IPs, and flag the anomaly. The whole approach leaks an identifier you had to register.

Reality removes that entire layer. When a censorship system probes your server's port 443, your Xray (or sing-box) server does not present a certificate of its own. For any TLS ClientHello that is not from one of your authenticated clients, it transparently forwards the handshake to a real, popular website (the dest) and relays that site's genuine certificate chain back to the prober. The prober therefore sees the certificate of, say, a major foreign CDN or vendor site, served from a valid TLS 1.3 handshake. There is no self-signed cert, no oddly fresh certificate, and no domain in your name to correlate. You did not buy anything and you registered nothing.

Authenticated clients are distinguished cryptographically. The server holds an X25519 key pair; only a client carrying the matching public key, plus a valid short ID, completes a real session and gets tunneled. Everyone else, including the censor's active probe, is invisibly handed off to the borrowed site and sees exactly what they would see if they had connected to that site directly. This is the core property: there is no observable difference between your server and a legitimate fronting of the dest, so there is nothing static to block.

The practical payoff for a VPS operator is large. You can stand up a working, hard-to-detect endpoint on a fresh IP in minutes, with no DNS records, no ACME challenge, and no certificate renewal cron job to maintain. On an offshore VPS this also means the endpoint carries no domain-based attribution at all.

The single most important configuration choice in Reality is the borrowed target, set by two linked fields: dest (the real host:port your server forwards unauthenticated handshakes to) and serverNames (the SNI values your clients are allowed to send, which must be names that the dest legitimately serves). Pick these badly and you reintroduce the very fingerprint Reality is meant to erase.

The criteria for a good dest are concrete:

• Supports TLS 1.3 and HTTP/2. Reality only mimics a modern TLS 1.3 handshake. If the borrowed site falls back to TLS 1.2 or lacks h2, the mismatch is detectable. Verify before committing.
• Is foreign relative to your users and unlikely to be blocked. The dest should be a site the censor has no reason to block and that is reachable from inside the censored network. If the dest itself gets blocked, your endpoint goes down with it.
• Is not a giant CDN-fronted property such as Google, Apple or Cloudflare's own marketing sites. These resolve to local CDN edge nodes and CDN-specific behavior; a connection to your VPS's IP claiming to be that site is geographically and topologically inconsistent, which probing can catch. Prefer a single-origin site hosted in a region plausibly near your VPS.
• Is stable and not a redirector. Sites that 301/302 to another hostname break the illusion. The dest should serve real content directly on the SNI you use.

A strong practical pattern is to choose a dest hosted in the same country or region as your VPS, so the apparent origin is geographically consistent with your server's IP. Tools such as RealiTLScanner can scan IP ranges near your VPS for hosts that serve TLS 1.3 + h2 and make suitable, plausible neighbors. The serverNames list must contain only names the dest actually presents a valid certificate for; sending an SNI the dest does not serve produces a certificate mismatch a prober can detect. Reality does not support wildcards in serverNames, so list exact hostnames.

Finally, keep the dest and serverNames in agreement. The classic mistake is pointing dest at one site while letting clients advertise an SNI that site does not serve. To a passive observer that is an immediate inconsistency. Treat the two fields as one decision.

Any AnubizHost VPS with 1 vCPU and 512 MB RAM is enough for a personal Reality endpoint; the Romania plan from $19.99/mo handles a household comfortably. After provisioning, SSH in as root and update the system (apt update && apt upgrade -y on Debian/Ubuntu). Reality is a transport implemented by Xray-core and by sing-box; the steps below use Xray.

Install Xray with the official script:

bash -c "$(curl -fsSL https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install

Generate the cryptographic material Reality needs. The X25519 key pair authenticates clients, and the short ID is an additional shared marker:

xray x25519
# returns a Private key (server) and Public key (client)
openssl rand -hex 8   # an example shortId, 0-16 hex chars

Then write an inbound that listens on 443, sets security: "reality", and fills in dest, serverNames, the server privateKey, and one or more shortIds. Use the XTLS Vision flow (flow: "xtls-rprx-vision") on the client to defeat TLS-in-TLS traffic-shape analysis. A minimal inbound looks like this:

{
  "listen": "0.0.0.0",
  "port": 443,
  "protocol": "vless",
  "settings": {
    "clients": [{ "id": "UUID-HERE", "flow": "xtls-rprx-vision" }],
    "decryption": "none"
  },
  "streamSettings": {
    "network": "tcp",
    "security": "reality",
    "realitySettings": {
      "dest": "your-chosen-site.example:443",
      "serverNames": ["your-chosen-site.example"],
      "privateKey": "SERVER-PRIVATE-KEY",
      "shortIds": ["", "0123456789abcdef"]
    }
  }
}

Restart Xray (systemctl restart xray) and confirm it is listening on 443. On the client, configure VLESS with the matching UUID, the server's public key, one of the shortIds, the SNI set to your chosen serverName, and flow: xtls-rprx-vision. Most client apps (v2rayN, NekoBox, sing-box, Hiddify) accept these fields directly or via a vless://...&security=reality&pbk=...&sid=...&sni=... share link. There is no certificate to install on either side.

Reality's stealth holds only if the borrowed handshake is convincing and your server reveals nothing extra. A few hardening rules matter in practice:

• Run only Reality on the IP's port 443. If the same VPS also serves a self-signed panel, an oddly fresh certificate, or an open admin port, a censor scanning the IP finds the anomaly your dest was supposed to hide. Keep management on a separate, firewalled, non-standard port and never expose a web panel on 443.
• Include the empty short ID alongside a random one. Listing "" in shortIds lets compatible clients connect without a short ID while still allowing keyed ones; mismatched short IDs are silently forwarded to the dest, which is exactly the fallback you want against probes. The short ID is optional but cheap defense in depth.
• Use XTLS Vision flow. Without it, a tunneled TLS session inside the outer TLS produces a recognizable "TLS in TLS" packet-size and timing pattern that some DPI systems flag. Vision reshapes that traffic so the inner session is not distinguishable by shape.
• Rotate the dest if it degrades. If your chosen site starts redirecting, drops TLS 1.3, or gets blocked locally, your endpoint's cover is gone. Periodically re-verify that the dest still serves TLS 1.3 + h2 directly, and keep a spare candidate ready.
• Lock down everything else. Key-only SSH on a non-standard port, fail2ban, default-deny inbound firewall, and automatic security updates. The goal is that the only thing an external scanner ever sees on your VPS is a clean, real-looking TLS 1.3 handshake.

Reality is currently one of the most robust transports against both passive DPI and active probing precisely because, done correctly, there is no static artifact to match. The discipline is in the details: a consistent dest/serverNames pair, Vision flow, and an otherwise silent server. For users who need this against aggressive nation-state filtering, hosting on a clean offshore IP with full root access removes the two remaining weak points, a shared or flagged IP and a provider that might cooperate with disclosure requests. AnubizHost dedicated and VPS plans give you that clean IP and root control. For higher throughput or many concurrent users, an offshore dedicated server provides the headroom; for a single private endpoint, an offshore VPS is the right fit.