Mihomo OpenVPN の tls-auth ハンドシェイクタイムアウトを直すには？

Mihomo issue #2992 で報告されたのは、OpenVPN アウトバウンドで tls-auth を使用し、同時に auth を SHA512 に設定した、非常に限定的な組み合わせです。

設定は読み込めて、DNS 解決と PROCESS-NAME ルールも一致しますが、制御チャネルは 4 回の再送後にタイムアウトし、クライアントログには make OpenVPN handshake: read hard reset response after 4 retransmits: context deadline exceeded と記録されます。

報告された環境は Windows 11 と Mihomo v1.19.29 です。HTTP リクエストは 502 を返し、HTTPS はプロキシが CONNECT を受け付けた後も TLS データを受信しませんでした。同じ Mihomo 環境で、tls-auth を使用しない別の OpenVPN 設定は動作しています。

この比較から、まず DNS、ルール、プロキシ入口全体を疑うのではなく、tls-auth と auth を引き続き確認すべきだと判断できます。

PR #3189 により、旧実装では tls-auth 制御パケットの HMAC が SHA1 に固定されていたことが確認されています。サーバーが SHA256、SHA384、SHA512 など別の auth ダイジェストで検証する場合、タグ長が一致しないため最初の制御パケットが破棄されます。

サーバーログを確認できる場合は、TLS Error: cannot locate HMAC in incoming packet と表示されることがあります。SHA1 を使用するサーバーはこの特定の不具合の影響を受けず、通常の TLS、証明書、ポート、ネットワークのエラーもこの記事の結論には含まれません。

まず調査専用の設定コピーを作り、稼働中の元ファイルを直接変更しないでください。対象のプロキシ項目が確かに type: openvpn であることを確認し、auth、tls-auth の有無、key-direction、proto、ポート、サーバードメインを記録します。

公式ドキュメントでは、tls-auth は tls-crypt および tls-crypt-v2 と排他的で、tls-auth 使用時の key-direction は 0 または 1 を指定できます。auth は MD5、SHA1、SHA256、SHA384、SHA512 に対応し、デフォルト値は SHA256 です。

tls-auth の静的鍵、username、password、クライアント秘密鍵、証明書の全文、実際のサーバーアドレスを公開の issue に貼り付けないでください。公開する証拠には、設定項目名、ダイジェストアルゴリズム、伏せ字にしたアドレス、エラー発生時刻、最初の関連ログだけを残します。元の設定は非公開の場所に保管してください。

テストのために tls-auth を削除したり、key-direction を推測で変更したり、サーバー側の auth を SHA1 に下げたりしないでください。そうすると認証境界が変わり、アップグレードで元の問題が直ったか検証できなくなるだけでなく、クライアント設定とサーバー設定が一致しなくなるおそれがあります。

ハンドシェイクエラーから分かるのは、OpenVPN 制御チャネルが完了しなかったことだけで、原因までは特定できません。まずサーバードメインが解決できること、対象の UDP または TCP ポートに到達できること、リクエストが実際にこの OpenVPN アウトバウンドへ一致することを確認し、比較用として動作確認済みのアウトバウンドを残します。

ログの名前解決、接続、証明書読み込み、設定検証の段階で、より前のエラーが出ている場合は、そのエラーを先に処理します。DNS とルールがともに成功し、接続が OpenVPN ハンドシェイクに進んだ後で 4 回の hard reset 再送タイムアウトが発生する場合に限り、issue #2992 の診断順序に当てはまります。

アップグレードの前後を通して、同じサーバー、同じ伏せ字済み設定、同じ HTTPS 接続先を使用してください。テスト中にノード、プロトコル、ポート、証明書、auth を同時に変更すると、接続が回復しても、その結果を v1.19.31 の効果だと判断できません。

v1.19.31 は PR #3189 の修正を含む安定版です。アップグレード前に、現在のバイナリの完全なバージョン出力、オペレーティングシステム、CPU アーキテクチャ、管理しているクライアントまたはサービスマネージャー、現在のコアファイルの実際の場所を記録します。

設定、参照される証明書ファイル、旧コアのバイナリをすべてバックアップし、バックアップは非公開で保管してください。GUI クライアントを使用する場合は、そのクライアントのコア更新画面と自動更新ポリシーも記録します。アプリのバージョンと実際に稼働中の Mihomo バージョンが常に同じとは限りません。

リモート機器、ルーター、無人ホストでは、その OpenVPN アウトバウンドを経由しない管理経路があることを先に確認してください。予備の接続手段がない場合は、唯一の接続時間帯にコアを直接置き換えないでください。

