vmess:// and vless:// Share Links: How to Use Them, Compare Them with Subscription URLs, and Import Them

When you receive text beginning with vmess:// or vless://, the client is handling a single node configuration. When you receive an address beginning with https:// that belongs in the “Subscription” menu, the client is usually handling a node list that can be fetched again later. Both deliver server details to the client, but their import paths, update methods, and use cases differ.

First, distinguish single-node links from subscription URLs

vmess:// and vless:// are configuration formats, not web addresses. After reading them, the client creates an outbound node containing the server domain or IP, port, user ID, transport method, TLS settings, and display name. Once imported, the original share text usually is not accessed continuously, so you must obtain and import a new link when the server parameters change.

A subscription URL is a remote source of node data. After saving it, the client sends a request during a manual or scheduled update and parses the response into multiple nodes. When the provider changes servers, ports, or transport settings, one subscription update synchronizes the changes without replacing nodes one by one. The response may contain encoded share links on separate lines or a structured configuration format supported by the client; the provider determines the exact format.

Do not identify a link by its length alone. A VLESS link can be very long, and a subscription URL may contain lengthy authentication parameters. The most reliable check is the prefix: vmess:// and vless:// belong in “Import from clipboard”; a regular https:// address should usually go to “Subscription group settings” or “Subscription settings.” If the provider specifies how to use it, follow the provider’s format instructions.

VMess share link
vmess://encoded-node-fields
Result: imported 1 VMess node

VLESS share link
vless://user-id@server:443?security=tls&type=ws
Result: imported 1 VLESS node

Subscription URL
https://sub.example.net/client/list
Result: 1 or more nodes fetched during the update

Which parameters are stored in a link

A single-node share link compresses a manual configuration into copyable text. A VMess configuration usually includes the protocol version, display name, server address, port, user ID, alter ID, transport network, camouflage type, path, host name, and TLS switch. In modern configurations, alter ID is usually 0, but clients may retain the field for compatibility with existing nodes.

VLESS does not use VMess’s user-encryption method; its authentication core is the user ID. Its URI query parameters further describe the transport layer. For example, type=ws means WebSocket, security=tls means TLS is enabled, and sni specifies the server name used during the handshake. Configurations using XTLS Vision may also include flow=xtls-rprx-vision. These fields must match the server and should not be added or removed based on their names alone.

The local ports above are client listening ports, not the node server’s port. A common v2rayN default is SOCKS 10808 and HTTP 10809; use “Settings” → “Parameter settings” to confirm the actual local listeners. If another program is using a port, the core may fail to start. The share link itself is then fine, but the log may report a listen failure or an address already in use.

The display name is only shown in the client’s node list and is not used for protocol authentication. Changing “Hong Kong 01” to “Backup for evenings” will not affect the connection, but changing the server address, port, user ID, SNI, transport path, or public-key parameters will change the handshake result. When troubleshooting, restore the original imported values first and compare fields one at a time; do not change several fields at once.

• Server address: The domain or IP address the client actually connects to.
• Remote port: The port on which the server listens, commonly 443 but not required to be fixed.
• User ID: A UUID-format string used to identify the user in VMess and VLESS.
• Transport parameters: Network types such as TCP, WebSocket, and gRPC, along with their path or service name.
• Security parameters: TLS, SNI, fingerprint, flow-control, or REALITY fields, depending on the node.

Import, update, and activate nodes in v2rayN

On desktop, copy the complete link first rather than selecting only part of it. After opening v2rayN 7.x, use “Server” → “Import share links from clipboard” to read the clipboard. Some versions also support importing with Ctrl + V when the main window is focused. After a successful import, a new row appears; the protocol column should show VMess or VLESS, and the address, port, and display name should match the source.

1. Copy the complete vmess:// or vless:// text and make sure the chat app has not truncated the beginning or end.
2. Open v2rayN and select “Server” → “Import share links from clipboard.”
3. Select the new entry in the node list, then press Enter or use the context menu to set it as the active server.
4. Select “Server” → “Test server real connection latency” to confirm that the node can establish an actual connection.
5. From the system tray menu, choose “Auto-configure system proxy” or the proxy mode you need, then visit a webpage to verify it.

If you have a subscription URL, do not put it in the single-node import dialog. Go to “Subscription groups” → “Subscription group settings,” add a group name, paste the complete HTTPS address into the subscription URL field, and save it. Then choose “Subscription groups” → “Update all subscriptions” so the client downloads the node list. Saving the URL without updating will not add nodes to the main list automatically.

v2rayN manages subscription updates by group. Before updating, check whether “Update through proxy” is enabled in the subscription settings. On first use, when no working connection is available, it is usually best to disable the option and request the URL directly. If the network cannot reach the subscription server directly, enable a working node first and then update through the proxy. After the update, check the status bar or log to confirm that the response was parsed successfully rather than merely checking whether the window closed.

