This VLESS Reality server setup uses Xray-core v26.3.27 on both server and client, with Vision over the raw transport and one local SOCKS entry. The server example targets a dedicated Ubuntu 24.04 LTS host. It teaches configuration and reader acceptance checks; no complete end-to-end author deployment was performed.

Key Takeaways

Pin the core and match its fields; rolling documentation can describe different syntax.

VLESS identity, REALITY key pairing, and Vision flow are separate settings.

A loopback SOCKS listener covers explicitly configured applications, not the whole device.

Rejection, revocation, restart, and recovery require separate checks.

Use an authorized TLS target and preserve an independent management path.

When does a VLESS Reality server setup suit your task?

Start with the self-hosting responsibility guide. This route fits readers who need to operate an Xray core and control its authorization. For a routed IP gateway instead, use the Ubuntu WireGuard deployment; neither tutorial is a prerequisite for the other. VLESS, REALITY, and Vision roles explain the layers without duplicating deployment.

If the goal is public access for real applications without core administration, AethoVPN provides a terminal-service alternative. On Windows, install the official .exe, continue using an email verification code, choose a currently available location in the App, and connect. Its documented global mode sends all applications' traffic through the encrypted VPN path; with global mode off, traffic to local-region websites bypasses its relay.

Check the visible exit IP, then separately repeat the original application task and browser task. One working task does not prove every process or destination works. Use a separate controlled terminal so the experiment does not alter everyday network settings.

This method does not claim VLESS import, REALITY/Vision support, or Xray server management. New users receive one three-day Pro trial, which account deletion does not reset. Try the supported-terminal route.

Prepare an authorized host and a fixed version

Use a dedicated, otherwise unused Ubuntu 24.04 LTS host and an independent authorized client. Reserve TCP 18443 and local client TCP 10808.

Inventory ss -lntup, existing services, routes, firewall ownership, configuration paths, and the recovery console. Establish a new management session before changing policy. If Xray or its installer paths already exist, stop: this fresh-install procedure must not overwrite a shared instance.

The example version is the official release tag v26.3.27.［1］ Record the binary architecture and xray version on both ends. A release pin describes this configuration, not permanent permission to ignore security fixes. Review release notes before an update and retain a compatible binary/configuration pair for rollback.

Choose a TLS 1.3 target you own or are expressly authorized to use. It must be reachable from the server, have a valid certificate for the chosen TLS_NAME, and satisfy REALITY's documented target requirements.［2］ TLS_TARGET:443 and TLS_NAME refer to that target; they are not necessarily your proxy's public endpoint. If you cannot provide this authorized target, stop before exposure rather than borrowing a public site's name or disabling checks.

The diagram shows an explicit application path. A server configuration does not automatically capture another application's traffic or the operating system's DNS. TUN and system-proxy boundaries explain the additional capture decisions.

Step 1: Review the official installer and install the core

Retrieve the official installation project's script to a file, inspect it, and run its shell syntax check before executing it.［3］ These are instructions for the reader's dedicated host:

curl --fail --location --proto '=https' --proto-redir '=https' \
  --output install-release.sh \
  https://raw.githubusercontent.com/XTLS/Xray-install/main/install-release.sh
less install-release.sh
bash -n install-release.sh
sudo adduser --system --group --no-create-home xray-lab
sudo bash install-release.sh install --version v26.3.27 --install-user xray-lab
sudo systemctl disable --now xray.service
sudo systemctl is-enabled xray.service
/usr/local/bin/xray version
sudo systemctl cat xray.service

Review all downloads, file writes, service/user changes, and removal behavior. The installer rolls independently of the core tag; retain the reviewed script privately and record its upstream revision. Syntax checking does not establish trust.

Fresh installation starts and enables xray.service; disable --now stops it and removes boot enablement. Expect is-enabled to report disabled; otherwise stop before configuration. Run the privileged installer only on the dedicated host after understanding its changes.

Verify that the unit runs as xray-lab and loads /usr/local/etc/xray/config.json using /usr/local/bin/xray. Do not continue with a root runtime or an unexpected configuration directory. Limit accessible files and destinations; no panel is required. The high test port avoids a need to bind privileged ports, but the installed unit's capability settings still require review.

Step 2: Pair the Xray REALITY configuration and XTLS Vision setup

Generate a fresh UUID with /usr/local/bin/xray uuid and an X25519 pair with /usr/local/bin/xray x25519. Generate the short ID using openssl rand -hex 8.

Run them in a private terminal; do not paste outputs into public tickets or screenshots. The server keeps the private key; copy the corresponding public value to the client's password field. Keep generated values in private configuration rather than shell arguments.

Parameter	Server location	Client match
VLESS UUID	`clients[].id`	Outbound `settings.id`
Vision	Explicit client `flow`	Outbound `flow: xtls-rprx-vision`
REALITY key	`privateKey`	Corresponding public value in `password`
Name	Approved entry in `serverNames`	`serverName`
Short ID	Entry in `shortIds`	`shortId`
Endpoint	Listener address and TCP port	Reachable public address and same port

