VMess vs. VLESS in Shadowrocket: What to Check When Entering Settings Manually

At a glance

What should you check first when adding VMess or VLESS manually? Confirm the Type, then verify Address, Port, UUID, transport, and TLS one by one. For users who already have their own service details, this guide explains which Shadowrocket settings are not interchangeable, which symptoms can help narrow down a problem, and how to review parameters without changing the existing configuration.

What’s the difference between VMess and VLESS?

Both use UUIDs, but does that make them interchangeable? No. A UUID is part of an identity; it doesn’t mean the two protocols use the same authentication or data handling. If your server provides VMess, choose VMess under Home → Add Server → Type. If it provides VLESS, choose VLESS. Changing only the Type while keeping the other settings does not convert an existing service to a different protocol.

How should you interpret the encryption setting? VMess has a protocol-level data encryption mechanism, and its specific setting should match the service parameters. VLESS does not provide the same kind of data encryption layer; deployments commonly protect traffic using an outer layer such as TLS. So VMess encryption and the TLS toggle are separate settings—one cannot replace the other. encryption=none in VLESS settings also does not mean TLS must be disabled.

Setting to check	VMess	VLESS
Type	Select VMess	Select VLESS
UUID	Enter the UUID for this VMess service	Enter the UUID for this VLESS service
Protocol-level encryption	Match the encryption setting to the service parameters; don’t copy it from another configuration	No equivalent encryption layer; don’t use VMess encryption settings
Transport	Must match the server configuration	Must match the server configuration
TLS	Check separately whether it’s enabled and which domain it uses	Check separately; the protocol name doesn’t tell you whether it’s enabled

Which one is always faster? You can’t tell from the name alone. Network routes, server load, transport, and TLS settings all affect connection performance. When entering settings manually, aim to match the server parameters exactly and confirm requests work. Don’t change a service configuration to use a protocol it doesn’t support.

How should you enter Address, Port, and UUID?

Where do you start in Shadowrocket? Open Home, use the add control to go to Add Server, choose the Type, then enter the Address, Port, and UUID provided by your service provider. The additional fields vary by Type, so follow the options shown in the app. Before editing an existing entry, keep a copy of its original settings so you can restore them if needed.

Address: Enter the supplied server hostname or IP address. If the field asks for a host address, don’t add https://, a path, or query parameters; those belong to other settings.
Port: Enter the port number exactly as provided. If the settings specify 443, enter 443; if they specify 8443, enter 8443. A port number alone doesn’t confirm that TLS is enabled.
UUID: Copy the full value for the corresponding service and check for leading or trailing spaces, missing characters, and line breaks. A typical UUID string is 36 characters long, including four hyphens. A correctly formatted UUID doesn’t prove that the server has authorized it.
Save and select: After saving, return to Home and explicitly select the entry you just edited before testing. Saving an entry alone does not switch the current connection to it.

36 characters

Typical length of a hyphenated UUID string

443

A common TLS port; still verify the actual settings

8443

Another possible server port; don’t automatically replace it with 443

Can you reuse a UUID across multiple entries? Only if the server explicitly authorizes the same UUID for each one. The same address, a similar label, or the same port isn’t enough to establish that. If the original details don’t include complete identity information, check with your own service provider. Don’t try to authenticate by altering characters.

How do you check transport, Host, path, and TLS separately?

Does choosing VMess or VLESS automatically select the right transport? No. The protocol name alone doesn’t guarantee a match. If the server requires WebSocket, set the corresponding transport in the client. Any other transport supported by the app must also match the server settings. Changing WebSocket to plain TCP usually isn’t an interchangeable optimization; it changes the data format the server expects.

Separate the settings: check the connection target and application-layer routing independently

Connection and identity

Address specifies which address to connect to first.
Port specifies which port to use at that address.
The UUID must match the authentication details for the corresponding service.
Type must match the protocol: VMess or VLESS.

Transport and TLS

Enter the WebSocket Host and path exactly as provided.
Don’t change the leading slash or letter case in the path.
TLS SNI specifies the server name during the handshake.
Check certificate validation, SNI, and WebSocket Host separately.

In short: Address, Host, and SNI may or may not be the same. Don’t change them just to make all three fields match.

Why might TLS need a domain name when Address is an IP? The connection target and certificate identity are different things. Some configurations connect to an IP address while the certificate is for a domain, which is then specified through SNI. Keep the domain name provided in the service settings; don’t mechanically replace it with the IP. WebSocket Host is an HTTP request header used for server routing, and it isn’t the same as the certificate name.

Can you enter just a slash for the path? Only if the original settings specify /. If the provided path is /gateway, changing it to / or omitting the leading slash may cause a routing mismatch. /gateway here illustrates the field format; it isn’t connection information you can use as-is.

Should TLS be on or off?

