VMess vs. VLESS vs. Trojan vs. Shadowsocks: Choosing the Right Proxy Protocol

1. How the four protocols differ: authentication, encryption, and transport security

The four protocols can’t be ranked simply as old versus new. VMess and Shadowsocks have built-in data encryption. Common VLESS configurations don’t encrypt payloads at the protocol layer, so they need an outer secure channel. Typical Trojan deployments rely on TLS. To compare security, consider the protocol and its outer protection together; don’t compare bare VLESS directly with an encrypted VMess connection.

alterId: 0 is a common compatibility field in modern VMess AEAD configurations; it doesn’t mean encryption is disabled. For Shadowsocks, “supports SS” isn’t enough detail either: legacy AEAD methods and the 2022 series have different key-format and core-version requirements. If the core doesn’t recognize the imported method, changing its display name won’t fix the problem.

2. Choose by use case: start with the server’s requirements

Subscription users usually don’t need to change protocols themselves. A VMess server won’t accept a connection just because you change the client’s protocol to VLESS. When setting up your own server, account for certificate management, open ports, transport support, and client versions. The recommendations below are for new connections where you control both ends and can use the required configuration—not a speed ranking for every network.

3. Handshake overhead and speed: there’s no universally fastest protocol

Handshake overhead affects how long it takes to establish a new connection. Sustained throughput depends more on bandwidth, packet loss, server load, and device performance. TCP setup, the TLS handshake, and the HTTP Upgrade for WebSocket can each add round trips. Connection reuse and TLS session resumption also affect real-world latency, so there’s no fixed millisecond figure that applies to all four protocols.

Common VLESS configurations don’t repeat payload encryption at the protocol layer, but that doesn’t mean they’re always faster than VMess or Shadowsocks. When nodes use different data centers or network egress, results mostly reflect network differences. Vision isn’t a “double your bandwidth” switch; understand its role and requirements from the core documentation and the configurations at both ends.

1. Keep test conditions consistent. Use the same server, egress, and test resource wherever possible. If you can’t control these factors, treat the results as a comparison of node performance, not of the protocols themselves.
2. Measure connection setup and downloads separately. Record the time to first response, then measure average throughput over at least 30 seconds of continuous transfer. A single latency test doesn’t predict how video or large downloads will perform.
3. Run each test three times. Use the median and note the time, whether connection reuse was enabled, and whether other downloads were running. Record failures too—not just the best result.
4. Keep routing consistent. Confirm that test requests actually use the outbound you’re testing. If a direct-connection rule matches during a test, the measured speed doesn’t represent a proxy connection.

Evaluate multiplexing separately too. It can reduce overhead for some short-lived connections, but in unsuitable configurations or lossy networks, it can increase interference between connections. Start with settings already verified for your client and server; change them one at a time only when there’s a specific problem. Avoid changing the protocol, multiplexing, and DNS settings all at once.

4. TLS, REALITY, and transports: each setting has a different role

TLS secures the channel and verifies the server’s identity. WebSocket is a transport wrapper. REALITY is a security mechanism provided by Xray, not a fifth proxy protocol. TCP, WebSocket, and the security layer are separate configuration dimensions. If the server provides TCP + REALITY, changing it to WebSocket + TLS won’t preserve the connection.

• TLS: Check serverName against the certificate’s domain. You can connect to an IP address, but certificate verification still requires the correct server name. SNI and the WebSocket Host are separate fields.
• REALITY: Check the server public key, shortId, allowed serverName, and fingerprint settings. The public key is the server’s key—not an arbitrary piece of text from a website certificate.
• Vision: A common flow value is xtls-rprx-vision. Set it only when the server and transport combination support it; don’t add it to every VLESS node.
• WebSocket: The path must match exactly, including capitalization and the leading slash. If you get an HTTP 404 or the handshake fails, check the reverse proxy forwarding and path first—not the UUID.

This is an example VLESS + TCP + TLS outbound in Xray JSON. example.net is a documentation domain, and the UUID is also illustrative; this configuration doesn’t provide a working node. Use the address, identity, and certificate domain assigned by your server. Don’t use this TLS configuration as-is for a REALITY node.

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.net",
            "port": 443,
            "users": [
              {
                "id": "6e7d180b-486c-4f4a-89c4-574ca70b83d2",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "example.net",
          "allowInsecure": false
        }
      }
    }
  ]
}

Here, outbounds describes only the outbound; it doesn’t include a complete local inbound or routing setup. If you manage nodes in v2rayN, edit their settings in the node editor. Don’t overwrite the runtime configuration generated by the client—it may be regenerated on startup or during a subscription update. For details on each field, see the JSON Configuration Guide.

5. Clients and cores: the same protocol name doesn’t guarantee the same support

v2rayN is a desktop client; its protocol support depends on the core and version it actually uses. On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Project V, V2Fly, and Xray have technical roots in common, but their configuration fields and feature support aren’t interchangeable—especially for REALITY, Vision, and newer transports.

A subscription link carries node settings; it isn’t a fifth proxy protocol. Even when import succeeds, subscription conversion can drop some extended fields. If the same node works in one client but not another, compare the protocol, port, transport, security layer, SNI, flow, and authentication details before blaming differences in core support.

6. Ports, UDP, and routing: separate the layers of a connection

The server port, local proxy port, and destination port used by an app serve different purposes. The three numbers below are examples to help identify settings—not defaults for every node or performance recommendations. Use the listening address and port in the client’s current configuration.

Setting the server port to 443 doesn’t enable TLS by itself; the protocol handshake and security layer still need to be configured correctly. Likewise, a browser connecting to a local SOCKS port and the client connecting to a remote server on port 443 are separate steps. The system proxy only affects apps that honor system proxy settings; it doesn’t prove that all traffic uses the proxy.

• Websites work, but real-time apps fail: Check whether the app uses the proxy and whether UDP forwarding is allowed by the client inbound, remote outbound, and firewall.
• Domains fail, but some IP addresses are reachable: Check the DNS query path, resolution results, and routing rules instead of assuming the protocol is unstable.
• Some sites show your local egress: Check whether a direct-connection rule matched. Switching from VMess to VLESS won’t change routing policies.

7. FAQ: troubleshooting after a successful import