Configuring a VLESS Reality profile in v2rayNG is mostly a matter of copying a matched set of values into the correct fields. The difficult part is not the number of fields; it is knowing which values belong to the server, which values belong to the client, and which options must remain empty. This guide follows the Android interface step by step and explains the practical meaning of UUID, serverName, publicKey, shortId, fingerprint, and flow. Use the parameters supplied by your server provider rather than inventing replacements.
This guide is for Android users who need to add a VLESS + REALITY node manually in v2rayNG. You will learn which server parameters are required, how to enter them through the profile editor, how to select an Xray core, and how to verify the result through logs, latency, and a real browser request.
Understand what a VLESS Reality profile requires
VLESS and REALITY perform different jobs. VLESS identifies the user with a UUID and carries the proxy session, while REALITY provides the security and handshake layer used by the Xray client and server. A complete profile therefore contains more than a protocol name. The address, port, UUID, transport, security mode, server name, public key, short ID, and sometimes Vision flow control must agree with the server-side configuration.
The following values are commonly supplied by a provider. The exact combination can differ, so treat this as a field map rather than a configuration template.
| Profile field | What it does | Typical value or rule |
|---|---|---|
Address |
The server hostname or IP address | A domain name is common; copy it exactly |
Port |
The server listener port | Often 443, but not always |
UUID |
Authenticates the VLESS user | A complete UUID supplied by the provider |
Encryption |
Defines the VLESS encryption field | Normally none for VLESS |
Network |
Defines how the connection is transported | Usually tcp for VLESS + REALITY |
Security |
Selects the outer security layer | reality, not ordinary TLS |
Server Name |
The SNI-like name used during the REALITY handshake | Must be one of the names allowed by the server |
Public Key |
Allows the client to validate the REALITY server identity | A provider-generated key, often shown as a short text string |
Short ID |
Identifies an accepted REALITY handshake variant | Copy the exact hexadecimal value, including leading zeroes |
Fingerprint |
Selects the client TLS fingerprint presented by Xray | chrome is a common provider recommendation |
Do not confuse the server address with the REALITY server name. The address is where v2rayNG opens the connection. The server name is sent as part of the handshake and is normally a domain selected by the server operator. They may be different. Replacing the server name with the address, or replacing it with a familiar website name, can make the handshake fail even when every other field is correct.
Uses the modern Xray security combination most commonly distributed for direct VLESS profiles. It normally needs a UUID, Vision flow, server name, public key, short ID, and fingerprint.
Suitable for: a provider-issued modern Xray node
Uses ordinary TLS rather than REALITY. Its certificate, server name, and transport settings follow a different server configuration, so REALITY fields cannot simply be reused.
Suitable for: a node explicitly marked TLS
Adds a WebSocket path and possibly a host header. It is not equivalent to VLESS + REALITY over TCP, even though both profiles use VLESS.
Suitable for: a node that specifies WebSocket
Practical conclusion: copy the combination, not the label
“VLESS” alone is not enough to configure a node. If the provider gives reality, tcp, and a public key, keep those values together; changing only the security dropdown creates a different profile.
Prepare v2rayNG and check the supplied values
Before opening the editor, update v2rayNG from a trustworthy distribution and confirm which core the application is using. VLESS Reality is an Xray-oriented configuration. Older or incompatible cores may display similar fields but fail to process the REALITY handshake correctly. In v2rayNG, open the side menu or settings area, locate the core selection option, and choose an available Xray core when the imported profile or provider documentation requires Xray. Menu wording can vary between releases, but the selected core is usually visible in the application settings or profile details.
Prepare the configuration in a plain note first. Keep one item per line and remove quotation marks, spaces at the beginning or end, and accidental line breaks inside the UUID or public key. A typical parameter list may look like this:
Protocol: VLESS
Address: node.example.net
Port: 443
UUID: 00000000-0000-0000-0000-000000000000
Encryption: none
Network: tcp
Security: reality
Server Name: target.example.com
Public Key: provider-supplied-public-key
Short ID: 4f2a
Fingerprint: chrome
Flow: xtls-rprx-visionThe values above are examples of field names only. The UUID, hostname, public key, short ID, and flow value must come from the actual service. Never use the example UUID or key for a real connection. If the provider supplies a VLESS link, importing that link is usually safer than manual entry because the link can carry all of these parameters in encoded form.
Add the profile in the Android interface
Use the profile editor when you have a complete parameter set but no usable share link. The labels below describe the common v2rayNG workflow; minor placement differences may appear across application versions.
Open profiles
Launch v2rayNG, tap the add button on the main screen, and choose the option for manually adding a VLESS profile. Avoid selecting VMess, Trojan, or a generic custom entry when the provider specifically supplied VLESS parameters.
Enter endpoint
Fill in the server address and port exactly as supplied. Use the hostname in the address field when the provider gives a hostname. Do not add
https://, a path, or a colon-port suffix into the address field if the interface has a separate port box.Set identity
Paste the UUID into the user ID field. Set VLESS encryption to
noneunless the provider documents another supported value. If a flow field is available, enterxtls-rprx-visiononly when the node specifies it.Choose Reality
Set the network or transport to
tcpand the security layer toreality. Open the REALITY-specific options, then enter the server name, public key, short ID, and fingerprint. The fingerprint is oftenchrome, but it must follow the provider’s profile.Save and select
Save the profile, return to the node list, tap the new entry to select it, and start the connection. If Android asks for permission to create a VPN connection, approve it only after checking that the selected profile is the one you intend to use.
Check each REALITY field before connecting
The Server Name field is one of the most frequently misunderstood options. It is not necessarily the same as the address, and it is not a free-form website choice. The server’s REALITY configuration determines which name is accepted. The Public Key must also be copied without changing uppercase and lowercase characters or removing punctuation. A single missing character produces a handshake error.
The Short ID is commonly hexadecimal, so values may contain digits from 0 to 9 and letters from a to f. Preserve leading zeroes. If the provider shows more than one short ID, use the one paired with the selected node. The Fingerprint controls the client fingerprint choice; it does not identify your Android model and should not be replaced with an arbitrary browser name.
| Observed setting | What to select | What not to do |
|---|---|---|
| VLESS with REALITY | Security: reality |
Do not select ordinary TLS |
| TCP transport | Network: tcp |
Do not add a WebSocket path |
| Vision flow supplied | Flow: xtls-rprx-vision |
Do not invent a flow value |
| No flow supplied | Leave flow empty if the client permits it | Do not add Vision automatically |
Save the profile after every meaningful correction. If a field is hidden until a security mode is selected, first choose REALITY, then scroll through the expanded options. Some Android screens place the public key and short ID below the server name, while others group them under an advanced or REALITY section.
Verify the connection and troubleshoot failures
A green connection indicator is useful, but it is not complete proof that traffic is working. First select the profile, start v2rayNG, and wait several seconds for the local VPN interface to appear. Then open the application’s log view and look for a successful outbound connection rather than repeated timeout messages. On a normal test, the log should stop producing authentication or handshake errors while the browser can load a page that requires the proxy.
- Run the built-in latency test if the node list provides one. A timeout means the test could not complete; it does not prove that the entire Android network is offline.
- Open a browser and visit a practical test page, then load a second page after a fresh refresh. Testing only the connection switch does not confirm DNS resolution, routing, and data transfer together.
- Compare the result with v2rayNG stopped. If the browser works only after the VPN permission is active, check Android’s VPN status and confirm that another VPN application is not competing for the same interface.
- Test both Wi-Fi and mobile data when possible. A profile that works on Wi-Fi but fails on mobile data may be affected by the network route, filtering, or IPv6 preference rather than a changed UUID.
Core and transport
- Core
- Xray
- Protocol
- VLESS
- Network
- TCP
- Security
- REALITY
These selections expose the REALITY fields required by the profile.
Identity and handshake
- User ID
- Provider UUID
- Server name
- Provider value
- Public key
- Provider value
- Short ID
- Exact hexadecimal text
Every value belongs to the same server-side configuration.
Read the most useful log clues
A timeout usually points to an unreachable address or port, a blocked route, an incorrect server name, or a server that is not listening. A handshake or REALITY verification error more often indicates a wrong public key, short ID, server name, fingerprint, or security selection. An authentication error commonly points to a wrong UUID. If the profile connects but pages remain blank, inspect the flow, transport, routing mode, and DNS behavior instead of repeatedly changing the UUID.
When an imported link works but a manually created profile does not, compare the two entries field by field. Pay special attention to URL-decoded characters, the port, the type or network value, and whether the imported entry contains a flow parameter that was omitted manually. Also confirm that you saved the edited profile and selected it; changing an unselected entry does not change the active connection.
For everyday use, keep the working profile unchanged and create a copy before testing a different core or routing mode. Avoid adding custom DNS, application exclusions, or advanced routing rules until the basic node can establish a connection and pass a browser test. Once the foundation works, make one controlled change, reconnect, and compare the logs and browsing result.