VLESS Reality Setup in v2rayNG for Android: A Simple Guide

Setting up a VLESS Reality profile in v2rayNG is mostly an exercise in matching fields, not guessing them. The server provider must supply the address, port, UUID, encryption setting, public key, short ID, and server name. v2rayNG then uses those values to create an Xray outbound on Android. If even one security or transport value is different from the server side, the profile may import successfully but fail during the Reality handshake.

This guide follows the current v2rayNG workflow: obtain the complete parameters, open the manual configuration screen, enter VLESS and Reality values, save the profile, start the local VPN service, and verify the result through the connection test and log. The examples use the common VLESS over TCP with Reality arrangement. Exact labels can vary slightly between v2rayNG releases and Android versions, but the field relationships remain the same.

Collect the complete Reality parameters first

Before opening v2rayNG, ask the server provider for a complete share link or a parameter list. A VLESS Reality profile is not defined by the protocol name alone. The address and port identify the remote listener, while the UUID identifies the VLESS user. Reality adds a public key, short ID, server name, and fingerprint to the TLS-like handshake. The transport type and flow value are also important because they determine how the client communicates with the server.

The most common layout is VLESS + TCP + Reality + Vision. In that arrangement, the remote port is often 443, the network is tcp, the security value is reality, and the flow is commonly xtls-rprx-vision. These are common values, not universal defaults. If the provider supplies a different port, flow, network, or security value, use the supplied value instead of copying the example.

There are several similar-looking identifiers in a Reality link, so copy them carefully. The UUID belongs to the VLESS user section. The public key is used by Reality to validate the server’s handshake and is not the same as a private key. The short ID is normally a short hexadecimal string. The server name, often called SNI, is a hostname used during the handshake; it is not automatically the same as the node address. The provider may also give a SpiderX path, which should be entered exactly when present.

Do not change the UUID, public key, short ID, or server name merely because they look unfamiliar. Do not remove Reality security to make an invalid profile “more compatible.” Disabling verification or changing the fingerprint can hide the real mismatch and may reduce the security properties expected by the server. If the values are incomplete, request a fresh share link or a complete configuration from the provider.

Add the profile through the v2rayNG Android menu

v2rayNG can import a VLESS share link, import a QR code, update a subscription, or create a server manually. For a first setup, manual entry is useful because every field is visible. It also makes troubleshooting easier: when a connection fails, you can compare the saved profile with the original provider parameters instead of inspecting an encoded link.

1. Open the server list

   Launch v2rayNG on Android and review the current configuration list. If an old profile is selected, leave it unchanged until the new profile has been saved and tested.

2. Choose manual setup

   Tap the add button in the server list, then choose the VLESS manual configuration option. The exact add icon may appear as a plus sign or in the overflow menu.

3. Enter core fields

   Fill in address, port, UUID, encryption, network, security, and flow. For a typical profile, encryption is none, network is tcp, security is reality, and flow is xtls-rprx-vision only when the server specifies it.

4. Fill Reality fields

   Open the Reality or TLS-related section and enter the public key, short ID, server name, fingerprint, and SpiderX value supplied by the provider. Do not confuse the server name with the address field.

5. Save and activate

   Save the profile, tap its row to select it, then start the v2rayNG VPN service with the main connect button. Approve Android’s VPN permission request if it appears.

For the address field, enter only the hostname or IP address. Do not include https://, a path, or a port suffix if v2rayNG provides separate fields. Enter the remote port as a number, such as 443. In the user section, paste the UUID exactly as supplied, including all hyphens. The VLESS encryption field is normally none; this does not mean that the connection is unencrypted, because Reality provides the relevant transport security layer in this profile design.

Under transport, select TCP when the provider’s link uses TCP. Reality parameters are not interchangeable with WebSocket parameters. Do not enter a WebSocket path, HTTP host, or gRPC service name into a TCP profile unless the provider explicitly describes that transport. Similarly, a VLESS Reality profile using Vision should not be changed to an unrelated flow value simply because another configuration uses it.

In the Reality section, the fingerprint is commonly set to chrome, but the server may require another supported fingerprint. The public key must be the client-facing key from the provider. The short ID may be empty on some server designs, but if a value is supplied, enter it without quotation marks or spaces. The server name should preserve capitalization only if the provider specifically requires it; the hostname itself must otherwise be exact.

After saving, open the profile again and check each field. This second review catches a frequent Android input problem: the keyboard may insert a trailing space when a value is pasted, or a long UUID may be truncated when copied from a messaging application. If a QR code or share link is available, compare the manually saved profile with an imported copy rather than relying on visual memory.

Start the VPN service and verify more than the connection icon

A saved profile is not yet an active proxy. In v2rayNG, select the new server and tap the main connect button. Android will normally display a VPN permission dialog the first time the application starts a local VPN service. Accepting that dialog allows v2rayNG to create the local TUN path, but it does not prove that the remote VLESS Reality handshake succeeded.

Use a staged test. First check whether the service remains connected for at least 20 to 30 seconds without immediately stopping. Then open the v2rayNG log view and look for the core startup result and the first outbound connection message. Finally, load a simple HTTPS page or use a network test that shows the resulting public address. A VPN key in the Android status bar only confirms that Android has an active VPN interface; it does not confirm that the selected server is reachable.

Keep local port behavior in perspective. v2rayNG manages local proxy and VPN handling on Android, and the exact port assignments can vary with the selected mode and release. Values such as 10808 for SOCKS and 10809 for HTTP are common desktop-style defaults, but Android applications generally use the v2rayNG VPN service rather than requiring every application to be configured with these ports manually. Do not treat a familiar port number as proof that traffic is working.

When testing an imported subscription, first confirm that the intended profile is actually selected. A list can contain several nodes with similar names, and tapping a row does not always mean that every old connection has been replaced. Stop the current service, select the new profile, start the service again, and then inspect the log. This creates a clear relationship between the selected configuration and the observed result.

Troubleshoot handshake failures in a fixed order

Reality errors are often caused by a single mismatched parameter, but the error may appear after several seconds as a timeout. Start with the least invasive checks. Confirm that Android has working ordinary internet access, verify the system date and time zone, and check that the server address resolves. Then compare the profile against the provider’s current link field by field. A node that worked last week may have been regenerated with a new UUID, public key, or short ID.

When every Reality profile fails at once, inspect the device clock before changing node values. TLS-style handshakes rely on reasonable time validation, and a device that has been offline, restored from a backup, or moved across time zones may have an incorrect date. Enable Android’s automatic date and time where appropriate, reconnect to the network, and restart v2rayNG before testing again.

If the log reports a timeout but the address is correct, check the remote port and network path. A provider may move a service from 443 to another port, or a DNS record may point to an old server. Do not infer that the port is open because the hostname resolves. DNS resolution only proves that a name returned an address; it does not prove that the service is listening or that the path allows the required TCP connection.

Do not solve a failed Reality connection by turning off security verification, replacing the server name with a random hostname, or copying public-key values from another profile. Those changes make the client appear different from the server and can create both connection failures and misleading test results. The fastest reliable fix is usually to obtain a fresh share link, import it into v2rayNG, and compare the decoded values with the old manual profile.

Once the connection works, keep one known-good profile unchanged. Duplicate it before experimenting with routing, TUN behavior, per-application settings, or DNS changes. Test one change at a time and record whether the failure affects the core startup, the remote handshake, or only a particular application. This separation prevents a working VLESS Reality profile from being discarded when the actual problem is an Android VPN permission, an application-specific network rule, or a DNS configuration.