Mihomo で「REALITY authentication failed」が出る場合の対処方法

クライアントとサーバーのログを個別に確認します。設定を読み込め、ポートが待ち受け中でも、REALITY authentication failed または authentication failed or validation criteria not met が出ていないか、実際の通信量が 0 のままかを調べてください。

minClientVer はサーバーが受け入れる最低クライアントバージョンを定めます。Xray-core v26.7.11 以降は、未設定でも既定値の 26.3.27 を使います。本記事で確認した Mihomo は REALITY の認証セッションで 1.8.2 を送信します。これは認証時に送る値であり、アプリに表示されるインストール済みコアのバージョンではないため、サーバーに拒否される場合があります。

これは一般的な証明書検証の問題でも、クライアント YAML に共有可能な項目が一つ不足している問題でもありません。minClientVer は Xray REALITY サーバー側の inbound 設定であり、Clash や Mihomo のサブスクリプションを通じて一般ユーザーへ配信されるものではありません。サーバーを管理できない場合は、バージョンとエラーをサービス提供者へ伝えて対応を依頼してください。クライアント側へこの項目を追加しても解決しません。

該当する構成は、サーバーがXray-core v26.7.11以降、VLESSインバウンドでREALITYが有効、realitySettingsにminClientVerが明示されていない場合です。クライアントはClash Verge Rev、FlClashなど、Mihomoコアを使うMihomoフロントエンドです。

x509、certificate、invalid short id、invalid public key、SNIのエラーや通常のノードtimeoutは、該当する項目から調べてください。ここでの互換性調整は適用しません。

サーバーを変更する前に、現在有効な Xray 設定をエクスポートまたはコピーしてください。管理パネル、Xray-core、クライアントに表示される Mihomo の各バージョンと、最初に失敗した時刻も記録します。「すべて最新版」とだけ書かず、再現可能な比較に必要なバージョン番号を残してください。

影響を受ける inbound の protocol、network、security、flow、serverNames、shortIds と、minClientVer が空かどうかも保存します。バックアップには UUID、privateKey、サブスクリプション識別子、サーバーアドレスが含まれる可能性があるため、管理された場所だけに保管してください。公開 issue やスクリーンショットでは必ず機密情報を伏せます。

最も有効な比較は、同じ inbound、同じノード、同じネットワークを保ち、クライアントコアまたはサーバーバージョンだけを変えることです。Xray クライアントではその inbound を通じて実際の HTTPS リクエストが成功し、Mihomo クライアントでは一貫して失敗するなら、ポート、鍵、接続先サイトが同時に使えなくなったわけではありません。

更新前の公式 Xray v26.6.27 を保存しており、同じ設定のままそのバージョンへ戻すと直ちに復旧する場合も、バージョン互換性の判断材料になります。ロールバックは短時間の確認だけに使用し、バックアップと公式バイナリの入手元を確認できない状態で本番サーバーを置き換えないでください。

Xray のメンテナーは公式の議論で、古い、または変更された TLS フィンガープリント（ハンドシェイク時に現れる特徴）は実際のブラウザーと異なり、DPI のような通信検査で識別されやすくなる可能性があると警告しています。minClientVer を下げても、接続を許可するクライアントの範囲が広がるだけで、送信されるフィンガープリントは修正されません。互換性を回復できても、それに伴うリスクを受け入れる必要があります。

サーバーの要件を満たし、同じノードで検証済みの互換クライアントへ更新できるなら、Xray の既定値を維持する方法を優先してください。現在の Mihomo クライアントをどうしても使い続ける必要がある場合に限り、最低値をそのクライアントが報告する 1.8.2 に明示的に合わせます。手軽さを理由に 0 や 0.0.0 を指定したり、すべての制限を解除したりしないでください。

複数人で共有するサーバーでは、従来のしきい値を必要とするクライアントを先に特定し、変更理由、時刻、元へ戻す条件を記録します。対応が必要なのは影響を受ける inbound だけであり、すべての REALITY inbound を一括で緩和してはいけません。

3x-ui などのパネルでは、影響を受ける VLESS inbound を編集し、Security または REALITY 設定を開いて、空の Min Client Ver を 1.8.2 に変更します。

