Mihomo v1.19.31でEasyTierアウトバウンドが接続を失った場合の対処法は？

Mihomo v1.19.31は2026年9月14日にリリースされ、type: easytierアウトバウンドが正式に追加されました。その後に提出されたissue #3214には、ある特定の事象が記録されています。

レポートでは、Mihomoとほかのプロキシは正常なまま、EasyTierアウトバウンドだけがalive: falseとなり、遅延履歴は0、速度テストはErrorまたはTimeoutが続き、対向側のpeer一覧からもこのMihomoノードが見えなくなっています。

これはLinux/amd64、with_gvisor、OpenWrt/Kwrt、ShellCrash環境でのユーザーレポートであり、すべてのv1.19.31、すべてのフロントエンド、またはすべてのプラットフォームで発生することを意味しません。報告者は同日に三回確認しましたが、EasyTier対向側の再起動後に発生したことが明確なのは初回だけです。そのため、対向側の再起動を唯一の発生条件とは断定できません。

すべてのプロキシが利用不能、Mihomoが起動不能、設定の読み込みに失敗、またはDNSとルールマッチだけに異常がある場合は、このレポートで説明されている範囲には含まれません。まず最初のエラーに沿って対処し、alive: falseが一つあるだけで根本原因を判断しないでください。

Mihomoの公式ドキュメントによると、EasyTierアウトバウンドは、ルール、ポリシーグループ、またはほかのルーティング方法によってトラフィックが送られたときにのみ起動します。設定を読み込んだ直後で、まだリクエストが到達していない時点でアクティブなインスタンスが見えない場合は、正常なオンデマンド動作にすぎず、サイレントな接続喪失ではない可能性があります。

まず、再現可能なテスト対象を一つと、EasyTierを明示的に選択するポリシーグループを一つ固定し、リクエストを実際にこのアウトバウンドへ送ります。listenersを設定していない場合、ドキュメントでは少なくとも一つのpeersが必要です。overlayアドレスはIPv4のみに対応し、ip-versionは下位のpeer接続でIPv4とIPv6のどちらを使うかを決めるだけであり、overlay IPv6を有効にするものではありません。

今回は起動条件だけを検証し、鍵、peerアドレス、ポリシーグループ、ルーティングを同時に変更しません。一度に複数の変数を変更すると、復旧しても設定修正とインスタンス再構築のどちらが効いたのか区別できません。

テストトラフィックがすでにEasyTierへ到達しているのに、alive: false、遅延履歴がすべて0、連続タイムアウトが発生する場合は、再起動前に現場の状態を保存します。アウトバウンド名、状態、速度テスト時刻、最初の関連ログ、EasyTier対向側のpeer一覧に想定したhostnameがまだあるかを記録してください。

報告者はeasytier-cli peerで対向ノードを確認し、異常なインスタンスが消えていることを確認しました。現在のEasyTierデプロイが提供するpeer確認手段を使って、同じ読み取り専用の確認を行えます。ただし、再現のために出所不明のスクリプトを実行したり、本番のpeerを変更したりしないでください。

curlでEmpty reply from serverが一度返っただけでは、認証とoverlayが正常だとは証明できません。分かるのは、TCP接続後に有効な応答を受信しなかったことまでです。

証拠を共有する前に、network-secret、秘密鍵、peer公開鍵、Controller secret、パブリックアドレス、サブスクリプション情報を削除してください。元の非公開コピーは保持し、公開にはマスキング済みの版だけを使用します。

issue #3214の報告者は、30分を超えて待っても復旧しなかったためMihomoを再起動し、EasyTierアウトバウンドを再び利用できる状態にしました。対向側のpeer一覧にもこのノードが再び表示されました。これは単一の環境で確認された一時的な復旧方法であり、すべてのプラットフォームに対するメンテナーの保証ではなく、今後の修正に代わるものでもありません。

まず、ルーターまたはリモートホストに、ローカルコンソール、別経路の管理手段、またはこのEasyTierアウトバウンドを通らない別の管理経路が残っていることを確認します。その後、現在のフロントエンド、ShellCrash、systemd、またはデバイス管理画面からMihomoだけを再起動します。管理方法によってコマンドは異なるため、自分の環境に適さないサービスコマンドをそのままコピーしないでください。

再起動後、同じポリシー、同じ対象、同じネットワークで再度リクエストを送り、alive、history、遅延、peer一覧を比較します。復旧した場合も、記録できるのは「今回の再起動で復旧した」ことだけです。失敗が続く場合は、ポート、設定、対向サービス、ルーティングの確認に戻り、連続再起動で最初のエラーを見えなくしないでください。

