プロジェクトの変遷と設定の引き継ぎ
初期のClashクライアントでは、YAMLでプロキシと振り分けルールを記述する方法が広まりました。元のプロジェクトのメンテナンス状況が変化した後も、コミュニティ製クライアントや後継コアの開発は続いています。そのため、古いガイドにあるボタン名、ダウンロード先、拡張項目が現在の環境に合わないことがあります。移行時は設定の基本構成を引き継ぎつつ、コアが対応する項目を再確認してください。特にDNS、TUN、外部リソースのパスに注意が必要です。過去の設定を読み込めても、それは解析に成功したことを示すだけで、元の環境とすべて同じ動作になるとは限りません。
画面上の操作と実際に適用される設定
クライアントは通常、設定のダウンロード、ポリシーの選択、トレイメニュー、システムサービスを担当し、コアはポートの待ち受け、ルールの照合、接続処理を担当します。画面のスイッチによって起動前に設定ファイルが生成されたり、実行中に制御インターフェース経由で設定が変更されたりすることがあります。そのため、サブスクリプションのファイルを編集した後、画面の表示と実際の値が一時的に異なる場合があります。トラブル時は、選択中の設定、実行ログ、接続の詳細を先に確認し、上書き設定が有効か調べてください。サブスクリプション、画面上のポート、システムプロキシを同時に変更すると、どの変更が結果に影響したのか分かりにくくなります。
更新の種類と設定のバックアップ
クライアント、コア、サブスクリプション、ルールの更新は、それぞれ別の操作です。クライアントを更新しても期限切れのサブスクリプションが自動修復されるわけではなく、サブスクリプションを再取得しても古いコアが新しい項目に対応するわけではありません。メンテナンスの前にローカルの上書き設定とカスタムルールを保存し、製品のリリースノートを確認してから、一度に1つの層だけを更新してください。更新後は同じアプリと接続先で再テストし、結果の違いを記録します。元に戻す必要がある場合、設定のバックアップがあればスイッチの状態を記憶に頼って復元せずに済みます。サブスクリプションURLにはアクセス情報が含まれる場合があるため、公開の場やスクリーンショットに載せないでください。
ソースコードと不具合の報告
オープンソースのリポジトリでは、項目の定義、ライセンス、既知の問題を確認できますが、あらゆるクライアントのインストーラーをダウンロードするための代替先ではありません。mihomoのリポジトリにはコアの変更が記録されています。画面のボタンが反応しない、サービスのインストールに失敗するといった問題は、まず対象のクライアントを特定してください。不具合を報告する際は、OS、アーキテクチャ、再現手順、個人情報を除いたログを添えて、サブスクリプションURL、プロキシの認証情報、外部コントローラーのキーは削除します。特定のアプリだけが通信できない場合は、接続失敗とだけ書かず、システムプロキシやTUNで通信を取り込んでいるかも説明してください。
初回接続時の確認手順
まず現在の設定を正常に読み込めることを確認し、次に対象アプリの通信がクライアントに取り込まれているかを調べ、最後にルールと接続先のポリシーを確認します。システムプロキシが有効なのに接続記録が表示されない場合は、アプリがシステムプロキシを参照しているかを先に確認してください。記録はあるのに接続先へ到達できない場合は、一致したルール、ドメインの名前解決、選択中の接続先を調べます。遅延テストの結果は、テスト対象と方法に左右されます。ウェブページ、ターミナル、ほかのアプリがすべて正常に使えることの証明にはなりません。問題を段階ごとに調べることで、権限・設定・ネットワークの問題を混同せずに済みます。
操作の全体像を確認するには、サブスクリプションの追加と初回接続ガイドから始めてください。設定の読み込みや接続で問題が起きた場合は、よくある質問とトラブルシューティングをご覧ください。インストール、システム権限、プラットフォーム固有の設定は全プラットフォームガイドにまとめています。端末ごとに順番に確認できます。