目次
パソコンをスリープから復帰させると、Clash Partyのノードの遅延測定は正常でも、TUNがオンのまま通信できなくなることがあります。また、TUNの設定を変えても、実際の通信が以前の設定のままに見える場合もあります。まずアプリのバージョンと発生までの操作を確認し、その後でコアの再読み込みを行います。どちらもノードの障害と決めつけないでください。
復帰後に通信できないのに、ノードの遅延測定は正常なのはなぜ？
Clash Party v2.0.4の正式リリースノートでは、復帰時のTUN再作成に設定の一部が渡されない問題と、TUN設定の保存後にコアが再起動しない問題の修正が案内されています。本記事ではこの二つを扱います。アップグレードですべての環境のTUN通信障害が直るとは限りません。
プロジェクトのIssue #2235では、macOSでv2.0.3を使うユーザーが、画面からTUNを有効にすると、実行時のstack、dns-hijack、auto-routeが想定と異なる一方、work/config.yamlには完全な設定が残っていたと報告しています。症状を見分ける参考になる報告ですが、すべてのユーザーで同じ項目が失われるという意味ではありません。
どの段階で問題が起きたかを先に確認する
| 症状 | 最初に確認すること |
|---|---|
| スリープ前は使えたが、復帰後にTUNが通信を転送しない | 復帰した時刻を記録し、この修正を含むアプリを実際に使用しているか確認します。 |
| 仮想ネットワークアダプターの画面で設定を保存しても、通信の動作が変わらない | 保存した内容とコアの再起動が完了したかを確認します。サブスクリプションを繰り返し変更しないでください。 |
| TUNがオフでも直接接続できない、またはノード自体に接続できない | 現在のネットワーク、ノード、実際のエラーを先に調べます。今回のTUN修正だけでは説明できません。 |
設定全体の再読み込みとTUNのオン・オフはどう違う？
v2.0.4の固定バージョンのソースコードでは、復帰後にコアが応答し、TUNが有効なはずなのにアダプターが存在しない場合、復旧処理はいったんTUNを無効にしてから、完全な設定を生成してコアへ渡します。旧版のこの処理はスイッチを再びオンにするだけだったため、アダプターの再作成時に不完全な設定が使われる可能性がありました。
新版では、仮想ネットワークアダプターの画面で設定を保存すると、現在のenableの状態を維持して設定を保存し、restartCoreを呼び出します。設定のホットリロードだけを行う処理とは異なります。保存後には通信が一時的に途切れるため、重要なデータ転送中のテストは避けてください。
画面の設定項目、ディスク上の合成済み設定ファイル、実行中のコアでは、確認できる状態が異なります。ファイルに完全なtunセクションがあっても、確認できるのはファイルの内容だけです。コアのログと実際のリクエストも確認し、読み込みと再起動が完了したことを確かめる必要があります。
復元できるコピーを保存してからアプリを更新する
アップグレード前後の確認手順
現在のローカルバックアップをエクスポートする
「アプリ設定 → バックアップと復元」で「バックアップをエクスポート」を選びます。アプリのデータとは別の場所に保存し、読み取れることを確認してください。サブスクリプション、オーバーライド、現在のTUN設定も別途記録し、機密情報は公開しないでください。
現在のアプリとコアのバージョンを確認する
Clash Partyのアプリのバージョンと、実際に動作しているMihomoのバージョンをそれぞれ記録します。v2.0.4はアプリのリリース番号です。コアだけを置き換えても、アプリ側の復帰処理と保存処理の修正が適用されるとは限りません。
プロジェクトの正式版v2.0.4を使う
プロジェクトのReleaseから、OSとアーキテクチャに合うものを選びます。バックアップと使用できる設定を残し、旧版のアプリを完全に終了してから、各環境のインストール手順で更新してください。データの消去、サブスクリプションの変更、DNS全体の調整を同時に行わないでください。
起動後にアプリのバージョンと設定を再確認する
実際に開いたアプリがv2.0.4であり、別の場所に残った旧版ではないことを確認します。選択中の設定、ノード、プロキシモード、元のTUN設定も改めて確認してください。
報告にあるアダプター名、stack、MTU、DNSアドレスをそのままコピーしないでください。それらは報告者の環境の値であり、今回の修正で指定された新しい既定値ではありません。以前使えていた自分の設定を残し、想定と違うことを確認できた項目だけを修正します。
TUN設定を保存したら、コアの再起動を確認する
アプリの「仮想ネットワークアダプター」画面を開き、記録と照らし合わせて、アダプター名、プロトコルスタック、自動ルーティング、DNSの取り込み、除外アドレスを確認します。メニュー名は言語やOSによって異なる場合があるため、実際の画面に従ってください。他のクライアントの操作手順をそのまま当てはめないでください。
設定の修正が必要な場合は、確認できた項目だけを変更して「保存」を押します。v2.0.4は現在のTUNのオン・オフ状態を維持してコアを再起動します。完了を待ってから、新しいリクエストを送ってください。更新失敗と表示された場合は、先にエラーを記録して現在の設定を残します。ボタンを連打したり、スイッチを何度も切り替えたりしないでください。
修正する設定がなければ、保存を実行するためだけにMTUやプロトコルスタックを変える必要はありません。先に中断できないリクエストを一時停止し、アプリを完全に終了してから開き直します。その後、TUNの状態と実際のリクエストを改めて確認してください。
PATCH /configsによる直接変更を通常の修復手順にしないでください。スイッチと設定はアプリが管理しているため、一部だけを書き換えるとアプリの状態と食い違う可能性があります。本記事ではアプリ内での保存と再起動を使います。制御ポートの開放や、一時的な合成済み設定ファイルの編集は必要ありません。
スリープと復帰を一度行って復旧を確認する
まず現在のネットワークとノードで、利用する権限のある通常のウェブページやリクエストを試し、結果を記録します。次に通常の操作でスリープと復帰を行い、ネットワークが戻ってから同じ接続先へ新しいリクエストを送ります。復帰前から続いている接続や、遅延測定の数値だけで判断しないでください。
今回の復旧を確認するチェックリスト
- アプリがv2.0.4で動作しており、選択中の設定、ノード、元のTUN設定が記録され、復元できる。
- 保存した設定が正しく表示され、コアの再起動が完了している。更新失敗やTUN起動エラーが繰り返し発生していない。
- 復帰後も同じドメインの名前解決ができ、同じウェブページやアプリのリクエストが完了する。接続履歴で想定どおりのルールと出口が確認できる。
- アプリを完全に終了して再度開いた後も、現在のTUNの状態と実際のリクエストを確認する。スイッチの色だけで転送が成功していると判断しない。
- テストしたネットワーク、時刻、発生までの操作、結果を残す。一度成功した結果が当てはまるのは今回の環境であり、あらゆるネットワーク条件を検証できたわけではない。
直らないときに通信と設定を保つには？
アップグレードや保存の後も通信できない場合は、まずアプリ内でTUNを無効にし、システムの直接接続が戻るか確認します。一時的な代替手段には、以前に動作を確認できたシステムプロキシだけを使ってください。システムプロキシが扱う通信範囲は異なるため、使えるようになってもTUNが直ったとは判断できません。
今回追加で行った変更を取り消し、記録した元の設定値と使用できるサブスクリプションに戻します。バックアップをインポートする必要がある場合は、先に現在の状態を別途保存してください。アプリの「バックアップをインポート」は現在の設定を上書きします。ファイルとバージョンが適切か確認し、唯一のコピーを繰り返し上書きしないでください。
旧版に戻す必要がある場合は、新版のデータのコピーを残し、アップグレード前に別途保存したバックアップを使います。本記事ではバージョンをまたぐデータの互換性を検証していません。唯一のデータフォルダーを旧版アプリでそのまま上書きしないでください。旧版で今回の修正を利用できるとも保証できません。
不具合を報告するときは、アプリとコアのバージョン、OS、スリープ復帰または設定保存で再現する最短の手順、関連するTUNセクションとエラーログを添えます。サブスクリプションのToken、ノードのパスワード、コントローラーのsecretを削除し、機密情報を含む設定全体はアップロードしないでください。
本記事は正式リリースの記録とv2.0.4の固定バージョンのソースコードを照合して作成しており、すべてのOSの実機で再現したものではありません。権限、ルーティング、DNSに関する他の問題は、実際のログに沿って調べる必要があります。その後の変更は、プロジェクトの新しいリリースとメンテナーの見解を確認してください。