Mihomo v1.19.31 は 2026 年 9 月 14 日にリリースされました。Release にはコミット 6d179a1c が明記されており、OpenVPN tls-auth の HMAC ダイジェストが SHA1 に固定されず、auth に従うよう修正されています。

最低条件は、実際に v1.19.31 が稼働していることです。後続の安定版を使用する場合は、6d179a1c の修正が含まれていることを確認してください。グラフィカルクライアントの画面やサブスクリプションを更新しただけでは、コアのアップグレードにはなりません。

Mihomo を直接実行している場合は、MetaCubeX/mihomo 公式の v1.19.31 Release から、オペレーティングシステム、CPU アーキテクチャ、ビルド種別が一致するアセットを選び、Release ページに記載された SHA256 と照合します。

Clash Verge Rev、OpenClash、その他のフロントエンドがコアを管理している場合は、そのプロジェクトに用意された公式のコア更新機能を使用し、更新後に実際の稼働バージョンをもう一度確認します。

旧コアを停止してからファイルを置き換え、既存の権限、起動引数、サービス設定を維持します。異なるバージョンの個別ライブラリを混在させないでください。また、検索広告、オンラインストレージ、出所不明のミラーから同名のコアを取得しないでください。

アップグレード後に重要なのは、画面上で成功と表示されることではなく、同じサーバー、同じ Profile、同じ auth、同じ tls-auth で制御チャネルのハンドシェイクが完了することです。まずポリシーグループの選択を固定し、リクエストが対象の OpenVPN アウトバウンドへ明確に一致するようにしてから、アップグレード前と同じ HTTPS 接続先へアクセスします。

ログに read hard reset response after 4 retransmits が出なくなったことを確認し、リクエストが実際の HTTPS レスポンスを受信できることも確認します。さらに通常のアウトバウンドも検証し、コアのアップグレードでほかの経路が壊れていないことを確かめます。UDP が必要な場合は、その後で実際の UDP 通信を別途検証してください。遅延値だけで代用することはできません。

tls-auth を無効にした、SHA1 に変更した、別のサーバーへ切り替えた後の成功を、修正の検証結果にしないでください。これらの変更で分かるのは別の設定が利用できることだけで、v1.19.31 が元の組み合わせを修正したことは証明できません。

実際の稼働バージョンがすでに v1.19.31、またはこの修正を含むことが確認済みの後続安定版なのにハンドシェイクが失敗する場合は、すべてのエラーを旧版の SHA1 固定に結び付けないでください。まずエラーが同じ内容か、リクエストが引き続き同じアウトバウンドへ一致しているか、サーバー側で HMAC、証明書、鍵の方向、認証に関するエラーも同時に記録されていないかを比較します。

ca、cert、key、tls-auth、key-direction、auth、proto、ポート、システム時刻をもう一度確認し、tls-auth が tls-crypt または tls-crypt-v2 と併用されていないことも確かめます。サーバー設定や鍵が最近変更されている場合は、現在のサーバー設定を基準にし、古いクライアントファイルから推測しないでください。

元のエラーが消え、別の明確なエラーに変わった場合に限り、新しい最初のエラーに従って調査を続けます。ダイジェスト、鍵の方向、証明書を何度も変更すると、バージョン比較が成立しなくなるだけでなく、サーバー側の失敗保護が作動する可能性もあります。

v1.19.31 により現在の機器で別の起動問題や互換性問題が生じた場合は、新しいコアを停止し、アップグレード前に保存した旧バイナリ一式と元の設定を復元してから、同じ管理画面または管理ツールで起動できます。ロールバック後は、まずバージョンと設定の読み込みを確認し、その後で通常のアウトバウンドと機器の管理経路を検証します。

旧コアに戻すと、この記事で説明した tls-auth と SHA1 以外の組み合わせによるハンドシェイク問題も再び持ち込まれるため、この OpenVPN Profile の長期的な修正にはなりません。業務をすぐ復旧する必要がある場合は、動作確認済みの別のノードまたはプロトコルへ切り替えるか、その Profile を一時的に無効にしてください。tls-auth を削除したり、key-direction を推測で変更したり、旧クライアントに合わせてサーバーの auth を下げたりしないでください。

再度アップグレードするときも、同じ伏せ字済みの基準設定、公式アセット、実際のリクエストを使用します。上流へ報告する際は、システム、アーキテクチャ、完全なバージョン出力、設定項目の組み合わせ、アップグレード前後の最初の関連ログ、最小再現手順を含めます。ただし、静的鍵、アカウント、秘密鍵、実際のサービスアドレスは絶対に含めないでください。