vitalygashkov/rucens/vless-vps-setup

Configure Xray VLESS REALITY

Set up a VLESS REALITY server that listens on TCP 443 and produce an importable vless:// URI. The expected clients are Karing, Happ, or another client with REALITY, XTLS Vision, and TUN support.

Keep the server setup generic. Full-tunnel mode and bypass rules for Russian sites belong in the client. Do not add country-based routing to Xray unless the user asks for it.

Commands assume a Linux distribution supported by the official Xray installer, systemd, root privileges, and Bash. Firewall commands are conditional examples. This template listens over IPv4; client IPv6 routing must be configured separately. Stop on failed installation or configuration commands.

Operating rules

• Work only on the VPS the user authorized. An existing setup request covers the necessary installation steps; do not ask again for the same authorization.
• Start with read-only checks. State which live services, ports, firewall rules, and configuration files the installation will touch.
• Do not weaken SSH, replace the firewall, remove packages, or disturb another VPN.
• Back up an existing Xray configuration before replacing it. If TCP 443 is occupied, identify the service and resolve the port choice before installation. Do not stop nginx, Caddy, or an existing inbound to free it.
• Treat the UUID, REALITY private key, client password/public key, short ID, SSH credentials, and complete client URI as secrets. Do not paste them into ordinary logs or the final narrative.
• Prefer one UUID and short ID per device. One credential can work on several devices at once, but separate credentials make revocation and diagnosis much easier.
• Never declare success based only on an open port. Validate the config, fallback behavior, and one authenticated client connection.

Required inputs

Collect or infer these values before changing the server:

• SSH host, user, and authentication method
• public IPv4 address of the VPS
• Linux distribution and architecture
• client labels, for example phone and tablet
• whether TCP 443 is free and reachable through both the OS firewall and provider firewall
• chosen REALITY target and SNI

A domain owned by the user is not required for REALITY.

Assume the user's clients and home network are suitable for this setup. Do not ask for the Keenetic/router model, firmware version, or LAN subnet as prerequisites, including when VLESS is installed alongside AmneziaWG. The user is responsible for reporting compatibility limitations or unusual LAN addressing. Revisit these details only if the user reports a relevant limitation or troubleshooting reveals a concrete conflict.

Preflight

Run read-only checks first:

uname -a
cat /etc/os-release
ip -br address
ip route
ss -lntup
timedatectl status
systemctl --failed --no-pager
systemctl list-unit-files | grep -E 'xray|v2ray' || true
command -v ufw >/dev/null && ufw status verbose || true
command -v nft >/dev/null && nft list ruleset || true
df -h /
free -h

Confirm that the server has working outbound DNS, TCP 443 access, correct time, and at least a few hundred MiB of free memory. Xray itself is light, but a starved VPS is a poor place to diagnose network problems.

If another VPN is present, keep it. VLESS on TCP 443 can coexist with WireGuard or AmneziaWG on a UDP port. Check the actual listeners rather than assuming there is no conflict.

Select and validate the REALITY target

Do not choose a random famous website. Failed REALITY authentication is forwarded to the configured target. A bad target can make the VPS useful as an unwanted forwarding node or create an obvious mismatch between the VPS location and the borrowed TLS endpoint.

Prefer a stable HTTPS endpoint that:

• is reachable directly from the VPS;
• supports TLS 1.3;
• accepts the selected SNI and returns a certificate whose SAN covers it;
• behaves consistently with and without SNI;
• is not an arbitrary free CDN endpoint;
• is geographically and operationally plausible for the VPS;
• has a certificate chain large enough for the REALITY features in use.

The official Xray guidance prefers a target in the same ASN where practical. Do not add fallback rate limiting by reflex. Xray documents that rate limiting can itself become a fingerprint. Consider it only after reviewing the current REALITY documentation and the abuse risk of the selected target.

Select the target for this VPS and probe it immediately before configuring REALITY. Replace these placeholders with the chosen hostnames:

target_host='<TARGET_HOST>'
server_name='<SERVER_NAME>'
target_ip=$(getent ahostsv4 "$target_host" | awk 'NR == 1 { print $1 }')
test -n "$target_ip" || exit 1
 
openssl s_client -connect "$target_ip:443" -tls1_3 \
  -servername "$server_name" -verify_hostname "$server_name" \
  -verify_return_error </dev/null
 
openssl s_client -connect "$target_ip:443" -tls1_3 \
  -noservername -verify_hostname "$server_name" \
  -verify_return_error </dev/null

Check each probe's exit status and negotiated TLS details. After Xray is available, also run xray tls ping -ip "$target_ip" "$server_name". Reject a target with certificate failures, unstable TLS behavior, or forwarding-abuse concerns. Record the chosen target and SNI.

Install or reuse Xray

If Xray is already installed, inspect xray version and systemctl cat xray first. Reuse a compatible installation. Adding an inbound does not require upgrading the binary or replacing the service unit. Preserve existing inbounds, outbounds, and routing; give the new inbound a unique tag and route it to the intended outbound. Upgrade only when required and authorized, with a rollback plan for both binary and configuration.

