Clash/mihomo 订阅转换：VLESS 链接转配置时容易丢的三个字段

把一条 VLESS 分享链接转成 Clash / mihomo 配置，看起来只是格式换一换：解析 URL、填进 YAML、导入客户端。实际操作里我踩过三次坑，每次都是链接里没有、但内核又要求的字段被悄悄丢掉了。最典型的一次是 Xray 26.9.9 的 Reality 节点，链接导入后一直 Timeout，内核日志里才是 REALITY authentication failed——服务端、公钥、UUID、short-id、伪装域名全对，就差一行客户端配置。

字段一：Reality 的 MLKEM 开关

Xray 从 26.9.8 起，Reality 服务端要求客户端的 ClientHello 里带 X25519MLKEM768 的 key share。这是一个后量子密钥交换扩展，服务端升级后就变成硬性要求，不带就直接认证失败。

问题是分享链接里根本没有这个字段。vless:// 链接的查询参数只有 security=reality、pbk、sid、sni、fp、type 这些，MLKEM 开关不在链接协议里。mihomo 必须在 reality-opts 里手动补：

- name: "🇸🇬-SG-直连"
  type: vless
  server: 111.91.20.50
  port: 443
  uuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
  network: tcp
  tls: true
  servername: www.google.com
  reality-opts:
    public-key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    short-id: xxxxxxxx
    support-x25519mlkem768: true

关键点：support-x25519mlkem768: true 必须显式写，mihomo 默认不开。sing-box 系客户端（包括手机上的 Karing 这类壳）在当时没有对应的开关，Reality 连新版 Xray 会直接失败，只能先绕道 WS 或 XHTTP。

排查经验：客户端界面只显示 Timeout，别被这个表象带偏，先看内核日志。看到 REALITY authentication failed 再去核对这一行，服务端和公钥都不用动。

字段二：SNI 与指纹不是摆设

第二类丢字段发生在 TLS 层。很多转换工具在生成配置时只保留 servername，丢掉指纹（fingerprint），或者把 SNI 写成裸 IP。

  servername: www.google.com
  fingerprint: chrome
  skip-cert-verify: false

SNI 决定了服务端看到的是哪个域名，指纹决定了 ClientHello 长什么样。Reality 尤其依赖这两项：服务端拿 SNI 去匹配伪装站点的证书，指纹不对就可能被中间设备识别出来。转换后第一件事就是核对这两行，缺了就按原链接的 sni 和 fp 参数补回去，不要留空让客户端用默认值。

字段三：UDP 与多路复用的默认行为

第三类是容易被忽略的传输层开关。VLESS 链接本身不携带 udp、smux、flow 这些信息，转换工具要么不写、要么按自己的模板填默认值：

  udp: true
  flow: xtls-rprx-vision

Vision（xtls-rprx-vision）只在 TCP + TLS + Reality/Vision 组合下有效，配错组合会直接连不上；UDP 默认在很多模板里是关闭的，关掉后 DNS 和 QUIC 流量会绕路甚至失败。我的做法是：转换完成后逐项核对这三个字段，对照原节点的实际用途填，不要信任转换工具的默认模板。

转换后的核对清单

每次转换完、导入前，我按这个顺序过一遍，花不了一分钟：

1. reality-opts 里有没有 support-x25519mlkem768: true（Reality 节点必查）
2. servername 和 fingerprint 是否与原链接的 sni、fp 一致
3. udp、flow 是否符合节点的实际组合（Vision 只配给 TCP+TLS）
4. YAML 语法校验通过（缩进错一位整个配置就废了）
5. 导入后先看内核日志，不要只看界面上的延迟数字

订阅转换真正的坑不在格式，而在“链接表达不了、内核又要求”的语义参数。链接是 1:1 的搬运工，转换工具只负责把看得见的字段搬过去，看不见的那几行得自己补。补完再导入，就不会再对着一个 Timeout 干瞪眼了。