VMess 和 VLESS 有什么区别

机场同时下发两种节点的话，把 Clash 订阅里的 VMess 和 VLESS 各抄一条出来上下摆着，差别一眼能看完。

proxies:
  - name: "日本 VMess"
    type: vmess
    server: jp01.example.com
    port: 443
    uuid: 00000000-0000-4000-8000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    servername: jp01.example.com
    udp: true

  - name: "日本 VLESS"
    type: vless
    server: jp02.example.com
    port: 443
    uuid: 00000000-0000-4000-8000-000000000000
    flow: xtls-rprx-vision
    tls: true
    servername: jp02.example.com
    udp: true

相同的那一行是 uuid。两种协议都用一串 UUID 当用户身份，这是它们同出一源的地方。往下 VMess 多了 alterId 和 cipher，VLESS 多了 flow。字段拼法取自 Mihomo 文档里的节点示例，机场面板生成订阅时照着这套写。

把四家文档摆在一起，差异集中在这么几项。

alterId 和 cipher 这两行在管什么

cipher 是 VMess 自己的加密算法。Mihomo 文档列的可选值有 auto、none、zero、aes-128-gcm 和 chacha20-poly1305，V2Fly 那边一样，Xray 的文档只留了三个，aes-128-gcm、chacha20-poly1305 和默认的 auto。订阅里一般写 auto，由内核按运行平台挑一个。

alterId 的来历要绕一点。V2Fly 文档对它的解释是，为了进一步防止被探测，一个用户可以在主 ID 的基础上再额外生成多个 ID。这套办法后来被 VMessAEAD 取代了，文档写明，4.28.1 版本之后客户端 alterId 设为 0 代表启用 VMessAEAD，服务端自动适配。sing-box 的说法更省事，alter_id 为 0 走 AEAD 协议，为 1 走旧协议，大于 1 的值没有用处，行为和 1 相同。Xray 的 VMess 出站文档干脆不再提这个字段。

所以现在看到一条 VMess 节点写着 alterId: 16，基本可以判断这份配置是从几年前的教程里抄来的。机场面板发的订阅都写 0。

VLESS 把加密整个交给了外层

VLESS 节点里找不到 cipher，因为它自己不做加密。V2Fly 的 VLESS 页面要求 encryption 字段现阶段需要填 none 且不能留空，理由写得很直白，就是为了提醒使用者没有加密。Mihomo 的 VLESS 示例里那一行是 encryption: ""。

既然协议本身不加密，外面那层就成了必需品。Xray 文档的原话是，VLESS 必须配合传输安全层使用，只有当对端是私有地址且链路处于受信网络中，或者已经启用 VLESS Encryption 时，才允许把传输安全设成 none。落到订阅上就是，一条正常的 VLESS 节点要么带 tls: true，要么带一段 reality-opts，关于后者可以看 REALITY 和 Vision 那几个参数。

flow 这一行是 VLESS 独有的流控开关。Xray 文档列出的取值有两个，xtls-rprx-vision 会拦截目标为 443 端口的 UDP 流量，xtls-rprx-vision-udp443 除了不拦 UDP 443 之外和前者相同。sing-box 只认 xtls-rprx-vision。这一栏由机场决定，用户不用管，但它出现在节点里说明服务端那边开了 Vision。

顺带说一个容易混淆的地方。VMess 也能开 TLS，tls: true 在两种节点里都合法。区别在于 VMess 开不开 TLS 都能工作，VLESS 不开就没有任何保护。

换成 sing-box 的 JSON，同样两条节点是这个样子，TLS 相关的东西全部收进一个 tls 对象里。

{
  "outbounds": [
    {
      "type": "vmess",
      "tag": "jp-vmess",
      "server": "jp01.example.com",
      "server_port": 443,
      "uuid": "00000000-0000-4000-8000-000000000000",
      "security": "auto",
      "alter_id": 0,
      "tls": { "enabled": true, "server_name": "jp01.example.com" }
    },
    {
      "type": "vless",
      "tag": "jp-vless",
      "server": "jp02.example.com",
      "server_port": 443,
      "uuid": "00000000-0000-4000-8000-000000000000",
      "flow": "xtls-rprx-vision",
      "tls": { "enabled": true, "server_name": "jp02.example.com" }
    }
  ]
}

VMess 那边加密算法叫 security 而不是 cipher，端口是 server_port。还有一项两边都有的 packet_encoding，管的是 UDP 怎么打包，sing-box 文档给的取值是空值、packetaddr 和 xudp，其中 packetaddr 由 v2ray 5 以上支持，xudp 由 xray 支持。这一栏对不上的话，游戏和语音会不通，网页照常。

时间这件事只卡 VMess

VMess 把当前时间算进了认证。V2Fly 的要求是系统 UTC 时间误差在 90 秒之内，时区无关，Xray 写的是 120 秒。VLESS 这边，V2Fly 文档把它描述成一个无状态的轻量传输协议，并明确说它不依赖系统时间。

这条差别在排查时很好用。同一份订阅里 VMess 节点整组超时、VLESS 节点还能连，先去看设备时钟，别急着找机场客服。台式机主板电池没电、手机关掉了自动对时，都会造成这种局面。连不上的排查顺序那篇里把这一步放得比较靠前，原因就在这儿。

同一个协议名，两个项目给的说法不一样

查 VLESS 资料的时候会碰到一件让人犯迷糊的事。V2Fly 文档的 VLESS 页面顶上挂着一条提示框，原文写的是 VLESS 已被弃用并且可能被移除，请考虑使用 Trojan 作为替代品。同一天去看 Xray 的文档，VLESS 页面上有完整的 flow 取值说明，还提到了较新的 VLESS Encryption。

两边说的是同一个协议，态度相反，是因为它们本来就是两个项目。VLESS 由 Xray 所属的 Project X 提出并维护，Xray 的仓库建于 2020 年 11 月。V2Fly 维护的是 v2ray-core 这条线，跟进过一版 VLESS，现在选择把它标成弃用。

对用户的意义只有一句。照着文档配参数之前，先确认自己的客户端用的是哪个内核。v2rayN 默认带 Xray，安卓的 v2rayNG 也是 Xray，Clash 系客户端跑的是 Mihomo，三家对 VLESS 的支持都在，字段拼法各不相同。

本站 28 家机场里，两者的出现频率差很多

本站收录的 28 家机场，资料里写明协议的有 8 家。VLESS 出现 6 次，是自述里最常见的一种。VMess 一次也没有出现。数据来自机场官网自述与站长资料，核对日 2026-08-09，本站没有逐家抓包验证。

没人在宣传里提 VMess，不代表订阅里就没有。老机场留着 VMess 节点给旧客户端兜底是常见做法，导进客户端看类型标签才知道。要看更完整的六种协议对照，可以读怎么按字段认协议。挑机场时协议本身不必当成主要指标，榜单里各家的线路和套餐差得更远。

VLESS 节点连不上，排查口和 VMess 不一样。先看内核认不认，原版 Clash 内核不支持 VLESS，还在用老客户端的人会发现这类节点根本进不了列表。内核没问题就去看 TLS 那几行，servername 填错、证书过期、订阅里的 flow 和服务端对不上，表现都是握手阶段失败。这几处都排掉，剩下的就是线路问题了。