Skip to main content

Configuration guide

VLESS with REALITY: fields, flow and safe configuration

REALITY is a security layer used by some Xray VLESS deployments; it is not a separate VPN protocol. The VLESS identity, transport and REALITY handshake fields must all describe the same server.

Technical review: 2026-09-03 · PublicVPNList Editorial Team

What the REALITY layer changes

A normal TLS profile validates a certificate chain for its server name. REALITY uses an Xray-specific authenticated handshake and a server public key while presenting traffic in a TLS-like form. It does not turn an unknown public endpoint into a trusted operator, and it does not replace VLESS routing or client TUN mode.

Fields that must agree

The address and port select the endpoint; UUID authenticates VLESS; security must be reality; public key, short ID and fingerprint drive the REALITY handshake; SNI/serverName must be one accepted by the server. The flow value, commonly xtls-rprx-vision, must be supported at both ends. Copying only the UUID and host is incomplete.

Transport compatibility

REALITY is commonly used with a raw TCP transport. WebSocket, gRPC and XHTTP are separate transport choices and client support differs. Do not silently substitute a transport because two profiles share the same host.

Decision reference

Decision pointWhat to verify
What the REALITY layer changesValidate the URI locally and keep allowInsecure disabled.
Fields that must agreeConfirm public key, short ID, fingerprint, SNI and flow.
Transport compatibilityUse a current Xray-compatible client.

Practical checklist

  1. Validate the URI locally and keep allowInsecure disabled.
  2. Confirm public key, short ID, fingerprint, SNI and flow.
  3. Use a current Xray-compatible client.
  4. After connection, compare public IP, IPv6, DNS and WebRTC results.

Limitations

  • A structurally valid link may point to an offline server.
  • Active probing resistance is not anonymity or operator trust.
  • Client implementations and accepted fingerprints change over time.

Privacy and interpretation

A successful configuration or connectivity result proves only the tested technical behavior at that time. It does not prove a no-logging policy, legal status, operator identity or safety for sensitive accounts. Public profiles should be used for low-risk testing with end-to-end HTTPS.

Technical source: XTLS REALITY project.

Continue with a relevant check

Frequently asked questions

What should I verify first for “VLESS with REALITY: fields, flow and safe configuration”?
Validate the URI locally and keep allowInsecure disabled.
What is the main limitation of this configuration guide?
A structurally valid link may point to an offline server.
Where is the underlying behavior for this page documented?
Use the linked XTLS REALITY project as the primary technical reference, then confirm fields against the client version you run.