Clashのよくある質問

クライアントはサブスクリプション管理、ポリシー選択、ログ確認、システムネットワーク設定を担い、コアは設定の解析、ルール判定、接続の確立を担います。Clash MetaはClashから派生したコアで、その後mihomoとして開発が続いています。クライアントによって内蔵コアが異なり、コアを切り替えられるものもあるため、画面が似ていても対応するプロトコルや設定項目が同じとは限りません。設定に互換性がない場合は、クライアント名だけで判断せず、アプリ情報やコア情報で実際に動作しているコアを確認し、該当するドキュメントを参照してください。

クライアントは設定や接続を扱うツールであり、インストールするだけで利用可能なリモートプロキシが用意されるわけではありません。サブスクリプションやローカル設定には、プロキシノード、ポリシーグループ、ルールなどが必要です。また、リモートサービス自体が利用可能である必要もあります。読み込む前に設定元の信頼性、使用中のコアがプロトコルに対応しているか、サービスの利用条件を確認してください。ノード一覧だけを含むサブスクリプションは、完全なClash設定ではない場合があります。読み込み方法が対応していれば、クライアント側で設定テンプレートと統合する必要があります。

ルールモードは設定内のルールを上から順に適用してポリシーを選び、日常的な通信の振り分けに適しています。グローバルモードはコアが取り込んだ接続をグローバルポリシーに通すため、一時的な比較やテストに便利です。DIRECTモードは取り込んだ接続を宛先へ直接接続し、リモートノードの影響を切り分けるときに使えます。モードが決めるのはコアに入った後の処理であり、どのアプリの通信をコアに取り込むかではありません。グローバルモードにしても特定のアプリが取り込まれない場合は、ルールを何度も変更するのではなく、システムプロキシやTUNを確認してください。

通信を取り込む場所が異なります。システムプロキシはOSのプロキシ設定を通じて、設定に従うアプリの通信を誘導します。一部のコマンドラインツール、ゲーム、独自のネットワークスタックを使うアプリは、この設定を利用しないことがあります。TUNは仮想ネットワークインターフェースとルーティングを使って対象の通信を取り込み、権限、DNS、ほかのVPNとの併用も関係します。ブラウザーは使えるのにほかのアプリがつながらない場合は、まずアプリが明示的なプロキシ設定に対応しているか確認し、必要に応じてTUNを検討してください。すべての問題で両方を同時に有効にする必要はありません。

プロトコル名が一致することは最低条件です。通信方式、TLS、認証、拡張パラメーターも確認してください。たとえばVLESSの通信方式の組み合わせやHysteria2の帯域幅設定は、コアの対応状況やクライアントの読み込み処理によって制限される場合があります。共有リンク、Clash YAML、ほかのクライアントの設定形式も、それぞれ別のものです。サービス提供元が明示的に対応している形式を優先し、読み込み後にノードの種類や重要なパラメーターを確認してください。エラーを消すために認証やセキュリティ関連の項目を安易に削除しないでください。

クライアントの設定またはサブスクリプション画面でリモート設定を追加し、リンク全体を貼り付けて保存します。ダウンロードと解析が終わったら、その設定を使用中にします。次にポリシーグループを開いて利用可能なノードを選び、システムプロキシを有効にするか、必要に応じてTUNを有効にして、最後に接続ログを確認します。ボタン名はクライアントによって異なりますが、ダウンロード、設定の有効化、通信の取り込みはそれぞれ独立した段階です。サブスクリプションリンクにはアクセス情報が含まれる場合があるため、公開画像やオンライン変換サイト、掲示板などに貼り付けないでください。

まず更新ログを確認し、ドメインの名前解決失敗、接続タイムアウト、HTTPステータスエラー、設定の解析エラーを区別します。401または403が返る場合は、アカウントの状態とリンクの認証を確認してください。404の場合は、URLが変更されていないか確認します。リクエストが成功しても解析できない場合は、ログイン画面やエラーページ、非対応形式をダウンロードしている可能性があります。クライアントが提供する選択肢に従ってDIRECT接続または既存のプロキシ経由で更新し、使えなくなったノードがダウンロードに影響しないようにしてください。短時間に何度も再試行したり、サブスクリプションURL全体を公開したりしないでください。