For this tag, inbound parsing uses clients; the rolling VLESS page may show users. The tagged source also permits inherited inbound flow, but this example makes the per-user Vision value explicit.［4］ Its transport parser accepts raw, and REALITY parsing supports target and client password.［5］

Do not merge fields from a different release. The flow field guide explains compatibility separately.

Create the server's private /usr/local/etc/xray/config.json, replacing every uppercase placeholder. SERVER_LISTEN_IPV4 is an address actually assigned to the server; a provider's public NAT address may not be bindable locally.

{
  "log": {"loglevel": "warning"},
  "inbounds": [{
    "tag": "vless-lab", "listen": "SERVER_LISTEN_IPV4", "port": 18443,
    "protocol": "vless",
    "settings": {
      "clients": [{"id": "CLIENT_UUID", "email": "lab-device", "flow": "xtls-rprx-vision"}],
      "decryption": "none"
    },
    "streamSettings": {
      "network": "raw", "security": "reality",
      "realitySettings": {
        "show": false, "target": "TLS_TARGET:443", "xver": 0,
        "serverNames": ["TLS_NAME"], "privateKey": "SERVER_PRIVATE_KEY",
        "shortIds": ["SHORT_ID"]
      }
    }
  }],
  "outbounds": [{"tag": "direct", "protocol": "freedom"}]
}

Set the directory to root:xray-lab mode 750 and this file to root:xray-lab mode 640, preserving the service's read access without public read permission. The UUID is an authorization credential; decryption:none is VLESS configuration, not permission to remove REALITY. A short ID is not a replacement for the UUID or key pair.

sudo chown root:xray-lab /usr/local/etc/xray
sudo chmod 750 /usr/local/etc/xray
sudo chown root:xray-lab /usr/local/etc/xray/config.json
sudo chmod 640 /usr/local/etc/xray/config.json
sudo -u xray-lab /usr/local/bin/xray run -test -config /usr/local/etc/xray/config.json
sudo systemctl start xray.service
sudo ss -lntp

A successful configuration test checks loading, not authenticated traffic. Open only the chosen TCP port through the existing host firewall manager and provider security group, preferably restricted to the authorized client's public source. Preserve management rules; do not reset the firewall.

The unrestricted freedom outbound can reach destinations the host can reach. Use an isolated host without sensitive internal routes or first implement a reviewed destination ACL; VLESS authentication itself does not limit destinations.

Step 3: Configure one official Xray client

Use the matching official core release on the authorized client. Store this JSON as a private client.json; the example enables only TCP SOCKS traffic and uses a loopback listener.［6］ On a multi-user host, other local users can potentially reach loopback, so use an isolated authorized client or add appropriate local access protection.

{
  "log": {"loglevel": "warning"},
  "inbounds": [{
    "listen": "127.0.0.1", "port": 10808, "protocol": "socks",
    "settings": {"auth": "noauth", "udp": false}
  }],
  "outbounds": [{
    "protocol": "vless",
    "settings": {
      "address": "SERVER_PUBLIC_ENDPOINT", "port": 18443,
      "id": "CLIENT_UUID", "encryption": "none", "flow": "xtls-rprx-vision"
    },
    "streamSettings": {
      "network": "raw", "security": "reality",
      "realitySettings": {
        "serverName": "TLS_NAME", "fingerprint": "chrome",
        "password": "SERVER_PUBLIC_KEY", "shortId": "SHORT_ID"
      }
    }
  }]
}

Replace the public endpoint, UUID, name, public key, and short ID with the paired values. In this tag, the outbound supports the flat address/port/id fields shown here.［4］ Restrict the file to its owner, validate, and launch in a private terminal:

chmod 600 client.json
xray version
xray run -test -config client.json
xray run -config client.json

Leave existing daily clients untouched. Use an explicit request on this controlled client, replacing the authorized hostname and path:

curl --fail --socks5-hostname 127.0.0.1:10808 https://AUTHORIZED_TASK_HOST/task

--socks5-hostname submits the hostname through SOCKS for remote resolution; --socks5 resolves locally.［7］ Check the destination's own request evidence and visible exit for this request. This proves neither device-wide DNS routing nor another application's capture. Direct IPv6, UDP, and TUN behavior are outside this TCP application example.

Step 4: Complete VLESS server verification and recovery

Use disposable credentials you own. Record version, request method, timestamp, expected stage, and observed result without copying secrets. This table supplies expected observations, not fabricated logs.

Check	Method	Expected observation	Failure action
Loaded configuration	Core version, unit path/user, configuration test, listener	Intended tag and file, chosen address/port	Fix installation or permissions first
Authorized forwarding	Explicit SOCKS request to owned/authorized destination	Intended server forwards the task	Compare pairing and outbound path
Capture and DNS	Repeat the exact application method with hostname	Only configured application path and remote name resolution are accepted	Correct application setting; leave wider scope unverified
Wrong UUID	Fresh connection with an unregistered disposable UUID	No authenticated task forwarding	Inspect active client list and restore test baseline
Wrong REALITY pairing	Fresh attempt with deliberately wrong public key or short ID	No authenticated proxy task	Distinguish target fallback from acceptance
Revocation	Remove UUID, restart dedicated instance, retry old UUID	Old access cannot start anew; instance's prior sessions terminate	Check persistent file and service identity
Reboot	Reboot authorized dedicated host; repeat fresh request	Same version/configuration/listener and task behavior	Inspect startup and firewall persistence

