[GH-ISSUE #3205] Xray Reality (26.7.11+): Clash Verge / Mihomo clients fail with REALITY authentication failed — need default minClientVer #1486

New issue

Open

opened 2026-10-13 20:43:42 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-13 20:43:42 +00:00

Owner

Originally created by @stekkko on GitHub (Sep 23, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3205

Summary

Amnezia Xray containers currently ship Xray-core 26.7.x. Starting with Xray 26.7.11, if realitySettings.minClientVer is unset, the server silently defaults to 26.3.27.

Clash Verge / Clash Meta / Mihomo clients hardcode Reality client version 1.8.2 in the handshake. They are therefore rejected with:

REALITY authentication failed
or TLS handshake EOF / timeout

The same server works fine with the Amnezia client (real xray-core reporting a modern version).

This is a widespread compatibility break between Amnezia Xray servers and Mihomo-based clients — not a wrong UUID/pbk/sid in the share link.

Environment

Server: Amnezia Docker container amnezia-xray
Xray: 26.7.28
Protocol: VLESS + REALITY + xtls-rprx-vision (TCP)
Failing clients: Clash Verge Rev (Mihomo Meta ~1.19.x)
Working clients: Amnezia app (Android / macOS / Windows)

Steps to reproduce

Deploy Amnezia Xray protocol on a VPS (current Amnezia image).
Export share / .vpn and import into Clash Verge as VLESS Reality (correct uuid / publicKey / shortId / SNI / flow).
Try to connect / run delay test from Clash Verge.

Expected

Clash Verge connects the same way Amnezia clients do.

Actual

Reality handshake is rejected. Server falls through to dest camouflage. Client shows Reality auth failure.

Workaround (confirmed)

On the server, edit container config /opt/amnezia/xray/server.json and set:

"realitySettings": {
  "minClientVer": "1.8.2"
}

Then restart:

docker restart amnezia-xray

After this, Clash Verge / Mihomo works. Amnezia native clients continue to work.

("0.0.0" also works; "1.8.2" is enough for Mihomo.)

Suggested fix (Amnezia side)

Please do one or more of:

Default new Xray Reality deployments to "minClientVer": "1.8.2" (or "0.0.0") so Mihomo-based clients work out of the box.
Add a UI toggle / advanced field: “Clash Meta / Mihomo compatibility” that writes minClientVer.
Document this in Amnezia docs / FAQ:
- Symptom: Clash Verge → REALITY authentication failed
- Cause: Xray 26.7.11+ default minClientVer
- Fix: set minClientVer to 1.8.2

Upstream references

Xray-core default minClientVer behavior (26.7.11+): https://github.com/XTLS/Xray-core/issues/6482
Mihomo hardcoded Reality client version 1.8.2: https://github.com/MetaCubeX/mihomo/issues/3039
Same class of reports on 3x-ui: https://github.com/MHSanaei/3x-ui/issues/5922

Mihomo maintainers currently document that they do not chase Xray 26.7.11+ Reality version policy — so the practical fix for Amnezia users is on the server image / defaults.

Why this matters

Many users run Amnezia on the server for easy deploy, but use Clash Verge on desktop for split tunneling (per-app TUN). Right now that combo breaks unless the user SSHs in and hand-edits server.json. Making the default compatible would remove a large footgun.

Thanks!

Originally created by @stekkko on GitHub (Sep 23, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3205 ## Summary Amnezia Xray containers currently ship **Xray-core 26.7.x**. Starting with **Xray 26.7.11**, if `realitySettings.minClientVer` is unset, the server silently defaults to **`26.3.27`**. **Clash Verge / Clash Meta / Mihomo** clients hardcode Reality client version **`1.8.2`** in the handshake. They are therefore rejected with: - `REALITY authentication failed` - or TLS handshake EOF / timeout The same server works fine with the **Amnezia client** (real xray-core reporting a modern version). This is a widespread compatibility break between Amnezia Xray servers and Mihomo-based clients — not a wrong UUID/pbk/sid in the share link. ## Environment - Server: Amnezia Docker container `amnezia-xray` - Xray: **26.7.28** - Protocol: VLESS + REALITY + `xtls-rprx-vision` (TCP) - Failing clients: Clash Verge Rev (Mihomo Meta ~1.19.x) - Working clients: Amnezia app (Android / macOS / Windows) ## Steps to reproduce 1. Deploy Amnezia **Xray** protocol on a VPS (current Amnezia image). 2. Export share / `.vpn` and import into **Clash Verge** as VLESS Reality (correct uuid / publicKey / shortId / SNI / flow). 3. Try to connect / run delay test from Clash Verge. ## Expected Clash Verge connects the same way Amnezia clients do. ## Actual Reality handshake is rejected. Server falls through to `dest` camouflage. Client shows Reality auth failure. ## Workaround (confirmed) On the server, edit container config `/opt/amnezia/xray/server.json` and set: ```json "realitySettings": { "minClientVer": "1.8.2" } ``` Then restart: ```bash docker restart amnezia-xray ``` After this, Clash Verge / Mihomo works. Amnezia native clients continue to work. (`"0.0.0"` also works; `"1.8.2"` is enough for Mihomo.) ## Suggested fix (Amnezia side) Please do one or more of: 1. **Default** new Xray Reality deployments to `"minClientVer": "1.8.2"` (or `"0.0.0"`) so Mihomo-based clients work out of the box. 2. Add a UI toggle / advanced field: **“Clash Meta / Mihomo compatibility”** that writes `minClientVer`. 3. Document this in Amnezia docs / FAQ: - Symptom: Clash Verge → `REALITY authentication failed` - Cause: Xray 26.7.11+ default `minClientVer` - Fix: set `minClientVer` to `1.8.2` ## Upstream references - Xray-core default `minClientVer` behavior (26.7.11+): https://github.com/XTLS/Xray-core/issues/6482 - Mihomo hardcoded Reality client version `1.8.2`: https://github.com/MetaCubeX/mihomo/issues/3039 - Same class of reports on 3x-ui: https://github.com/MHSanaei/3x-ui/issues/5922 Mihomo maintainers currently document that they do **not** chase Xray 26.7.11+ Reality version policy — so the practical fix for Amnezia users is on the **server image / defaults**. ## Why this matters Many users run Amnezia on the server for easy deploy, but use **Clash Verge** on desktop for split tunneling (per-app TUN). Right now that combo breaks unless the user SSHs in and hand-edits `server.json`. Making the default compatible would remove a large footgun. Thanks!

bsakaguchi referenced this issue

2026-10-14 21:01:40 +00:00

[PR #1486] [MERGED] Error handling for cgroup #2386