DEV Community

ricco020
ricco020

Posted on

Wrong key or wrong short ID? Xray REALITY gives the same error for both

#networking #privacy #linux #selfhosted

I maintain VLESS + REALITY config templates for people running their own Xray server, and tonight I ran a small fault-injection test on Xray-core 26.10.31 to answer one question: when a REALITY client is misconfigured, what does each side actually tell you?

Short answer: the server tells you nothing, and two different mistakes produce the exact same client error.

The setup

Everything ran on one Linux box, loopback only:

  • Xray 26.10.31 (a4a3dff, go1.27.3), server inbound VLESS + REALITY + Vision, target www.microsoft.com, server log level warning (the usual production setting).
  • A client config with a local SOCKS5 inbound and an HTTP inbound, fingerprint: chrome.
  • Fresh keys from xray x25519, UUIDs from xray uuid, a short ID from openssl rand -hex 8.
  • Test request: curl --socks5-hostname 127.0.0.1:<port> https://www.cloudflare.com/cdn-cgi/trace.

Baseline first. Both files pass xray run -test ("Configuration OK."), the correct client returns HTTP 200 through SOCKS5 and through the HTTP inbound, and a plain TLS probe to the server port (openssl s_client -servername www.microsoft.com) gets the real Microsoft certificate (CN = www.microsoft.com). That last part is the whole point of REALITY: a prober who does not hold the key just sees the cover site.

Then I started three broken clients against the same server.

Results

Client mistake curl result Client log Server log (warning)
Wrong public key (password from another keypair) fails after ~2.1 s, SSL_ERROR_SYSCALL REALITY: received real certificate (potential MITM or redirection) nothing
shortId not in the server list fails after ~2.1 s, SSL_ERROR_SYSCALL REALITY: received real certificate (potential MITM or redirection) nothing
serverName not in serverNames (www.apple.com) fails after ~2.2 s, SSL_ERROR_SYSCALL only accepted tcp:www.cloudflare.com:443 [socks-in >> proxy] nothing

Three things I did not expect before running it:

1. A wrong key and a wrong short ID look identical. In both cases the server does not recognise the client as one of its own, so it behaves as a transparent relay to the target, the client receives Microsoft's genuine certificate, and Xray reports a possible MITM. The message is accurate from the client's point of view, but it sends you looking at your network when the problem is a copy-paste. If you see received real certificate, check the public key and the short ID first, in that order.

2. A wrong SNI is even quieter. No REALITY error at all on the client, just a connection accepted locally and a failed TLS session downstream. If your client logs show traffic being accepted and nothing coming back, compare serverName with the server's serverNames array character by character.

3. The server says nothing at warning. None of the three failures produced a single line on the server. That is by design (a REALITY server is supposed to look like it is not there), but it means "check the server logs" is useless advice for client-side mistakes unless you temporarily raise the log level.

Two warnings worth reading

Xray 26.10.31 now prints these at startup when you choose them:

REALITY: Choosing "www.microsoft.com" as the target will increase the likelihood of your server's IP being blocked by the GFW
REALITY: Listening on non-443 ports will increase the likelihood of your server's IP being blocked by the GFW
Enter fullscreen mode Exit fullscreen mode

The first one is new to me in a release build and contradicts a lot of older tutorials that use www.microsoft.com as the default dest. Pick a target that is plausible for your server's network neighbourhood and supports TLS 1.3 and H2.

The field name changed

In the client realitySettings, current Xray uses password for what everyone still calls the public key. xray x25519 prints it as Password (PublicKey): .... Templates that still say publicKey keep working for now, but if you diff your config against a recent example and see password, it is the same value, not a new secret.

One client I could not make work

I also tried a sing-box 1.14.4 client against the same Xray 26.10.31 server, with chrome, firefox and safari fingerprints. All three failed with reality verification failed, while the Xray client with the same values worked. I have not dug into the cause, so treat it as "test your exact client and server versions together", not as a verdict on sing-box.

A 3-line checklist

  1. xray run -test -c config.json on both sides. It catches placeholders and malformed keys immediately (invalid "privateKey"), not logic errors.
  2. Run the server and the client on one machine on a spare port before touching the VPS firewall. If loopback works, the remaining problem is network, not config.
  3. If it fails with received real certificate, the key or the short ID is wrong. If it fails silently, the SNI is wrong.

I keep a longer walkthrough of VMess vs VLESS, REALITY and the transport options, with the full server and client JSON, here: V2Ray, VMess and VLESS setup guide. If you just want the keys, short ID and share link generated in the browser, there is a free VLESS REALITY config generator on the same site.

Top comments (0)