ネイティブ JSON 設定を使用している場合は、その inbound の realitySettings にだけ minClientVer を追加し、UUID、privateKey、serverNames、shortIds は変更しません。

保存後は、現在の Xray バイナリで実際の設定ファイルを先にテストします。公式コマンドドキュメントによると、run サブコマンドの -test はサービスを起動せず、設定だけを検証します。設定パス、バイナリ名、サービスの再起動方法はインストール方法に合わせてください。パネル管理下のサービスでは、パネル固有のテストと再起動手順を優先します。

skip-cert-verify を有効にせず、SNI や client-fingerprint をむやみに変更せず、UUID、REALITY 鍵、short-id を再生成せず、サブスクリプションの変換を繰り返さないでください。いずれの操作も、サーバーが比較するクライアントバージョンを変えません。

同様に、すべてのノードを Global に切り替えたり、ルールを無効にしたり、ローカル設定を削除したりしないでください。認証はルールによる振り分け後に確立されるため、REALITY サーバーがすでにハンドシェイクを拒否している場合、クライアントのプロキシモードを変えても通過できません。

サービス再起動後は、遅延の数値だけで判断しないでください。元の Mihomo ノード、SNI、short-id、public key、クライアントフィンガープリントを変えず、以前必ず失敗していた HTTPS リクエストを再試行してから、クライアントの接続記録とサーバーログを確認します。

修正が有効なら「REALITY authentication failed」は出なくなり、サーバーでは接続が inbound から VLESS 処理へ進み、クライアントに実際の送受信トラフィックが発生し、HTTPS リクエストを少なくとも二回連続で完了できます。変更したのはサーバー側の受け入れしきい値なので、通常はサブスクリプションの再インポートは不要です。

最低バージョンを下げることで生じるフィンガープリントのリスクを受け入れられない場合は、変更前の realitySettings を復元し、設定テストを再実行してから、従来の管理方法で再起動してください。この状態で旧 Mihomo クライアントが再び失敗するのは想定どおりです。しきい値を満たし、検証済みのクライアントへ切り替えます。

短期的にサービスを復旧する必要があり、利用できる互換クライアントがない場合は、バックアップが完全で入手元を確認できることを条件に、更新前に検証済みの公式 Xray v26.6.27 へ一時的にロールバックすることを検討できます。これは互換性のためのロールバックで、旧版の方が安全という意味ではなく、今後の修正に代わるものでもありません。現行版のインストールファイルと復旧計画を保管してください。

1.8.2 を明示しても失敗する場合は、直ちにバックアップを復元し、それ以上値を下げないでください。サーバーが実際に読み込んだ設定、inbound ポート、UUID、short-id、SNI、鍵、クライアントの最初のエラーを改めて確認します。

Mihomo issue #2967 と Xray issue #6477 は、同じ設定でもクライアントやサーバーの版で動作が変わることを示しています。3x-ui issue #5922 には、管理画面で minClientVer を明示的に設定して復旧した例が記録されています。

2026-09-02 時点で、Xray の固定コミットとメンテナーの議論は、最低クライアントバージョンの変更に伴うフィンガープリントのリスクを利用者が負う必要があると明示しています。Mihomo issue #2967 は wontfix とされ、その後の文書変更依頼 #3132 も閉じています。メンテナーはクライアント側の正式な修正を発表していないため、特定の Mihomo 正式版を待つことを確実な対処方法とは扱えません。

現時点の証拠は、上記構成のバージョン互換性の問題を支持しています。ただし、すべてのREALITY authentication failedをminClientVerのせいにはできません。無効なshort-id、public key、SNI、時刻、フロー制御、ポート、サーバーが新設定を読み込んでいない場合にも似た症状が出ます。

Xray または Mihomo の正式な Release、公式文書、マージ済みコードが互換性要件の変更を明示し、同じノードで実際のリクエストによる再テストも完了した場合に限り、明示した最低バージョンを解除して既定値に戻します。保守記録にはサーバーのバージョン、設定値、互換性が必要なクライアント、最後の検証日を残してください。