How To Configure VLESS Reality In V2RayNG: Full Setup Guide

A VLESS Reality profile in v2rayNG can look intimidating because several fields are related to the server certificate, transport, and Xray-specific handshake rather than to ordinary proxy settings. A successful setup depends on copying each value into the correct field, using a compatible Xray core, and confirming that the Android VPN service is actually routing application traffic through the profile.

This guide explains how to add the profile manually on Android and how to recognize the same values when they arrive through a subscription. It uses the current v2rayNG 1.10.x interface as a reference; labels can move slightly between releases, but the required VLESS and Reality parameters remain substantially the same.

Understand What VLESS Reality Requires

VLESS is the user-authentication protocol, while Reality is the TLS-like security layer used to make the connection resemble a normal TLS session to a selected destination. The transport is usually TCP, and the Xray core uses the Reality parameters to complete the handshake. These layers should not be mixed together: the UUID identifies the client, the port identifies the server listener, and the Reality values control how the secure session is established.

Unlike VMess, VLESS normally uses encryption: none at the protocol level. This does not mean that the connection is unencrypted. With Reality enabled, the transport handshake and subsequent traffic are protected by the Reality security layer. Selecting an unrelated encryption value, such as an old VMess option, can prevent the profile from working even when the server address and UUID are correct.

Do not invent any of these values. A hostname that resolves correctly can still fail because its port, SNI, public key, or short ID belongs to a different node. Likewise, changing the server name to the address you happen to see in a browser is not a valid repair. Reality uses a specific server name selected by the administrator, and that name must match the profile.

Check Compatibility Before Adding the Profile

Before editing fields, confirm that the provider actually supplied a VLESS Reality profile rather than a VLESS WebSocket, VLESS TCP TLS, or VMess profile. The difference is visible in a share link: a VLESS Reality link commonly contains parameters such as security=reality, pbk=, sid=, sni=, and often flow=xtls-rprx-vision. A link without those values may use another transport and should not be converted by guesswork.

Use an up-to-date v2rayNG release with an Xray core that supports VLESS Reality and Vision flow. In v2rayNG, open the side menu and check the core or version information before troubleshooting. If the application offers a core selector, choose Xray rather than an older V2Ray core for this profile. Menu names differ between builds, but a profile requiring Reality should never be tested with a core that lacks Reality support.

Add VLESS Reality Manually in v2rayNG

Manual entry is useful when you have one node, need to inspect every parameter, or want to understand what a subscription importer is doing. Keep the original configuration visible while entering it. A single missing character in the UUID, public key, or short ID is enough to produce a generic connection failure.

1. Open profile editor

   Launch v2rayNG, tap the add button, and choose “Manual Settings” or “Create manually.” Select VLESS as the protocol instead of VMess or Trojan.

2. Enter server data

   Fill in the provider’s address and port. Paste the UUID into the user ID field, set encryption to none, and leave the email field empty unless the provider specifically uses it.

3. Set TCP transport

   Choose TCP as the network or transport. If the provider says Vision, set Flow to xtls-rprx-vision; do not add WebSocket path or HTTP host values to a TCP Reality profile.

4. Enable Reality

   Open the security settings, choose Reality, and enter the server name, public key, short ID, and fingerprint supplied by the provider.

5. Save and connect

   Save the profile, select it in the main list, tap the VPN or connect button, and approve Android’s VPN request. Wait for the connection indicator and then test an external website.

In the Reality section, the Server Name field is the SNI value. It is often a normal public hostname and may not be identical to the node address. The Public Key is usually shown as pbk in a share link. The Short ID is usually shown as sid; if the provider gives multiple IDs, use the one assigned to this node. The Fingerprint controls the client hello fingerprint, and chrome is a common provider-selected value.

Handle Optional Reality Fields Carefully

Some v2rayNG builds expose fields such as SpiderX, Mux, packet encoding, or a custom fingerprint. SpiderX is an optional HTTP path used during the Reality handshake and is often left as / or left blank according to the provider’s link. Do not insert a random path. Mux is unrelated to the Reality handshake and should remain at the provider’s recommended default while you establish a baseline connection.

If the share link includes query parameters, map them rather than translating them literally into unrelated controls. For example, sni maps to Server Name, fp maps to Fingerprint, pbk maps to Public Key, and sid maps to Short ID. The type=tcp parameter indicates the network, while security=reality selects Reality. Preserve URL decoding when a value contains encoded characters.

