Repository navigation
Conversation
REALITY servers verify the first three bytes of the TLS session ID as the client version against their configured minClientVer and silently fall back to the decoy certificate when the client is too old, which surfaces on the client as "REALITY authentication failed". mihomo hardcodes 1.8.2 there, so every server run by a recent Xray-core with minClientVer set rejects mihomo clients outright while accepting Xray/sing-box clients using the same key. Mirror the current Xray-core version (26.10.21) the same way Xray-core's own client does. Verified against a live server (Xray-core with minClientVer): before the patch REALITY Authentication: false with fingerprints chrome/firefox/safari/random and support-x25519mlkem768 on and off; after the patch Authentication: true, traffic flows with exit IP = the server.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
REALITY servers (xtls/reality, what recent Xray-core uses) read the first three bytes of the TLS ClientHello session ID as the client version and check them against
minClientVer/maxClientVer. If the version is too old, the server doesn't refuse the connection — it quietly swaps in the decoy certificate instead of authenticating. On the client this shows up asREALITY authentication failed.Xray's own client writes its real version there (
core.Version_x/y/z, see reality.go#L169-L172). mihomo hardcodes1.8.2incomponent/tls/reality.go.So the moment a server admin enables
minClientVeron a current Xray-core, every mihomo client gets the decoy fallback, while Xray and sing-box connect fine with the same key. I hit this in the wild: a server got a fresh Xray-core after an IP move, and all users of a mihomo-based GUI stopped connecting overnight — with nothing changed on their side and their keys perfectly valid. #3039 and #3241 describe the same behaviour.Fix
Stop hardcoding. Write the current Xray-core version (26.10.21) into the session ID, the same way Xray's client does.
Verification
Against the live server that triggered this (vless+xhttp+Reality, current Xray-core with
minClientVerset):REALITY Authentication: falsein the debug log, delay test fails. Tried fingerprints chrome/firefox/safari/random andsupport-x25519mlkem768on and off, on both the v1.19.34 release binary and a v1.19.24 build bundled in a GUI app — no combination helps. Xray 26.10.21 and a sing-box client connect with the same key, which points straight at the version check.REALITY Authentication: true(PQ on and off), delay test ~700–800 ms, traffic exits through the server's IP.One decision for a maintainer
Hardcoding 26.10.21 follows Xray's current version today, but it ages the same way 1.8.2 did — someone has to bump it when Xray releases. I kept the diff minimal, but I'm happy to rework it into something less maintenance-prone (e.g. a single constant with a comment, or tracking Xray releases) if you'd prefer.