まず元の設定を残し、ログで最初にエラーが出た箇所を確認します。項目が未対応の場合は、コアの機能と設定形式を確認してください。ポリシーグループが見つからない場合は、ルールの宛先、グループ名、ノード名が大文字・小文字や空白も含めて完全に一致しているか確認します。YAMLのインデントにはスペースを使い、リストの階層も正しく設定してください。サブスクリプションから生成された設定なら、手作業の変更が次回更新で上書きされないよう、サブスクリプションのテンプレートまたはクライアントのオーバーライド設定を修正します。一度に変更するのは1か所だけにし、その都度クライアントの設定チェックを実行してください。

TUNは仮想ネットワークインターフェースとシステムルートを扱うため、通常は適切な権限が必要です。デスクトップクライアントにサービスモードや特権ヘルパーがある場合は、まず案内に従ってインストールと権限設定を行い、昇格が必要な処理はサービスに任せてください。画面を常に管理者として実行する方法を、最初から選ぶ必要はありません。サービスを導入しても失敗する場合は、サービスの起動状態、仮想ネットワークインターフェースの作成状況、セキュリティソフトによるブロックを確認します。モバイル端末ではシステムのVPN設定を許可する必要があります。許可しないと、該当する通信取り込み機能は利用できません。

mixed-portはHTTPとSOCKSの両方のプロキシ接続を受け付ける待ち受けポートです。アプリのプロキシ設定には、コントロール用ポートではなく、実際に待ち受けているアドレスとポートを入力します。自分の端末だけで使う場合は、ループバックアドレスでの待ち受けで十分です。LAN内の端末から使う場合は、allow-lan、バインドアドレス、OSのファイアウォール、認証設定を確認し、信頼できるネットワークだけにアクセスを制限してください。プロキシの待ち受けポートやコントロール用ポートをインターネットに直接公開しないでください。ポートを変更した場合は、アプリの明示的なプロキシ設定も更新します。

特定のノードを選択してから、新しい接続を発生させます。クライアントの接続一覧で宛先ドメイン、適用ルール、ポリシーグループ、実際に使用されたノードを確認してください。必要に応じて対象アプリの既存接続を終了してから再起動します。確立済みの接続では、以前の出口が引き続き使われる場合があるためです。出口IPの確認は参考になりますが、ブラウザーのアイコン、システムプロキシのスイッチ、ノードのテスト成功だけでは判断できません。アプリが独自のプロキシやVPNを使っている場合は、別経路の影響を先に取り除いてください。そうしないと、テスト結果が別の接続を示している可能性があります。

ルールは通常、上から順に照合され、最初に一致したルールのポリシーが適用されます。条件を絞ったカスタムルールは、先に一致する可能性のある広いルールより上に配置し、指定したポリシーグループが存在することも確認してください。サブスクリプションの設定では、生成ファイルを直接編集すると更新時に上書きされるため、クライアントのオーバーライド機能やルール統合機能を使うのがおすすめです。確認時は現在の設定を再読み込みし、新しい接続のルール判定ログを見てください。アプリがIPアドレスで接続し、コアがドメイン情報を取得できない場合は、ドメインルールに一致しないことがあります。DNSと通信の識別方法もあわせて確認してください。

Fake-IPは、ドメイン名と接続の対応関係を維持するためにコアが割り当てる仮想アドレスで、接続先サーバーの実際のグローバルIPではありません。アプリがこのアドレスを受け取った後の接続は、コアが取り込む必要があります。LAN内のデバイス検出や管理機能、実際の名前解決結果を必要とするアプリでは、例外設定が必要な場合があります。すべてのドメインを一律に除外するのではなく、対象のドメインごとにフィルターやDNS経路を設定してください。DNSモードを切り替えた後は、対象アプリを再起動して関連キャッシュを消去すると、古いマッピングの影響を避けられます。

自動更新では通常、リモート設定やプロキシプロバイダーのデータが更新されます。ポリシーの選択が維持されるかどうかは、クライアントの保存方法やポリシーグループ名が安定しているかによって異なります。リモート設定ファイルに直接加えた変更は、次回のダウンロードで置き換えられる可能性があります。固定ルールやDNSの変更はクライアントが対応するオーバーライド層に設定し、更新後に最終的な有効設定を確認してください。設定全体の更新とproxy-providersの更新は別の操作です。スケジュール更新を設定する前に、クライアントがどちらの更新方法を提供しているか確認しましょう。