For a fresh installation, select a stable version from the official releases and record it. Download the official installer at a reviewed commit, inspect it, then run the selected version's installation. The installer can start services itself, so do not use this path on an existing installation.

xray_version='<SELECTED_VERSION>'
installer_commit='<REVIEWED_INSTALLER_COMMIT>'
install_script=$(mktemp)
curl --proto '=https' --proto-redir '=https' -fL --retry 5 \
  "https://raw.githubusercontent.com/XTLS/Xray-install/$installer_commit/install-release.sh" \
  -o "$install_script"

After a successful download and source inspection:

bash "$install_script" install --version "$xray_version"
rm -f -- "$install_script"
xray version
systemctl cat xray

Confirm the installed version. Follow documentation or source for that release when fields differ, including users/clients and target/dest. Validate with the installed binary, then prove authentication with a real client; JSON validation alone does not establish compatibility.

Generate credentials

Generate a distinct UUID and random 8-byte short ID for each device. For a new REALITY inbound, generate a server key pair. Capture output without logging it:

set +x
umask 077
client_uuid=$(xray uuid)
short_id=$(openssl rand -hex 8)
reality_keys=$(xray x25519)

Parse the installed version's output in the private shell session, without printing it into tool output. PrivateKey goes into server privateKey; Password, or PublicKey in older versions, goes into client URI pbk. Do not substitute a Hash32 value. Check the release's source if labels differ. Reuse the existing server key pair when adding users to an inbound.

Write configuration and URI files without exposing their contents in logs. Afterward, unset client_uuid, short_id, reality_keys, and any variables holding parsed keys. Short IDs must contain an even number of hexadecimal characters, at most 16.

Write the server configuration

Inspect the actual service command and configuration path first. The official installer normally uses /usr/local/etc/xray/config.json. Before editing an existing file:

config=/usr/local/etc/xray/config.json
backup=$(mktemp "${config}.bak.XXXXXX")
cp -p -- "$config" "$backup"
chmod 600 "$backup"
systemctl show xray -p User -p Group -p ExecStart

Keep the backup protected and retain its path. Fill every placeholder. The full template below is for a fresh server; merge only the needed inbound and routing changes into an existing configuration.

The template below follows the current Xray documentation. If the installed release rejects users, consult the matching release documentation and use clients only when that release expects it.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "vless-reality-in",
      "listen": "0.0.0.0",
      "port": 443,
      "protocol": "vless",
      "settings": {
        "users": [
          {
            "id": "<CLIENT_UUID>",
            "email": "<CLIENT_LABEL>",
            "flow": "xtls-rprx-vision"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "show": false,
          "target": "<TARGET_HOST>:443",
          "xver": 0,
          "serverNames": [
            "<SERVER_NAME>"
          ],
          "privateKey": "<REALITY_PRIVATE_KEY>",
          "shortIds": [
            "<SHORT_ID>"
          ]
        }
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ]
}

For more devices, add one entry under users and preferably one short ID per device. Give each entry a useful label. Do not log browsing destinations at info level longer than needed for commissioning.

Create the file under umask 077. Use root ownership and 0600 for a root service, or 0640 with an appropriate restricted group for a non-root service. Resolve an omitted service Group from the user's primary group. Verify that the actual service account can read the file and traverse its parent directories.

Validate before restart

Use the service's actual configuration path or configuration-directory arguments throughout. Do not restart Xray until the complete configuration passes validation:

xray run -test -config /usr/local/etc/xray/config.json

If validation fails, fix the named field. Do not repeatedly restart a broken service.

When the test succeeds:

systemctl enable xray
systemctl restart xray
systemctl --no-pager --full status xray
ss -ltnp '( sport = :443 )'
journalctl -u xray -n 100 --no-pager

Open only TCP 443 in the active firewall. For already active UFW:

ufw allow 443/tcp
ufw status verbose

Preserve SSH access and existing rules. For another firewall, add a persistent allow rule in its existing input chain, accounting for earlier drops and chain priorities. Do not enable a disabled firewall incidentally. Also check the provider's external firewall or security group.

Produce the client URI

Build one URI per client:

vless://<CLIENT_UUID>@<SERVER_IP>:443?encryption=none&flow=xtls-rprx-vision&security=reality&sni=<SERVER_NAME>&fp=chrome&pbk=<REALITY_CLIENT_PASSWORD_OR_PUBLIC_KEY>&sid=<SHORT_ID>&type=tcp#<PROFILE_NAME>

Use the selected SNI for <SERVER_NAME> and the VPS public IP for <SERVER_IP>. Percent-encode the profile name and any query values that require URI escaping.

Give the user the URI in a file with permissions 0600 or another channel they requested. Remove temporary credential files created during setup after confirming delivery. In the ordinary response, state where it was saved without repeating it. A QR code is optional and should be generated only if the user wants one.

Client setup

In Karing or Happ:

1. Import the vless:// URI.
2. Select the imported profile.
3. Enable TUN or VPN mode for a full tunnel.
4. Put Russian-site bypass lists and other split-routing rules in the client.
5. Keep DNS inside the client tunnel unless the chosen client policy intentionally sends bypassed domains to a local resolver.