Import a Subscription or Share Link

When a provider supplies a subscription, use v2rayNG’s subscription group instead of manually rebuilding every node. Open the side menu, choose “Subscription settings,” add a subscription group, paste the complete URL, save it, and use “Update subscriptions.” After the update finishes, search the node list for a VLESS Reality entry. The imported profile should display VLESS, TCP, Reality, and the expected server name or address.

A share link can usually be imported through the Android share sheet or by copying it and choosing the add-from-clipboard option in v2rayNG. Review the resulting profile before connecting. Importing is not the same as validation: a truncated URL may create a profile with empty fields, and a provider may have changed the server key while leaving an old link in a saved message.

Do not paste a subscription URL into the server address field. A subscription URL is a document containing one or more profiles, whereas the address field accepts only the remote host for one node. Also avoid changing all imported nodes at once until one profile has been tested. If the entire group fails, the problem may be an expired subscription, an unreachable update URL, or a provider-side configuration change.

Connect and Verify the Android Route

After selecting the profile, tap the main connect button and approve the VPN permission request. v2rayNG commonly uses Android’s VPN interface to capture traffic, so the Android status bar should show a VPN indicator while the profile is active. The profile’s connected state alone is not sufficient: check the v2rayNG log, open a known external site, and confirm that the request is not being handled by a direct route.

• Profile check: Confirm the selected entry is the intended VLESS Reality node, not an older VMess profile.
• VPN check: Confirm Android shows the VPN indicator and that another VPN application is not competing for the same service.
• Log check: Look for a successful outbound connection rather than repeated timeout, handshake, or authentication messages.
• Traffic check: Test both a browser and a second application if per-app routing is enabled.
• DNS check: If domain names fail while direct IP tests work, inspect DNS settings and routing instead of immediately replacing the Reality key.

For a clean baseline, temporarily use the default routing mode and test one browser request. Once the profile works, enable per-app proxying or custom rules and test again. Excluding the browser, selecting “bypass” for all applications, or enabling a blocklist can make a healthy node appear broken. Record which change was made before each test so that a later failure has a clear cause.

Troubleshoot Common VLESS Reality Failures

Most failures can be narrowed down by comparing the error stage. A timeout before any handshake suggests address, port, firewall, or network reachability. A TLS or Reality handshake error suggests SNI, public key, short ID, fingerprint, clock, or core compatibility. An authentication error points more directly to the UUID or server-side client record. Do not change several categories at the same time, because that removes the evidence needed to identify the mistake.

Perform a Field-by-Field Recheck

Start with the address and port, then check the UUID, protocol, encryption, flow, network, security, SNI, public key, short ID, and fingerprint in that order. This sequence follows the approximate path from socket creation to authentication and Reality negotiation. If the provider uses a domain address, verify that it resolves to the expected server, but remember that DNS resolution alone does not prove that the selected TCP port is reachable.

Pay special attention to the difference between Address and Server Name. The address is where v2rayNG opens the TCP connection. The server name is the SNI hostname presented during the Reality handshake. They may be different by design. Replacing the server name with the address is one of the most common manual configuration errors.

Finally, delete duplicate test profiles that use the same address but different keys. v2rayNG can keep several similar entries, and selecting an old profile from the list can make a corrected profile appear ineffective. Rename a working profile with a short date or provider label, such as “Reality TCP test,” without exposing the UUID or private server details in a shared screenshot.

Final Configuration Checklist

A working VLESS Reality profile has consistent values across the protocol, transport, and Android routing layers. The protocol is VLESS, encryption is normally none, and the UUID is complete. The transport matches the provider, commonly TCP with xtls-rprx-vision. Security is Reality, and the SNI, public key, short ID, and fingerprint are copied from the same server profile rather than assembled from different links.

1. Check the Android date, time zone, and network connection.
2. Use an Xray-capable v2rayNG core that supports the supplied Reality profile.
3. Confirm address and port before changing any cryptographic field.
4. Copy the UUID without spaces or line breaks.
5. Match TCP, flow, Reality, SNI, public key, short ID, and fingerprint exactly.
6. Connect through Android VPN mode and confirm the VPN indicator.
7. Test one application in the default route before enabling custom rules.
8. Use logs to identify the failing stage instead of changing every field randomly.

Once the first profile is verified, duplicate it only when the provider instructs you to change a specific value, such as the server address or port. Keeping a known-good baseline makes future subscription or routing problems much easier to isolate.