REALITY may send unsuccessful authentication traffic to its configured target.［2］ Receiving a response or completing a TCP connection is therefore insufficient. A browser showing that target's content is not evidence that the authorized task traversed VLESS. Never “fix” rejection by removing security checks or allowing unknown users.

Revoke a device and distinguish sessions

Remove its UUID entry from the persistent server file, validate as xray-lab, then run sudo systemctl restart xray.service on this dedicated instance. Restarting interrupts all its existing sessions, not just one device; account for that impact before using the method elsewhere. Retry the removed UUID on a fresh connection, then verify the persistent file and active unit again.

Deleting a subscription alone does not revoke access. Do not restore compromised credentials from a backup.

Before later authorized tests, generate a fresh UUID, add it to the server configuration and replace the client ID. Validate both files, then restart the dedicated server and foreground client. Confirm the new UUID works and the revoked UUID still fails.

After positive and negative checks, run sudo systemctl enable xray.service and confirm sudo systemctl is-enabled xray.service reports enabled. On an authorized reboot, check version, user, path, listener, firewall and target, then repeat the fresh task. Otherwise boot persistence remains unverified.

Failure branches and maintenance

No listener points to configuration, permissions, unit, or port ownership. No accepted REALITY stage points to reachability, approved name/target, key pair, short ID, clock, or version. Accepted authentication without a task response points next to UUID/flow agreement, outbound route, and destination policy.

Use the connection-failure guide, changing one variable at a time. A different VPN succeeding cannot isolate a failure across a different endpoint and protocol.

Review release notes, target certificate/availability, credentials, client compatibility, and necessary log retention. Keep only stage, time, and a redacted internal label when enough; do not collect third-party payloads. Reassess server versus managed-exit responsibility if maintenance no longer serves the original task.

Stop and restore

Stop the foreground client with Ctrl-C and restore only the application's saved proxy settings. On the new server instance, use sudo systemctl disable --now xray.service, then verify the listener is gone and remove the owned cloud/host rules. Remove only files, units, users and resources created by this fresh installation after reviewing the installer's removal behavior; do not apply a purge to a shared host.

Read back the management connection and ordinary task. Preserve necessary private recovery records while retiring usable credentials; host and snapshot billing are separate provider actions. For future upgrades, restore a known compatible binary/configuration pair rather than combining an older binary with newer fields.

Summary

Match the pinned core's identity, REALITY, transport, and Vision fields.
Verify one explicit application path before making broader capture claims.
Prove rejection, session termination, fresh revocation, restart, and baseline recovery independently.

FAQ

Do I need a panel?

No. This procedure uses the official core and a reviewed installer. A panel introduces another persistent configuration owner and needs its own authorization and recovery assessment.

Why must client and server versions match here?

Matching versions bounds the configuration being evaluated. Rolling documentation and other clients can use different field names or defaults; do not infer compatibility from a successful import.

Does a connection capture the whole device?

No. This example has a local TCP SOCKS listener for explicitly configured applications. TUN, device routing, UDP, and wider DNS behavior require separate configurations and checks.

How can I verify revocation?

Remove persistent authorization, restart this dedicated instance to terminate its sessions, then retry the old UUID freshly. Confirm the intended unit and file rather than deleting only the subscription.

What should I inspect after reboot?

Verify the binary tag, unit user, configuration path, listener, firewall and target dependency, then repeat a fresh authorized task. An active service alone does not complete acceptance.

Why can wrong authentication receive a response?

REALITY can forward unsuccessful authentication to its target. A fallback response is distinct from authenticated VLESS forwarding; correlate the intended task with its authorized destination evidence.

When is self-hosting unnecessary?

If you need supported-device public access without core or server control, compare a managed-terminal route. Check its actual task behavior and terms without assuming support for these protocols.

Scope: Prepared from official documentation and tagged source for Xray-core v26.3.27 and a dedicated Ubuntu 24.04 LTS server; no complete end-to-end author test was performed. TCP application traffic only; no performance, country availability, or whole-device protection claim. Follow applicable law and service policy.

Sources:

XTLS, "Xray-core v26.3.27 release": https://github.com/XTLS/Xray-core/releases/tag/v26.3.27
Project X, "REALITY configuration": https://xtls.github.io/en/config/transports/reality.html
XTLS, "Xray-install": https://github.com/XTLS/Xray-install
XTLS, "v26.3.27 VLESS configuration parser": https://github.com/XTLS/Xray-core/blob/v26.3.27/infra/conf/vless.go
XTLS, "v26.3.27 transport configuration parser": https://github.com/XTLS/Xray-core/blob/v26.3.27/infra/conf/transport_internet.go
Project X, "SOCKS inbound": https://xtls.github.io/en/config/inbounds/socks.html
curl, "curl command-line manual": https://curl.se/docs/manpage.html

Sources checked 9 October 2026.

Related Articles:

VLESS Reality Server Setup: Configure Vision and Verify