Can you turn on TLS as soon as you see VLESS? Check the service settings first. VLESS commonly uses TLS, but the protocol name alone doesn’t determine every security setting. VMess can also use TLS. When entering settings manually, check whether TLS is enabled separately from whether certificates are validated. Don’t bypass certificate validation to conceal a domain or certificate problem.

Enable TLS and keep certificate validation on

Recommended

If the service settings explicitly require TLS, enable it, enter the specified SNI, and keep certificate validation on. If the handshake fails, first check the device’s date and time, the domain, the certificate’s validity period, and the server configuration instead of simply ignoring validation.

Use when TLS settings are provided and the server’s identity must be verified against its certificate.

Disable TLS and verify how traffic is protected

Use this only when the service instructions explicitly say to disable TLS. This doesn’t mean traffic still has the same protection. For VLESS in particular, confirm how the service is designed to protect data; don’t change the TLS settings to an unencrypted connection on your own.

Use when the server explicitly specifies no TLS and you have verified the transport environment and its protection.

In short: restore the service settings first, then troubleshoot the certificate

If enabling TLS causes a certificate error, keep the error details and check SNI. Don’t change the port, Host, and certificate validation setting all at once. Correct one field at a time, based on the original service details, and reconnect to see whether the change helped.

Can’t connect after entering the settings? Troubleshoot in this order

Does a connected status on Home mean the UUID and TLS settings are correct? Not necessarily. Establishing the system tunnel doesn’t mean the remote service authenticated successfully, much less that a webpage request completed. First confirm which server is selected, then check the test results and request behavior. Don’t treat the tunnel toggle as proof that the entire connection is working.

Confirm the selected entry: Return to Home and check the selected entry’s Type, Address, and Port. Reconnect so subsequent requests use the settings you just saved.
Understand what the test checks: Run the connectivity test available in the app. A successful TCP connection only suggests that the port may be accepting connections; it doesn’t validate the UUID, WebSocket path, or TLS identity.
Isolate rule effects: Temporarily select Proxy under Home → Global Routing and access the same destination. When you’re done, restore the original Config or other intended mode. Direct can’t confirm that the proxy service is working.
Check the protocol layer: Verify the UUID and VMess encryption settings, along with any additional parameters specified for the VLESS service. If Flow is involved, follow the service requirements and the options actually supported in the app.
Check the transport layer: Verify the transport, Host, path, TLS, and SNI. If the remote connection works but domain requests still fail, check DNS next. Don’t rewrite DNS and every connection setting at the outset.

Why does the webpage time out when the port test succeeds?

A reachable port doesn’t mean protocol authentication succeeded. First confirm the selected entry on Home, then check Type and UUID, followed by transport and TLS. If only a specific destination fails, keep the request’s error details and distinguish between a destination service, DNS, or rules issue.

Does a TLS handshake error mean the UUID is wrong?

Don’t assume the UUID is the cause. First check the TLS toggle, Port, SNI, and the device’s date and time; then review the certificate validation details. Handshake problems and subsequent protocol authentication occur at different stages, so troubleshoot them separately based on where the error happens.

Does a WebSocket 404 always mean the path is wrong?

A 404 can indicate that an HTTP route wasn’t matched, but the status code alone can’t identify the cause. Compare the transport, Host, and full path against the original settings, one by one. Also confirm that the connection reaches the correct Address and Port. If needed, ask your service provider to check the server-side routing.

It works with Proxy but fails after switching back to Config. Should you switch to VLESS?

Don’t switch protocols yet. This result points first to the policy matching the destination request in Config and its DNS behavior. Keep the same server and test destination, inspect the relevant rules and the policy for FINAL, then decide whether the configuration needs changing.

If you already have a subscription, do you still need to enter settings manually?

How can you reduce entry errors when you already have your own subscription details? Keep the original imported result as a reference before deciding whether to add anything manually. A subscription may include protocol, identity, and transport settings that are easy to miss when copied by hand. Importing doesn’t guarantee the settings will remain valid; after server changes, check the updated details and the currently selected entry.

Before updating: Note the label and key settings of the service that currently works. Don’t rely on its display name alone to tell whether it’s still the same entry.
After updating: Check Home to make sure the entry is still there, then verify its Type, Address, Port, and transport settings. Don’t assume a manually created copy will stay in sync with the subscription.
When checking settings manually: Match each item in the original details to a field under Add Server. If there’s no corresponding option, check whether it’s supported rather than entering it in a similarly named field.
When asking for help: You can share the Type, transport, stage where the error occurs, and checks you’ve already completed. Treat UUIDs, full subscription URLs, and any tokens they contain as credentials; don’t post them publicly.

Which protocol should you keep? Keep the configuration that your service actually supports, has complete settings for, and passes verification. VMess and VLESS differ in how they should be configured and troubleshot; their names aren’t a reason to switch services. Buying the app and connecting to a service are separate matters. This site does not provide, sell, or recommend connection services or subscriptions.