目次
EasyTierの対向ノードが見えなくても、すぐに切断と判断しないでください。まだ通信が届かず、アウトバウンドが起動していないだけかもしれません。同じテストリクエストを実際に通してから、ノード一覧とアクセス結果を比較します。リモート端末では、テスト中に操作できなくならないよう、このアウトバウンドを通らない管理経路も確保してください。
EasyTier の peer がないとき、オンデマンド起動か切断かを判断する
Mihomoが動作し、ほかのプロキシが使える状態で、EasyTierにalive: false、遅延履歴0、継続するErrorまたはTimeoutが同時に出ているか記録してください。対向peer（対向ノード）一覧にこのノードがないかも確認します。この組み合わせがissue #3214の現象に対応します。
これは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アウトバウンドの異常か、Mihomoの経路全体の異常かを判断します。
再起動前にアウトバウンドと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、パブリックアドレス、サブスクリプション情報を削除してください。元の非公開コピーは保持し、公開にはマスキング済みの版だけを使用します。
アウトバウンドに一度もトラフィックが流れていない
まずテストリクエストをそのアウトバウンドに通し、起動したことを確認してください。すぐに再起動しないでください。
EasyTierは異常だが、一般的なプロキシとMihomoプロセスは正常
alive、history、遅延テスト、peerの状態を保存してから、ほかの設定は変えずにMihomoだけを再起動してください。
peerアドレスの下位ポートに到達できない
まずファイアウォール、ポート、アドレス、対向サービスを調査し、インスタンスのサイレントな接続喪失とは判断しません。
peerは存在するが、overlayの対象に到達できない
遅延だけでなく、ルーティング、exit-node、proxy-networks、対象のIPv4も引き続き確認します。
すべてのアウトバウンドが同時に失敗
まずMihomoの設定、システムネットワーク、または管理サービスを復旧します。
管理経路を確保してから Mihomo を再起動する
issue #3214の報告者は、30分を超えて待っても復旧しなかったためMihomoを再起動し、EasyTierアウトバウンドを再び利用できる状態にしました。対向側のpeer一覧にもこのノードが再び表示されました。これは単一の環境で確認された一時的な復旧方法であり、すべてのプラットフォームに対するメンテナーの保証ではなく、今後の修正に代わるものでもありません。
まず、ルーターまたはリモートホストに、ローカルコンソール、別経路の管理手段、またはこのEasyTierアウトバウンドを通らない別の管理経路が残っていることを確認します。その後、現在のフロントエンド、ShellCrash、systemd、またはデバイス管理画面からMihomoだけを再起動します。管理方法によってコマンドは異なるため、自分の環境に適さないサービスコマンドをそのままコピーしないでください。
再起動後、同じポリシー、同じ対象、同じネットワークで再度リクエストを送り、alive、history、遅延、peer一覧を比較します。復旧した場合も、記録できるのは「今回の再起動で復旧した」ことだけです。失敗が続く場合は、ポート、設定、対向サービス、ルーティングの確認に戻り、連続再起動で最初のエラーを見えなくしないでください。
EasyTierが再起動し、peerが戻り、遅延が復旧したことを確認して、実際のoverlay IPv4リクエストを一度完了します。
v1.19.32 の修正内容と引き続き調べるべき状況
Mihomo v1.19.31は2026年9月14日にリリースされ、type: easytierアウトバウンドが正式に追加されました。その後に提出されたissue #3214には、ある特定の事象が記録されています。
正式版 v1.19.31 は修正のマージ前に公開されたため、今回の自動再生成処理を含みません。PR #3215 の最終コミット fbb6742 はまずローリング Alpha に入り、その後 Mihomo v1.19.32 の正式版リリースにも収録されました。
Mihomo は EasyTier の実行イベントを受け取り、イベントストリームが閉じてインスタンスが実際に停止した場合にだけ Host と Instance を作り直します。peer の再接続は引き続き EasyTier が担当します。定期的な遅延測定を追加する修正でも、タイムアウトのたびに再起動する修正でもなく、すべてのタイムアウトが自動復旧するという意味ではありません。
この修正のためだけにローリング Alpha を追う必要はもうありません。該当する症状がある場合は、現在の状態とロールバック手段を先に確保し、メンテナンス時間帯に公式 v1.19.32 または修正を含む新しい正式版を選んでください。無人で動く端末では、予備の管理経路を特に先に確認します。
バージョンの選択
| 現在の状況 | 推奨 | 理由 |
|---|---|---|
| 該当する事象はまだ発生していない | 既存の正式版と公式 Release を確認する | 一件の報告だけで稼働中のコアを急いで置き換えない |
| v1.19.31 で断続的に接続が失われる | 証拠を保存し、v1.19.32 または新しい正式版への更新を計画する | 正式版に含まれる修正の対象範囲が明示されている |
| 接続喪失が頻発し、メンテナンス時間と予備の管理経路がある | バックアップ後に更新し、同じ障害条件で検証する | 正式版に含まれる自動復旧の動作を直接検証できる |
| リモートで無人運用している、または旧コアを復元できない | 予備の接続手段とロールバック手順を先に用意する | 更新が中断されると管理経路が使えなくなる可能性がある |
v1.19.32 をインストールし、EasyTier が自動で再接続できるか確認する
更新前に旧コアの完全なバイナリ、正しいアーキテクチャとビルドの種類を保存し、設定と管理ツール側のコア選択もバックアップします。Mihomo の公式 v1.19.32 または新しい正式版のアセットだけを使用し、実際の動作バージョンを確認してください。新旧のコンポーネントを混在させないでください。
まず実際のトラフィックをEasyTierへ到達させ、peerが表示され、overlay IPv4リクエストが成功することを確認します。メンテナンス時間内で、対向側を制御でき、予備の管理経路がある場合に限り、テスト用peerを短時間停止してから復旧させます。その後、Mihomoを再起動せずにpeerが再表示され、遅延と実際のリクエストが復旧するかを観察します。
PRの作者は、disable-p2p: true、単一経路のローカルテストで、対向側の復旧から約一秒後にpeer_addedが現れ、Mihomo PIDは変化しなかったことを確認しています。これはその特定のテストにおける自己回復設計を裏付けますが、すべてのP2P、リレー、マルチパス、または不安定なネットワークが一秒以内に復旧することを保証するものではありません。マルチパスネットワークでは、明確な通信断がまったく発生しない可能性もあります。
正式版で接続が自動復旧するかの確認項目
- 動作中のバージョンが fbb6742 の修正を含む v1.19.32 または新しい正式版である
- テストリクエストが実際にEasyTierアウトバウンドへ到達し、一般的なプロキシを引き続き比較対象として使える
- 中断前のpeer、alive、history、遅延、実際のoverlay IPv4リクエストをすべて記録済み
- 対向側の復旧後、Mihomoを再起動しなくてもpeerが再表示されることが期待される
- 遅延履歴が復旧し、実際のTCPリクエストが成功する。UDPが必要な場合は、別途実際のUDP通信を検証する
- Mihomo PIDが変化せず、ログに再構築の繰り返しやエラーループがない
- ほかのアウトバウンド、基本的な接続、端末の管理画面へのアクセスに新たな問題がない
- 旧コアのバイナリ、設定のバックアップ、復旧手順を引き続き利用できる
更新後に問題が起きたら、旧コアを丸ごと復元する
新しい正式版が起動しない、CPU やメモリが異常になる、通常のプロキシで不具合が起きる、または EasyTier がなお復旧しない場合は、設定をさらに変更するのをやめます。Mihomo を停止してから、更新前に保存した完全なバイナリと元の設定を復元し、同じ管理方法で起動してください。
ロールバック後はまずバージョンと設定の読み込みを確認し、通常のプロキシ、EasyTier アウトバウンド、overlay IPv4、管理経路を検証します。古いライブラリ、プラグイン、単一のモジュールだけを新しいディレクトリへコピーしないでください。また、報告者が使った独立した EasyTier Core と SOCKS5 を組み合わせる構成を、メンテナーの推奨として扱わないでください。
v1.19.31 へ戻すと fbb6742 による自動復旧も失われます。接続断が再発した場合は、管理された再起動を一時的な復旧策として残し、互換性の問題が解決してから再び更新してください。バージョン差を隠すために peer、秘密鍵、ルーティングを繰り返し変更しないでください。
ロールバック完了の基準
- 現在は更新前に保存した旧コアと正しいビルドの種類で動作している
- 元の設定、ポリシーグループ、EasyTier peer、管理方法を復元済み
- 一般的なプロキシと基本的なネットワークリクエストが正常
- EasyTierアウトバウンドがオンデマンドで起動し、実際のoverlay IPv4リクエストを完了できる
- デバイスのローカルおよびリモート管理経路を引き続き利用できる
- 新しい正式版のバージョン、症状、ログ、ロールバック結果を機密情報を伏せて記録した
- 異なるバージョンのバイナリやコンポーネントを混在させていない
プロジェクトへ引き続きフィードバックする場合は、プラットフォーム、アーキテクチャ、ビルドタグ、最小限にマスキングした設定、EasyTierと一般的なプロキシの比較、alive/history、peerの変化、最初の関連ログを提示してください。network-secret、秘密鍵、Controller secret、サブスクリプション、完全なパブリックネットワーク構成は公開しないでください。