VLESS+REALITY+Vision fails to connect against Xray-core v26.7.11 server (both stable v1.19.28 and alpha-2b2bdf6 kernels) — Hysteria2 unaffected

[psyhotm]

Environment

• ClashMac: v27.1.1 (207)
• Kernel tested: v1.19.28 (stable) AND alpha-2b2bdf6 — both show identical failure
• Server: Xray-core v26.7.11 (self-hosted, 3x-ui panel), VLESS + REALITY + Vision flow (xtls-rprx-vision), client-fingerprint chrome/firefox
• Same server config works fine with other xray-core-based clients (mobile apps), so it's not a server misconfiguration

Problem

All VLESS+REALITY+Vision proxies fail the health check consistently (verified via /providers/proxies API — alive: false, delay: 0 on every attempt) across three independent servers with different IPs/regions, using the same subscription/config format. Hysteria2 proxies on the exact same three servers work perfectly (alive: true, normal latency).

Switching Update Channel to Alpha and installing the latest alpha-2b2bdf6 kernel did not fix it — identical failure.

Suspected cause

Xray-core has a documented breaking change in the Vision flow padding algorithm in recent releases ("Due to changes in the Vision padding algorithm, there will be compatibility issues between the old and new versions of XTLS Vision"). It looks like mihomo's Vision implementation hasn't been updated to match the new padding algorithm yet, even in the alpha branch.

Question

Is this a known/tracked issue on the mihomo side? Is there an ETA for Vision padding compatibility with newer Xray-core releases (v26.7.x+)?

[psyhotm]

Follow-up with debug-level kernel logs, found the actual failure point.

The failure is not just a generic timeout — REALITY authentication is explicitly rejected, and it's tied to the post-quantum hybrid key exchange (X25519MLKEM768):

level=debug msg="REALITY localAddr: <SERVER_IP>:443 is using X25519MLKEM768 for TLS' communication: false"
level=debug msg="REALITY Authentication: false, AEAD: *aes.gcmAsm"
level=debug msg="Health Checked, proxy: <node-name>, url: https://www.gstatic.com/generate_204, alive: false, delay: 65535 ms"

This exact sequence (X25519MLKEM768 negotiated: false → REALITY Authentication: false) repeats identically for all three independent REALITY servers, every single health-check cycle. Hysteria2 proxies on the same three servers authenticate and pass health checks normally in the same log window.

Per Xray-core's REALITY docs, if the masquerade target (servername) supports the X25519MLKEM768 post-quantum key exchange, the REALITY client is expected to automatically use it for key negotiation. Our masquerade targets (real-world domains like yandex.ru / addons.mozilla.org) do support it. It looks like mihomo's client-side uTLS fingerprint templates (chrome / firefox) may not be including the X25519MLKEM768 key share in the ClientHello, causing a mismatch with what the newer Xray-core REALITY server (v26.7.11) now expects during authentication.

Happy to provide the full debug log excerpt if useful.

[xlighting2017]

Xray changed, mihomo will not follow
MetaCubeX/mihomo#2967

stay with the old Xray version