コマンドラインツールがデスクトップのシステムプロキシを参照するとは限りません。まずツールのドキュメントを確認し、対応するプロキシ引数、専用設定、環境変数を使って、クライアントが実際に待ち受けているローカルアドレスとポートを指定します。HTTP_PROXY、HTTPS_PROXY、ALL_PROXYや変数名の大文字・小文字への対応はツールごとに異なり、1つの変数を設定すればすべてのプログラムで使えるとは限りません。テスト後に不要になった設定は、該当するターミナルのセッションまたは設定ファイルから削除してください。クライアントを終了しても明示的なプロキシ設定が残っていると、ツールは存在しないローカル接続先に接続し続けます。

サブスクリプションのダウンロード先とノードのサーバーは別の接続先です。サブスクリプションを更新できても、ノードが使えるとは限りません。まずアカウント、通信量、サービスの稼働状況を確認し、同じグループ内の別ノードと比較します。一部のノードだけ失敗する場合は、そのノードのサービスを優先して確認してください。すべて失敗する場合は、端末のネットワーク、ドメインの名前解決、システム時刻、コアのプロトコル対応を確認します。Hysteria2やTUICなどではUDP経路も必要です。テスト用URL自体に接続できないとタイムアウトするため、実際のアクセス状況と接続ログをあわせて判断してください。単一のテスト結果だけでクライアントを何度も再インストールしないでください。

まずコアが正常に動作していることと、ローカルプロキシのポートが待ち受け中であることを確認し、OSの設定にあるアドレスとポートを照合します。ブラウザーの拡張機能、組織のポリシー、個別のプロキシ設定がシステム設定を上書きしていないか、接続先がプロキシの除外リストに入っていないかも確認してください。次に、クライアントに新しいリクエストが記録されるか確認します。接続記録がない場合は通信を取り込む入口に問題がある可能性が高く、記録がある場合はルール、ポリシー、ノードを確認します。プロキシ設定を変更するほかのプログラムを終了してからテストし、スイッチの表示と実際のOS設定が食い違わないようにしてください。

アプリコンテナーで分離された一部のWindowsアプリは、ローカルのループバックプロキシに直接接続できません。その場合は、対象アプリにループバックの除外設定が必要なことがあります。まず通常のデスクトップブラウザーが同じプロキシを使えることを確認し、クライアントのUWPループバックツールまたはシステム管理ツールを使って、必要なアプリだけを選び、案内に従って許可してください。ストアアプリがすべて同じネットワーク方式を使うわけではないため、接続の問題をすべてループバック制限のせいにすることはできません。TUNに切り替えた場合も、ルーティング、DNS、アプリの接続記録を確認してください。

まずTUNを無効にし、ほかのVPNや同種の通信取り込みツールも一時停止して、通常のネットワーク接続が戻るか確認します。その後、通信を取り込む方法は1つだけ有効にし、デフォルトルート、DNS設定、仮想ネットワークインターフェースの状態を確認してください。クライアントを終了しても問題が続く場合は、クライアントのサービス停止機能やネットワーク設定の復元機能を使い、手動で設定したプロキシやDNSが残っていないか確認します。役割が分からないまま、システムルートやネットワークインターフェースをまとめて削除しないでください。通常の接続が戻ったら、ログを確認しながら機能を1つずつ有効にし、問題が発生する最小の設定を特定します。

ポートが使用中の場合は、別のクライアント、古いコアのプロセス、バックグラウンドサービスが同じアドレスを待ち受けていないか確認してください。正体の分からないシステムプロセスをすぐに終了しないでください。重複しているインスタンスを停止するか、待ち受けポートを変更してアプリのプロキシ設定も更新します。クライアントを終了した後にネットへ接続できなくなる場合は、システムプロキシが無効になっているか、ブラウザー拡張やターミナルの環境変数がローカルポートを参照したままになっていないか確認します。TUNを使っている場合は、サービスとルートが正常に終了したことも確認してください。自動起動を利用していると、画面を閉じてもバックグラウンドのコアが停止しているとは限りません。それぞれの状態を確認しましょう。