How to Fix Mihomo REALITY authentication failed

Check the client and server logs separately. Even if the configuration loads and the port is listening, look for REALITY authentication failed or authentication failed or validation criteria not met, and check whether actual traffic remains at 0.

minClientVer sets the minimum client version the server accepts. Starting with Xray-core v26.7.11, leaving it unset uses 26.3.27 by default. The Mihomo implementation checked here reports 1.8.2 in the REALITY authentication session. That is the version value submitted during authentication, not the installed core version shown in the app, so the server may still reject it.

This is not an ordinary certificate check, nor is the client YAML missing a shareable field. minClientVer belongs to the Xray REALITY server inbound configuration and is not delivered to ordinary users through a Clash or Mihomo subscription. If you do not control the server, give the versions and error to the service provider; you cannot invent this field on the client.

The relevant setup uses Xray-core v26.7.11 or later on the server, a VLESS inbound with REALITY enabled, and no explicit minClientVer in realitySettings. The client uses the Mihomo core, such as Clash Verge Rev, FlClash, or another Mihomo frontend.

For x509, certificate, invalid short id, invalid public key, SNI errors, or an ordinary node timeout, investigate the named field first. This compatibility change does not apply to those errors.

Before changing the server, export or copy the active Xray configuration. Record the control-panel version, the Xray-core version, the Mihomo version shown by the client, and the time of the first failure. Do not write only "everything is up to date"; exact version numbers are required for a repeatable comparison.

Also record the affected inbound's protocol, network, security, flow, serverNames, shortIds, and whether minClientVer is empty. The backup may contain a UUID, privateKey, subscription identifier, and server address, so keep it in a controlled location and redact any public issue or screenshot.

The most useful comparison keeps the same inbound, node, and network while changing only the client core or server version. If an Xray client can complete a real HTTPS request through that inbound while a Mihomo client consistently fails, the port, keys, and target site have not all failed together.

If you retained the official Xray v26.6.27 before upgrading and the same configuration works again immediately after returning to it, that also supports a version-compatibility diagnosis. Use the rollback only for short-term confirmation; do not replace a production server without a backup and an official binary source.

In the official discussion, an Xray maintainer warned that outdated or modified TLS fingerprints—the features presented during a handshake—may differ from real browsers and be easier for traffic inspection such as DPI to identify. Lowering minClientVer only admits a wider range of clients; it does not correct the fingerprint a client sends. Compatibility can return, but the associated risk must also be accepted.

If you can upgrade to a compatible client that meets the server threshold and has been verified on the same node, prefer to keep the Xray default. If you must continue using the current Mihomo client, explicitly set the minimum to match its reported 1.8.2; do not enter 0 or 0.0.0 or disable every restriction merely for convenience.

If this server is shared, first identify which clients still require the older threshold and record the reason, time, and restoration condition for the change. Change only the affected inbound; do not loosen every REALITY inbound in bulk.

In a panel such as 3x-ui, edit the affected VLESS inbound, open the Security or REALITY settings, and change Min Client Ver from empty to 1.8.2.

When using a native JSON configuration, add minClientVer only inside that inbound's realitySettings. Do not change the UUID, privateKey, serverNames, or shortIds.

After saving, use the current Xray binary to test the actual configuration file first. The official command documentation states that the -test option of the run subcommand validates the configuration without starting the service. The configuration path, binary name, and service restart entry point depend on your installation; for a panel-managed service, prefer the panel's own test and restart workflow.

Do not enable skip-cert-verify, blindly change the SNI or client-fingerprint, regenerate the UUID, REALITY keys, or short-id, or repeatedly convert the subscription. None of these actions changes the client version compared by the server.

Do not switch every node to Global, disable rules, or delete the local configuration either. Authentication is established after rule routing; when the REALITY server has already rejected the handshake, the client's proxy mode cannot make it pass.

After restarting the service, do not look only at the latency number. Keep the original Mihomo node, SNI, short-id, public key, and client fingerprint unchanged. Retry the HTTPS request that previously failed every time, then inspect the client connection record and server log.

When the fix is effective, REALITY authentication failed no longer appears, the server shows the inbound reaching VLESS processing, the client carries real upstream and downstream traffic, and at least two consecutive HTTPS requests complete. Reimporting the subscription is usually unnecessary because the server's acceptance threshold is what changed.

If the fingerprint risk from lowering the minimum version is unacceptable, restore the original realitySettings, rerun the configuration test, and restart through the existing management entry point. The older Mihomo client is then expected to fail again; replace it with a verified client that meets the threshold.

If service must be restored in the short term and no compatible client is available, you can consider temporarily returning to the verified official Xray v26.6.27 used before the upgrade, provided that the backup is complete and the source can be verified. This is a compatibility rollback; it does not mean that the older version is safer, and it must not override a later fix. Keep the current version's installation file and recovery plan.

If the connection still fails after explicitly setting 1.8.2, restore the backup immediately and stop lowering the value. Instead, check the configuration actually loaded by the server, the inbound port, UUID, short-id, SNI, keys, and the client's first error.

Mihomo issue #2967 and Xray issue #6477 show that the same configuration can behave differently across client or server versions. 3x-ui issue #5922 records a case that recovered after explicitly setting minClientVer in the panel.

As of 2026-09-02, the fixed Xray commit and maintainer discussion warn that changing the minimum client version means accepting the fingerprinting risk. Mihomo issue #2967 is marked wontfix, and the later documentation request #3132 is also closed. Maintainers have not announced an official client-side fix, so waiting for a particular stable Mihomo release is not an established solution.

The evidence supports a version compatibility issue in the setup above, but not every REALITY authentication failed error comes from minClientVer. Invalid short-id, public key, SNI, time, flow control, ports, or a server that has not loaded the new configuration can produce similar symptoms.

Remove the explicit minimum version and return to the default only when an official Xray or Mihomo Release, official documentation, or merged code clearly changes the compatibility requirements and the same node has passed a real-request retest. Keep maintenance records of the server version, configured value, clients requiring compatibility, and last verification date.