v1.19.31正式版は修正のマージ前にリリースされたため、今回の自動再構築ロジックは含まれていません。PR #3215は2026年9月15日にAlphaへマージされ、最終コミットはfbb6742です。2026年9月16日のローリングPrerelease-Alphaにも、「サイレントなoverlay障害後にEasyTierアウトバウンドを再起動する」修正が明記されています。

最終的な実装では、定期的な速度テストは追加されておらず、すべてのタイムアウトを再起動シグナルとして扱うこともありません。peerの再接続は引き続きEasyTier自体が担当し、Mihomoはイベントストリームを処理します。イベントストリームが閉じ、インスタンスが実際に停止した場合にのみHostとInstanceを再構築します。この範囲は「どのタイムアウトも自動で修復する」というものより限定的です。

Alphaはローリングタグであり、後に別のコミットを指すようになります。試用する場合は、fbb6742、ダウンロード時刻、アセットファイル名、現在のビルドタグを併せて記録し、「最新のAlpha」とだけ書かないでください。無人運用のルーター、予備の管理経路がないデバイス、またはすぐにロールバックできないデバイスは、安定版を使い続け、今後の正式Releaseにこの修正が明記されるのを待つほうが適しています。

Alphaをテストする前に、v1.19.31安定版の完全なバイナリ、正確なアーキテクチャとビルドバリアントを保存し、設定と管理ツールでのコア選択もバックアップします。Mihomo公式のPrerelease-Alphaアセットだけを使用し、実行中のコミットにfbb6742が含まれることを確認してください。新しいコアファイルと旧バージョンのコンポーネントを混在させてコピーしないでください。

まず実際のトラフィックをEasyTierへ到達させ、peerが表示され、overlay IPv4リクエストが成功することを確認します。メンテナンス時間内で、対向側を制御でき、予備の管理経路がある場合に限り、テスト用peerを短時間停止してから復旧させます。その後、Mihomoを再起動せずにpeerが再表示され、遅延と実際のリクエストが復旧するかを観察します。

PRの作者は、disable-p2p: true、単一経路のローカルテストで、対向側の復旧から約一秒後にpeer_addedが現れ、Mihomo PIDは変化しなかったことを確認しています。これはその特定のテストにおける自己回復設計を裏付けますが、すべてのP2P、リレー、マルチパス、または不安定なネットワークが一秒以内に復旧することを保証するものではありません。マルチパスネットワークでは、明確な通信断がまったく発生しない可能性もあります。

Alphaが起動できない、CPUまたはメモリに異常がある、一般的なプロキシでリグレッションが発生する、またはEasyTierが依然として復旧しない場合は、設定の変更を続けるのをまず止めます。Mihomoを停止した後、アップグレード前に保存したv1.19.31の完全なバイナリと元の設定を復元し、同じ管理経路から再起動します。

ロールバック後は、まずバージョンと設定の読み込みを確認し、その後、一般的なプロキシ、EasyTierアウトバウンド、overlay IPv4、管理経路を検証します。旧ライブラリファイル、プラグイン、または単一のモジュールだけをAlphaのディレクトリへコピーしないでください。また、issueの報告者が使用した、独立したEasyTier CoreにSOCKS5を組み合わせる代替構成を、メンテナーの推奨として記載しないでください。

安定版へロールバックすると、fbb6742の自己回復ロジックは再び失われます。接続喪失が再発する場合は、制御された再起動を一時的な復旧方法として残し、今後の安定版Releaseを待つことができます。peer、鍵、ルーティングを何度も変更して、再現可能なバージョン差を覆い隠さないでください。

2026年9月16日時点で、現在の安定版は引き続きv1.19.31であり、EasyTierのサイレントな接続喪失後の自動再構築について明確な記録があるのはAlphaコミットfbb6742だけです。今後は、Mihomoの正式Releaseにこのコミットまたは同等の修正が含まれるかを基準にしてください。次のバージョン番号を推測したり、issueがclosedになったことをリリース済みと見なしたりしないでください。

正式版のリリース後も、同じポリシー、同じpeer、同じテスト対象を使い、正常な起動、短時間の中断、自己回復、一般的なプロキシ、ロールバックを一度再確認する必要があります。Releaseノート、実行バージョン、ローカル環境での結果の三者が一致して初めて、一時的な再起動またはAlphaテストの手順を取りやめられます。

プロジェクトへ引き続きフィードバックする場合は、プラットフォーム、アーキテクチャ、ビルドタグ、最小限にマスキングした設定、EasyTierと一般的なプロキシの比較、alive/history、peerの変化、最初の関連ログを提示してください。network-secret、秘密鍵、Controller secret、サブスクリプション、完全なパブリックネットワーク構成は公開しないでください。