Clipboard import and QR-code scanning in v2rayNG

The v2rayNG 1.10.x main screen provides import options through the “＋” button in the top-right corner. After copying a single-node link, choose “Import config from clipboard”; if the share details are shown as a QR code, choose “Scan QR code.” Scanning requires camera permission, and a successful scan creates a node entry directly. A QR code is only a text container: it still holds a VMess link, VLESS link, or subscription URL and does not change the protocol itself.

1. Copy the share link, open v2rayNG, and tap “＋” in the top-right corner.
2. Choose “Import config from clipboard” and wait for the success message at the bottom.
3. Return to the configuration list and tap the new node to make it the current configuration.
4. Tap the connect button in the bottom-right corner and confirm system connection permission.
5. Open “Test real connection for all configurations” or test the current node, then record the actual connection latency.

When scanning, fit the entire QR code inside the viewfinder and avoid screen glare or cropped alignment markers. If the QR code is on another device, you can save a clear image first and use the client’s image-recognition option; menu labels may vary slightly between versions. After recognition, always check the protocol, address, and port. If the result is only a regular web address, it is more likely a subscription entry or management page than a single-node configuration.

To import a subscription, open “Subscription group settings” or “Subscription settings” from the top-left menu, tap Add, enter the name and URL, and save. Return to the main screen and choose “Update subscription” from the top-right menu. The update accesses the remote URL and rebuilds the corresponding group, so the node count should change when it succeeds. If the URL contains authentication parameters, preserve the entire query string after the question mark when copying it.

v2rayNG uses the Xray core by default and is suitable for nodes with VLESS, XTLS Vision, or REALITY parameters. v2flyNG uses the v2fly core and is a better fit for VMess, VLESS, and standard transport configurations within v2fly’s supported range. You cannot assume both cores will fully handle a link merely because it starts with vless://; check its security layer and flow-control parameters.

Why a successful import still cannot connect

“Import successful” only means that the client understood the text format; it does not mean the remote server is reachable. A structurally valid VLESS link will still be added to the list even if the server is offline. Troubleshoot in this order: confirm the core is running, verify that local ports are listening, check remote reachability, compare handshake parameters, and confirm that system traffic enters the proxy.

Start by opening the client log. In v2rayN, view core output from “Help” or the log area on the main screen; in v2rayNG, open the log page from the menu. If local port 10808 or 10809 is already in use, go to “Settings” → “Parameter settings” and choose free ports, such as SOCKS 10818 and HTTP 10819. Save and restart the core. If you configure a browser proxy manually, update its port as well.

If the log reports a TLS handshake failure, check the device time, server name, SNI, and security type. For WebSocket nodes, also verify that the path starts with the correct slash and that the Host field matches the server configuration. REALITY configurations require the exact public key, short ID, server name, and fingerprint; any missing item can cause failure during connection establishment.

If the core is running and the real-connection test succeeds but webpages do not open, check the routing mode and DNS. Global mode is useful for quickly ruling out routing-rule issues; switch back to rule mode after confirming the connection works. If custom routing sends the target domain to a direct exit by mistake, the node will not carry that traffic even when it is healthy. Save the current rules before making changes and adjust only one item at a time.

• Connection timeout: check the server address, remote port, network reachability, and whether the subscription has expired.
• Handshake failure: check TLS, SNI, system time, transport path, and security parameters.
• Core startup failure: check for local port conflicts, core files, and configuration syntax.
• Browser bypasses the proxy: check the system proxy, the browser’s independent proxy settings, and per-app rules.
• Nodes disappear after an update: check the subscription response, group filters, and update log.

Choosing between a single link, a subscription, and manual configuration

When testing just one node, a share link is the most direct option: copy it, import it, set it as the active server, and run a real-connection test. It also works well for moving a verified single node from one device to another. However, an old share link does not refresh automatically when node parameters change, and maintaining several nodes this way can lead to mixed old and new configurations.

For long-term use, save the subscription URL and create a separate group for each source. This makes it easy to identify which source failed during an update and prevents same-named nodes from overwriting one another. Updates do not need to run too often; once a day or manually after the provider announces changes is usually enough. Frequent refreshes will not make nodes faster and may trigger the subscription service’s rate limits.

Manual configuration is mainly useful for troubleshooting or when the server provider supplies an explicit field list. First select the protocol, then enter the address, port, user ID, security layer, and transport method in order. Do not mix VMess’s alter ID, VLESS flow-control fields, or path concepts from different transport methods. After saving, test the duplicate first and delete the original only after confirming it works.

Regardless of the method, treat “configuration imported” and “connection working” as two separate checkpoints. The first checks whether the node appears in the list and its fields were parsed completely; the second checks core logs, real-connection latency, system proxy settings, and actual access. Following this order quickly reveals whether the problem lies in the link format, subscription retrieval, node handshake, or local proxy settings.