オリジナルのコアから後継のメンテナンスブランチへ
オリジナルのClashは、設定ファイル、プロキシグループ、ルール振り分けを使って通信を管理する方法を確立しました。オリジナルのプロジェクトがメンテナンスを終了した後も、エコシステムのクライアントすべてが停止したわけではなく、後継コアを採用したものや既存機能を維持するものがあります。Metaは重要な機能拡張ブランチで、mihomoは同じコアの系譜を引き継いでメンテナンスを続けています。そのため、クライアント名にClashが含まれていても、使用コアや対応プロトコル、設定の互換性まで判断できるわけではありません。
ガイドを読むときは、まず対象がコアかクライアントの画面かを確認しましょう。YAMLの項目を説明する資料はコアに関するもの、トレイ、設定のオーバーライド、バックグラウンド権限の手順はクライアントやシステムに関するものが一般的です。両者を分けて理解すれば、スマートフォンの画面でデスクトップ専用のメニューを探したり、アプリ固有の設定をサブスクリプションに書き込んだりする誤りを防げます。
GUIとコアは別々に更新
FlClashやClash Verge RevなどのGUIクライアントは、コアの機能を使ってサブスクリプション管理、プロキシグループの選択、システムへの通信取り込みを行います。画面の更新は操作方法だけを変える場合もあれば、コアも同時に更新する場合もあります。コアの更新によって、プロトコル対応、DNSの動作、設定項目の要件が変わることもあります。クライアントを選ぶ際は、名前だけで互換性を判断せず、必要な機能が明示的に対応しているか確認してください。具体的な違いはクライアント選びガイドで比較できます。
モバイル端末では、システムのバックグラウンド動作やネットワーク拡張の権限にも制約があります。デスクトップで使えるスクリプト、プロセス単位の振り分け、システム連携機能が、スマートフォンにもあるとは限りません。複数の端末で同じ設定を使う場合は、共通ルールを設定ファイルにまとめ、バッテリー最適化、自動起動、システムプロキシなどは各クライアント側で設定しましょう。
設定の互換性は項目ごとに確認
同じYAML形式でも、異なるコアが同じ設定をすべて読み込めるとは限りません。プロトコル名、通信パラメーター、ルールセット、DNSの設定項目には対応状況の違いがあります。インポート時に不明な項目や未対応のプロキシ種別が表示されたら、エラー内容を保存し、まずコアの対応状況を確認しましょう。項目をむやみに削除すると、読み込みに成功しても元の振り分けや名前解決の動作が変わるおそれがあります。サブスクリプションの変換も、変換先が表現できる機能の範囲内でしか行えません。
プロトコルに一律の順位はなく、ネットワーク品質、サーバー側の実装、通信方式、スマートフォンの無線状態によって使い勝手は変わります。接続の安定性やバッテリー消費を比較するには、ほかの条件をそろえ、実際の通信、再接続の状況、バックグラウンドでの使用をそれぞれ確認しましょう。プロトコルの選び方とDNSの名前解決と通信の取り込みは、技術ガイドで利用シーンごとに説明しています。
更新前に設定を記録し、更新後は一部の通信で確認
クライアントの更新、コアの更新、サブスクリプションの更新はそれぞれ別の操作です。前の2つはソフトウェアを変更し、後者はリモート設定の内容を更新します。更新前に現在のモード、重要なプロキシグループの選択、ローカルオーバーライドを記録し、必要な設定はクライアントのエクスポート機能で保存しておきましょう。更新後は、よく使うサービスを1、2件確認してから、ルールの適用状況とバックグラウンド接続を確認します。すべての設定をすぐにやり直す必要はありません。
オープンソースのコードは実装の確認、問題の議論、修正履歴の追跡に役立ちますが、公開リポジトリを見るだけで特定のリリース内容を確認したことにはなりません。問題が起きたら、まず再現手順を絞り込み、OS、クライアント、エラー内容、試した操作を整理しましょう。ログにはアクセス先のドメイン、サーバーアドレス、サブスクリプションの認証情報が含まれる場合があります。報告を送る前に、問題の再現に不要な個人情報を取り除いてください。