目次
同じ REALITY 互換性問題かを最初に確認する
この記事が対象とするのは、次の組み合わせだけです。サーバーは Xray-core v26.7.11 以降で、VLESS inbound に REALITY を使用し、realitySettings の minClientVer を明示していません。クライアントは Clash Verge Rev、FlClash、その他の Mihomo フロントエンドなど、Mihomo コアを使用しています。
典型的な症状は、設定を読み込めてサーバーポートも待ち受けているのに、クライアントでは「REALITY authentication failed」、サーバーでは「authentication failed or validation criteria not met」と記録され、実通信が 0 のままになることです。
x509、certificate、invalid short id、invalid public key、SNI のエラー、または一般的なノードの timeout であれば、該当する項目を先に確認してください。これらはこの記事の直接の対象外です。
Mihomo issue #2967 には、セッションバージョン 1.8.2 と既定の下限値が衝突することが記録されています。一方、Xray issue #6477 には、同じ設定のまま v26.6.27 から v26.7.11 へ更新すると接続に失敗し、サーバーバージョンをロールバックすると復旧することが記録されています。
3x-ui issue #5922 でも、管理パネルで互換性のある minClientVer を明示すると復旧するケースが記録されています。
最近の issue #3132 では、この既知の境界を Mihomo のドキュメントへ追記するよう求められましたが、メンテナーはクライアント側の正式な修正を発表していません。
四つの条件をすべて満たす場合だけ読み進めてください
| 確認項目 | この記事の対象 | 一致しない場合 |
|---|---|---|
| プロトコル | VLESS + REALITY | 実際のプロトコル、TLS、トランスポート層から確認する |
| サーバー | Xray-core v26.7.11+ | この記事のバージョンに関する結論を当てはめない |
| サーバー側の設定項目 | minClientVer が空、または未指定 | 明示値とクライアントのバージョンを照合する |
| クライアント | Mihomo コアで認証に失敗している | 実際のコアと最初のエラーを確認する |
設定を保存し、サーバーとクライアントの実際のバージョンを記録する
サーバーを変更する前に、現在有効な Xray 設定をエクスポートまたはコピーしてください。管理パネル、Xray-core、クライアントに表示される Mihomo の各バージョンと、最初に失敗した時刻も記録します。「すべて最新版」とだけ書かず、再現可能な比較に必要なバージョン番号を残してください。
影響を受ける inbound の protocol、network、security、flow、serverNames、shortIds と、minClientVer が空かどうかも保存します。バックアップには UUID、privateKey、サブスクリプション識別子、サーバーアドレスが含まれる可能性があるため、管理された場所だけに保管してください。公開 issue やスクリーンショットでは必ず機密情報を伏せます。
xray version変更前に用意するロールバック可能な基準状態
- 現在の Xray 設定を管理された場所にバックアップした
- サーバーの Xray-core とクライアントの Mihomo のバージョンを記録した
- クライアントとサーバーの最初のエラーを保存した
- UUID、public key、private key、short-id、SNI は変更していない
- 同じネットワークで失敗したテスト結果を一件記録した
Xray が Mihomo を拒否する理由を理解する
Xray REALITY の公式ドキュメントでは、minClientVer はサーバーが許可するクライアントの最低バージョンと定義され、現在の既定値は 26.3.27 と説明されています。同じ設定で再現した Xray issue #6477 と合わせると、v26.7.11 以降はこの項目が空でも、無制限とは解釈されず既定の下限値が適用されます。
Mihomo issue #2967 に示された現在の実装では、REALITY ClientHello のセッションバージョンは 1.8.2 です。サーバーが 1.8.2 を既定の最低バージョン 26.3.27 と比較すると、このハンドシェイクは拒否されます。そのため同じノードでも、Xray クライアントでは接続でき、Mihomo クライアントでは失敗します。
これは一般的な証明書検証の問題でも、クライアント YAML に共有可能な項目が一つ不足している問題でもありません。minClientVer は Xray REALITY サーバー側の inbound 設定であり、Clash や Mihomo のサブスクリプションを通じて一般ユーザーへ配信されるものではありません。サーバーを管理できない場合は、バージョンとエラーをサービス提供者へ伝えて対応を依頼してください。クライアント側へこの項目を追加しても解決しません。
Xray クライアントは接続できるが、Mihomo では「REALITY authentication failed」となる
サーバーの minClientVer と両側のバージョンを優先して照合する。
すべてのクライアントで失敗する
inbound の待ち受け、UUID、short-id、SNI、鍵、ファイアウォールを確認し、バージョンだけを見ない。
一つのノードだけが失敗し、サーバーは更新していない
そのノードの REALITY パラメーター一式とサービス状態を先に確認する。
クライアントでは x509 または certificate エラーだけが出る
証明書、時刻、SNI を確認し、minClientVer は下げない。
バージョンまたはしきい値だけを変えて比較する
最も有効な比較は、同じ inbound、同じノード、同じネットワークを保ち、クライアントコアまたはサーバーバージョンだけを変えることです。Xray クライアントではその inbound を通じて実際の HTTPS リクエストが成功し、Mihomo クライアントでは一貫して失敗するなら、ポート、鍵、接続先サイトが同時に使えなくなったわけではありません。
更新前の公式 Xray v26.6.27 を保存しており、同じ設定のままそのバージョンへ戻すと直ちに復旧する場合も、バージョン互換性の判断材料になります。ロールバックは短時間の確認だけに使用し、バックアップと公式バイナリの入手元を確認できない状態で本番サーバーを置き換えないでください。
比較結果の読み方
| 比較結果 | 次の手順 |
|---|---|
| Xray クライアントは成功し、Mihomo は失敗する | minClientVer と Mihomo のセッションバージョンを確認する |
| 両方のクライアントで失敗する | ポート、inbound、REALITY パラメーターの確認へ戻る |
| v26.6.27 では成功し、v26.7.11+ では失敗する | バージョン境界を確認してから明示的な互換性しきい値を検討する |
| ネットワークを変えた場合だけ復旧する | ネットワーク経路やブロックを確認し、minClientVer が原因と決めつけない |
最低バージョンを下げるかを先に判断する
Xray の公式ドキュメントは、minClientVer を下げると旧クライアントの接続を許可できる一方、その TLS フィンガープリントは実際のブラウザーとの差が目立ち、DPI に識別されやすくなる可能性があると明確に警告しています。これは互換性と識別リスクのトレードオフであり、無条件に安全な修正ではありません。
サーバーの要件を満たし、同じノードで検証済みの互換クライアントへ更新できるなら、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 はサービスを起動せず、設定だけを検証します。設定パス、バイナリ名、サービスの再起動方法はインストール方法に合わせてください。パネル管理下のサービスでは、パネル固有のテストと再起動手順を優先します。
"streamSettings": {
"security": "reality",
"realitySettings": {
"minClientVer": "1.8.2"
}
}xray run -test -config /path/to/config.json変更を最小限に抑える手順
現在有効な設定をバックアップする
元の空欄状態とロールバック用ファイルを保存し、privateKey、UUID、サーバーアドレスは公開しない。
一つの inbound だけを変更する
minClientVer を 1.8.2 に明示し、その他の REALITY パラメーターは変更しない。
設定テストを実行する
テストに失敗したら直ちにバックアップを復元し、構文エラーのある設定で再起動しない。
従来の管理方法で再起動する
パネルまたは既存のサービス管理方法を使用し、二つ目の Xray を並行起動しない。
同じノードでハンドシェイクと実通信を検証する
サービス再起動後は、遅延の数値だけで判断しないでください。元の Mihomo ノード、SNI、short-id、public key、クライアントフィンガープリントを変えず、以前必ず失敗していた HTTPS リクエストを再試行してから、クライアントの接続記録とサーバーログを確認します。
修正が有効なら「REALITY authentication failed」は出なくなり、サーバーでは接続が inbound から VLESS 処理へ進み、クライアントに実際の送受信トラフィックが発生し、HTTPS リクエストを少なくとも二回連続で完了できます。変更したのはサーバー側の受け入れしきい値なので、通常はサブスクリプションの再インポートは不要です。
検証チェックリスト
- Xray の設定テストに成功し、サービスは一つだけ動作している
- 同じ Mihomo ノードで「REALITY authentication failed」が表示されない
- サーバーログで、その接続が認証失敗の処理へ送られていない
- 遅延表示だけでなく、実際の HTTPS リクエストから内容が返る
- 二回続けて再テストし、ネットワークを切り替えた後の結果も説明できる
- UUID、鍵、SNI、short-id、skip-cert-verify は変更していない
リスクを受け入れられない場合は既定値へ戻し、バージョンをロールバックする
最低バージョンを下げることで生じるフィンガープリントのリスクを受け入れられない場合は、変更前の realitySettings を復元し、設定テストを再実行してから、従来の管理方法で再起動してください。この状態で旧 Mihomo クライアントが再び失敗するのは想定どおりです。しきい値を満たし、検証済みのクライアントへ切り替えます。
短期的にサービスを復旧する必要があり、利用できる互換クライアントがない場合は、バックアップが完全で入手元を確認できることを条件に、更新前に検証済みの公式 Xray v26.6.27 へ一時的にロールバックすることを検討できます。これは互換性のためのロールバックで、旧版の方が安全という意味ではなく、今後の修正に代わるものでもありません。現行版のインストールファイルと復旧計画を保管してください。
1.8.2 を明示しても失敗する場合は、直ちにバックアップを復元し、それ以上値を下げないでください。サーバーが実際に読み込んだ設定、inbound ポート、UUID、short-id、SNI、鍵、クライアントの最初のエラーを改めて確認します。
これらの操作ではバージョン要件を解消できない
skip-cert-verify を有効にせず、SNI や client-fingerprint をむやみに変更せず、UUID、REALITY 鍵、short-id を再生成せず、サブスクリプションの変換を繰り返さないでください。いずれの操作も、サーバーが比較するクライアントバージョンを変えません。
同様に、すべてのノードを Global に切り替えたり、ルールを無効にしたり、ローカル設定を削除したりしないでください。認証はルールによる振り分け後に確立されるため、REALITY サーバーがすでにハンドシェイクを拒否している場合、クライアントのプロキシモードを変えても通過できません。
| 実施内容 | 効果がない、またはリスクがある理由 |
|---|---|
| skip-cert-verify を有効にする | minClientVer は一般的な証明書検証ではない |
| UUID と REALITY 鍵を作り直す | 元の比較条件を崩すだけで、バージョン要件は変わらない |
| minClientVer を 0 にする | 互換範囲とフィンガープリントのリスクを広げるため、最小限の修正ではない |
| 遅延の回復だけを見る | 遅延表示だけでは実際の HTTPS 通信が通ったとは限らない |
現時点の根拠の範囲と今後のメンテナンス
2026-09-02 時点で、Xray REALITY の公式ドキュメントは引き続き 26.3.27 を minClientVer の既定値としており、この値を下げた場合のフィンガープリントのリスクも明記しています。Mihomo issue #2967 は wontfix とされ、その後のドキュメント追加依頼 #3132 もクローズされています。そのため、特定の Mihomo 正式版を待てば解決すると確定事項のように案内することはできません。
現在の根拠から、この記事で限定したバージョン互換性の判断は可能です。ただし、すべての「REALITY authentication failed」を minClientVer が原因とみなすことはできません。無効な short-id、public key、SNI、時刻、flow、ポート、またはサーバーが新しい設定を読み込んでいない場合にも、似た症状が発生します。
今後、Xray または Mihomo の正式な Release、公式ドキュメント、マージ済みコードによってこの境界の変更が明示され、同じノードで実リクエストの再検証にも成功した場合に限り、この記事の一時的な互換設定を解除してください。メンテナンス記録には、サーバーバージョン、明示したしきい値、互換性を必要とするクライアント、最終検証日を残します。