VMess、VLESS、Trojan、Shadowsocks 不是四个速度档位，而是不同的认证、加密与转发方案。已有订阅的用户，应先匹配服务端参数和客户端内核；准备新建连接的用户，再按传输需求与设备能力选择。下面把协议、TLS、传输方式分开解释，并给出桌面与 Android 端的核对步骤。
先分清协议、传输与内核
节点名称里的“VLESS + WebSocket + TLS”包含三个层次：VLESS 负责代理协议的认证与请求表达，WebSocket 承载数据，TLS 提供这一组合的加密通道与服务器身份验证。只记住“VLESS”而漏掉另外两项，通常无法还原一条可用连接。
v2rayN 是桌面客户端，界面用于导入配置、选择节点和设置系统代理，实际连接由内核完成。Android 上，v2rayNG 使用 Xray 内核，v2flyNG 使用 v2fly 内核。客户端能识别某种分享链接，不代表当前内核一定支持链接里的全部扩展参数。
- 协议：看 VMess、VLESS、Trojan 或 Shadowsocks，决定认证字段及协议处理方式。
- 传输：看 TCP、WebSocket、gRPC 等字段，客户端与服务端必须使用相互匹配的配置。
- 安全层：看 TLS 或 REALITY 等设置，不要把 REALITY 当成独立的第五种代理协议。
- 路由：决定请求直连、代理或阻断，与节点使用哪种协议是不同的问题。
四种协议的加密与认证区别
比较时，先问“加密由哪一层提供”，再问“服务端如何识别用户”。UUID 或密码是认证信息，不等于完整的安全配置；端口写成 443，也不会让一条未启用 TLS 的连接自动获得 TLS 保护。
| 协议 | 认证与加密 | 常见搭配 | 重点核对 |
|---|---|---|---|
| VMess | 以 UUID 标识用户；支持协议自身的数据加密，现代配置采用 AEAD 认证机制。 | TCP，或 WebSocket + TLS 等组合。 | UUID、加密选项、传输方式，以及设备系统时间。 |
| VLESS | 以 UUID 认证；常见配置不使用协议自身的数据加密，依靠 TLS 或 REALITY 等方案保护连接。 | WebSocket + TLS，或支持相应功能的 Xray 配置中的 TCP + REALITY。 | 安全层、服务器名称、传输字段、flow，以及 REALITY 相关参数。 |
| Trojan | 以密码认证，常见标准部署依赖 TLS 提供加密与服务器身份验证。 | 通常使用 TCP + TLS；其他传输组合取决于实现。 | 密码、证书有效性、服务器名称及传输支持。 |
| Shadowsocks | 使用约定的加密方法与密钥材料；传统 AEAD 与 Shadowsocks 2022 的格式和要求不同。 | 直接承载 TCP、UDP 流量；额外封装需双方支持。 | method、密码或密钥格式，以及 UDP 支持。 |
VMess 的 AEAD 认证与 Shadowsocks 所说的 AEAD 加密方法不是同一个配置字段。老教程中的 VMess alterId 也不应随意照搬；现代 VMess AEAD 配置通常为 0，已有节点仍应以服务端实际要求为准。
Shadowsocks 同样不能只凭“密码正确”判断配置完整。例如 aes-128-gcm 与 2022-blake3-aes-128-gcm 是不同方法，后者还有专门的密钥格式要求。把加密方法改成另一种，并不会让服务端自动跟着改变。
按使用条件选择，而不是按名称排名
以下推荐针对“可以选择服务端方案”的情况。如果服务方只提供其中一种协议，应先确认它能在当前设备完整运行，而不是在客户端强行改成另一种。四种协议之间没有脱离线路、配置与设备条件的固定速度排名。
VLESS：新配置优先核对
推荐在服务端明确提供完整 TLS 或 REALITY 参数，且客户端内核支持对应组合时，可作为新配置的优先候选。推荐依据是部署条件匹配，不代表它在所有网络下更快。
适合：能够确认内核支持、需要使用相应传输与安全层的新连接。
VMess：沿用成熟配置
已有 VMess 订阅稳定可用时，没有必要仅因名称较早就更换。重点是使用匹配的现代认证配置、保持系统时间准确，并确认服务端的传输方式。
适合：已有可用订阅，或现有服务端围绕 VMess 部署的用户。
Trojan：已有 TLS 部署
如果服务端已有有效证书、明确的服务器名称和 Trojan 支持，可围绕现有 TLS 环境配置。不要把“使用 TLS”理解为可以忽略证书验证。
适合：服务端已提供完整 Trojan 参数、希望沿用 TLS 部署的用户。
Shadowsocks：匹配加密方法
配置字段相对集中，适合服务端已提供明确 method 与密钥的连接。选择传统 AEAD 还是 2022 方法，要看两端支持，不能只看客户端是否显示 Shadowsocks 选项。
适合：已有 Shadowsocks 服务，或需要在设备上比较不同加密方法开销的用户。
日常浏览、移动网络与老设备怎么判断
日常网页访问更容易受到线路往返时间、DNS 解析与服务器负载影响。切换协议时如果同时换了地区和服务商，就无法判断差异究竟来自哪一项。比较应尽量固定服务器、测试目标与网络环境。
- 日常浏览：先确认 HTTPS 页面能持续加载、图片请求能完成，再观察大文件下载。一次延迟测试成功只说明某种探测通过，不代表浏览器的全部请求都正常。
- 移动网络：从无线网络切到蜂窝网络后，现有连接可能需要重建。先检查隧道是否恢复，再检查 DNS 和 UDP；不要把每次重连都归因于协议不适合移动设备。
- 老设备：实际开销取决于 CPU 的加密加速、内核实现和额外封装。不能笼统认定 Shadowsocks 一定最省电，也不能认定 VLESS 名称中的“轻量”必然带来最低占用。
- 实时语音与游戏：需要客户端入口、代理协议实现、服务端及路由共同支持 UDP 转发。网页正常而语音失败时，应单独检查 UDP 链路。
在客户端里核对配置的四步
桌面端可先用 v2rayN 验证一条完整配置，再处理路由与应用接管。下面的菜单路径用于常见中文桌面界面；不同界面版本的文字可能略有区别，应按菜单功能对应，不要为了寻找同名选项修改无关设置。
-
导入完整链接
复制服务方提供的完整分享链接，在 v2rayN 主窗口使用 Ctrl + V 导入。不要把订阅地址当成单节点链接，也不要把一条节点链接拆成几段分别粘贴。
-
核对节点字段
双击节点打开编辑窗口，依次核对地址、端口、用户 ID 或密码、传输协议和 TLS 设置。遇到 WebSocket 时检查路径与 Host；遇到 REALITY 时按服务端要求核对公钥、shortId、服务器名称与 flow。
-
启动并看日志
将目标节点设为活动服务器，查看主界面日志区域，先确认内核能够启动。若出现“不支持的传输”或配置解析错误，优先检查内核兼容性，而不是连续更换本地监听端口。
-
接管应用流量
在托盘图标右键菜单中选择「系统代理」→「自动配置系统代理」，再用浏览器验证。需要核对本地监听时，进入「设置」→「参数设置」查看实际端口；手动设置代理的应用应填写与之匹配的地址和端口。
Android 端应先区分内核：v2rayNG 的 Xray 功能与 v2flyNG 的 v2fly 功能不能直接画等号。尤其是 VLESS 的某些扩展、安全层和 flow，必须确认应用当前所带内核是否支持。导入成功后仍要实际启动连接；“列表里出现节点”只是完成了解析。
端口、域名与安全选项别混用
远端端口是服务器接收连接的位置，本地端口是应用连接客户端的位置。下面三个数字只是便于解释的配置示例，不是四种协议的强制端口，也不是 v2rayN 的统一默认值。
例如，浏览器手动使用 127.0.0.1:1080 的 SOCKS 代理，前提是客户端确实在该地址提供 SOCKS 服务。远端节点即使填写 example.com:443，也不能把浏览器代理端口跟着改成 443；这里的 example.com 仅用于说明字段关系。
- 服务器地址与服务器名称：前者用于建立连接，后者通常参与 TLS 的 SNI 与证书验证；两者可以不同，但必须符合服务端部署。
- WebSocket Host 与路径：它们属于传输配置，不等于 UUID，也不应照抄另一条节点的值。
- 允许不安全连接：不要把跳过证书验证当成常规修复。先检查系统时间、证书域名、有效期与服务端证书链。
- REALITY 参数：应使用服务端提供的成套参数，不要将普通 TLS 节点的字段机械复制到 REALITY 节点。
协议选择常见问题
订阅里只有 VMess，需要改成 VLESS 吗？
不需要仅为协议名称更换。先启动现有节点并验证访问；如果服务方另提供 VLESS 链接，再作为独立节点导入比较。直接把编辑窗口中的协议类型改掉，不能让服务端同步切换。
VLESS 导入了，为什么一启动就报错？
先查看日志中的首条配置错误，再核对传输、安全层与 flow。Android 用户确认使用的是 v2rayNG 还是 v2flyNG，并检查对应内核支持；不要只根据链接以 vless:// 开头就认定所有字段都能运行。
Trojan 提示证书问题，关掉验证行不行？
先校准设备时间，再核对节点中的服务器名称与证书覆盖的域名。若证书过期或链不完整，应由服务端修复。关闭验证会削弱服务器身份确认，不适合作为长期解决办法。
网页能打开，语音却一直连不上？
先确认应用流量是否进入代理，再检查该配置的 UDP 支持和服务端防火墙。系统 HTTP 代理通常不能接管任意应用的 UDP 流量；需要时使用客户端实际提供的 TUN 或系统隧道能力，并重新验证路由规则。
换协议后还是超时，下一步看哪里？
按本地监听、应用代理、内核日志、远端地址和服务端可达性的顺序检查。先证明请求确实进入客户端，再判断握手是否失败；如果连接根本没有到达客户端，改 UUID 或加密方法通常没有帮助。
最终选择可以归结为三件事：服务端提供什么完整方案、设备上的内核能否执行、实际网络下是否稳定。已有可用节点先保留，新方案单独导入比较；协议匹配之后，再处理系统代理、DNS 与路由分流，排查过程会更清楚。