In v2rayNG, open a node’s edit screen and check the protocol first, followed by its transport and security settings. VMess has its own data encryption mechanism; common VLESS configurations rely on TLS or REALITY to protect the connection. This guide is for Android users who already have a subscription and need to verify its settings. It covers alterId, SNI, transport paths, and flow to help distinguish import errors from connection issues.
Identify the protocol, transport, and security layer in the node editor
Find the node on the v2rayNG home screen, tap its edit icon, and review the protocol at the top and connection settings below. Field order can vary between versions, but check them in the same order: server address and port, user ID, transport, and transport security. If you don’t have a specific reason to change anything, go back without saving test values.
VMess and VLESS are proxy protocols; TCP, WebSocket, and gRPC are transport options; TLS and REALITY are connection security options. They operate at different layers and aren’t interchangeable. A node labeled VLESS doesn’t tell you which transport it uses or whether REALITY is enabled.
| Setting | VMess | VLESS |
|---|---|---|
| User identity | Usually a UUID | Usually a UUID |
| Protocol-level encryption | Has its own data encryption mechanism | Common configurations use encryption=none and rely on outer-layer protection |
| alterId | 0 in modern AEAD configurations | No such field |
| Common connection setups | VMess + WebSocket + TLS | VLESS + TCP + REALITY, or WebSocket + TLS |
| What to check on import | alterId, encryption options, and transport settings | Security layer, flow, and related security settings |
A subscription distributes configuration; it isn’t a fourth protocol. A single subscription can contain both types of nodes. Routing rules determine which connections use which outbound, but don’t automatically convert VMess to VLESS. Per-app proxy settings only change which apps send traffic through the client.
Different encryption models don’t mean VLESS can skip security settings
In the VMess editor, the “Encryption” field usually offers options such as auto. VMess’s protocol-level encryption and outer-layer TLS are separate things: even when the protocol provides encryption, the server may still require WebSocket over TLS. Removing the TLS settings won’t make the connection “more direct”; it may prevent the server from receiving the request at all.
In common VLESS configurations, encryption=none means the protocol doesn’t encrypt data at that layer. It doesn’t mean the entire connection is unprotected. Check whether “Transport security” is set to the TLS or REALITY option required by the server. Turning on “Allow insecure” just because you see none doesn’t fix a layer mismatch and weakens TLS certificate verification.
VLESS with complete settings from the server
RecommendedWhen adding a new configuration and all the required settings are available, import the TLS or REALITY setup provided by the server. Keep the security layer, SNI, and flow settings—don’t copy only the address and UUID.
Best for: a new connection with a subscription that explicitly supports the current v2rayNG core
A stable VMess AEAD connection
Keep the existing protocol and transport settings. If the connection works, there’s no need to switch to VLESS just because the name is newer; the server must support the protocol change too.
Best for: an existing subscription that mainly uses VMess and works reliably
Bottom line: choose a complete, importable setup—not just a protocol name
If a VLESS node is missing required details such as the REALITY public key, update the subscription or ask for the complete configuration. Don’t fill in missing values using another node’s settings. Keep a working VMess node as a comparison.
How to set alterId: usually 0 for modern VMess
Open the VMess node editor and find “Alter ID” or alterId. Modern VMess AEAD configurations use 0. The 64 often seen in older guides belongs to legacy configurations; it is not a universal setting for better compatibility or speed. Support for older authentication methods may also vary by core version.
These three values refer to different things: authentication mode, identifier format, and network entry point. You can’t infer one from another. A correctly formatted UUID doesn’t prove the account is valid, and port 443 doesn’t guarantee that the server uses TLS. Use the port provided in the subscription; don’t change it to 443 just because TLS is enabled.
- alterId is 0 after import: Leave it as is, then check the address, UUID, and transport settings. Don’t change it to 64 by default.
- An older configuration specifies a nonzero value: Update the subscription or ask the provider for an AEAD configuration. Changing the client value alone doesn’t mean the server has been migrated.
- There’s no alterId field in the VLESS editor: That’s expected. There’s no hidden setting to find, and you shouldn’t put this value in flow.
- Authentication fails and the device clock is clearly wrong: On Android, go to Settings → System → Date & time and enable automatic time. Menu names may vary by manufacturer. Time can affect both VMess authentication and TLS certificate checks.
WebSocket, TLS, and REALITY: check each setting against the server’s configuration
In the node editor, expand “Transport” and “Transport security.” For WebSocket nodes, check the path and Host; for TLS nodes, check the server name (SNI). The server address tells the client where to connect, SNI specifies the target server name during the handshake, and the WebSocket Host is an HTTP request field. These values may match or differ, depending on the server setup.
Settings to check for two common configurations
VMess + WebSocket + TLS
- Confirm the protocol is VMess and that alterId matches the server configuration.
- Set the transport to WebSocket and keep the leading slash in the path.
- Enter Host and SNI in their respective fields; don’t swap them just because the names look similar.
- Keep TLS certificate verification enabled, and make sure the domain matches the certificate.
VLESS + TCP + REALITY
- Confirm the security layer is REALITY, not ordinary TLS.
- Check the server name, public key, shortId, and fingerprint requirements one by one.
- If the server requires Vision, set flow to the correct value: xtls-rprx-vision.
- Don’t add the path or Host from a different WebSocket node.
These are two common setups, not a complete list of valid combinations. Use the server configuration and supported core features as your guide.
REALITY isn’t enabled by simply flipping a switch in an ordinary TLS configuration. The client’s public key must match the server’s private key; the shortId must be one the server accepts; and the server name must meet the server’s requirements. A shortId may be empty by design, so an empty value alone doesn’t indicate a configuration error.
For VLESS nodes using Vision, a common flow value is xtls-rprx-vision. It’s not an encryption algorithm and shouldn’t be copied into arbitrary WebSocket configurations. Adding this flow to VMess won’t turn it into VLESS + REALITY. If a field isn’t recognized, first check client and core support, then confirm the subscription was generated for that client.
Can’t connect after import? Check where it fails before blaming the protocol
In v2rayNG, tap “+” in the top-right corner, then “Import from clipboard” to add a shared link. To add a subscription, open “Subscription group settings” in the side menu, add a group, save the URL, then update the subscription from the main-screen menu. Depending on the version, the option may be called “Update subscription” or appear in a menu of update options. Successfully pasting a link only means the client parsed it; it doesn’t confirm that the account, server, or network is working.
- Check the imported entry: Open its edit screen and compare the protocol, port, UUID, transport, and security layer. Don’t rely on the node’s label—a note saying “VLESS” doesn’t replace the actual protocol setting.
- Check the logs after startup: Open “Logs” in the side menu. If the core reports a field or configuration error before it starts, fix the compatibility issue first. Repeated latency tests won’t help at this stage.
- Distinguish connection errors from handshake errors: For a connection timeout, check server reachability and the port. For certificate or handshake errors, check the device time, SNI, certificate, and security settings. Error messages are clues; interpret them in context.
- Check which traffic is routed last: If the node connects but a specific app doesn’t, check VPN permission, per-app proxy settings, and routing rules. If the app is excluded, switching between VMess and VLESS won’t automatically route its traffic through the proxy.
Can I turn a VMess node directly into VLESS?
Not by changing the client protocol alone. Ask the server provider for a VLESS endpoint and its complete settings, then import it as a new entry. Keep the original node so you can compare or switch back.
VLESS shows none. Does that mean encryption is disabled?
First check which field shows none. If it’s protocol encryption, check TLS or REALITY next. If transport security is also blank, ask the provider how the server is configured rather than guessing.
REALITY keeps failing the handshake after import. Should I disable certificate verification?
Don’t use certificate verification bypass as a fix. Check the server name, public key, shortId, fingerprint, and flow against the subscription, then confirm that the core supports the configuration and the server is up.
Why does the same subscription work on desktop but not Android?
First compare the actual settings and update times for the same-named nodes in v2rayN and v2rayNG. Then check Android VPN permission and per-app rules. Entries with the same name may come from different subscription updates.
Which protocol should you choose? Keep a stable node and test under the same conditions
Calling VLESS “lightweight” doesn’t prove it will be faster. Real-world performance also depends on network congestion, server load, transport, and the destination site. You can’t prove one protocol is faster with a single speed test between nodes in different regions or using different entry points.
- Already have a stable VMess connection: Keep using it, and make sure its authentication method is supported by the current core. Before migrating, ask the provider for a complete new node.
- A new subscription offers VLESS + REALITY: Import it into v2rayNG using the Xray core and the supplied settings. Check the security layer and flow; don’t fill in fields based on old guides.
- Want to compare performance: Run three tests per node on the same Wi-Fi, at the same time of day, and against the same destination. Record connection success, page load times, and sustained download performance—not just latency.
- Switching Android clients: v2flyNG uses the v2fly core. Don’t assume it supports the same Xray-specific configurations as v2rayNG; check that the target core supports the required combination first.
When maintaining nodes, treat “protocol, transport, and security layer” as one complete configuration. Update the subscription first, check the fields next, then adjust routing and per-app proxy settings. This preserves working connections and helps avoid mistaking incorrect server settings for an unreliable protocol.