Clashのよくある質問

クライアントはサブスクリプション管理やモード切り替え、システムとの連携を担い、コアは設定の読み込み、ルール判定、接続を担います。mihomoはClash Metaから引き継がれたコアプロジェクトです。画面上の名称とコアの名称は異なる場合があります。サブスクリプションは設定を取得するリモートの配信元で、通常はサービス提供元が管理します。クライアントをインストールしただけでは、利用可能なサブスクリプションは手に入りません。問題が起きたら、画面操作、コアのエラー、サブスクリプションの内容のどこに原因があるかをまず確認しましょう。

サブスクリプションURLからはリモートの設定を再取得できますが、ローカルのYAMLは端末に保存した設定のスナップショットです。リモートの更新によって、既存のプロキシ項目、プロキシグループ、ルールが置き換わることがあります。ローカルファイルは通常、手動で編集するか再インポートします。プロキシ項目だけを返すURLは、完全な設定にプロキシプロバイダーとして追加する必要があり、Profile全体としては使えません。インポート前にクライアントが求める形式を確認し、正常に使えている設定のコピーを残しておきましょう。

普段はルールモードを選び、現在の設定に従って接続を各ポリシーへ振り分けるのが一般的です。グローバルモードでは、コアが受け取った接続をグローバルポリシーグループで処理しますが、そのグループ内で利用可能な出口を選ぶ必要があります。直接接続モードでは、コアが受け取った接続を宛先へ直接つなぎます。これらのモードが影響するのはクライアントが取り込んだ通信だけで、端末上のすべてのアプリが対象になるわけではありません。切り分けのために一時的にグローバルモードで比較したら、確認後はルールモードに戻し、ルールの問題をノード障害と誤認しないようにしましょう。

システムプロキシはHTTPまたはSOCKSのプロキシ設定をOSに登録し、その設定に従うアプリで利用できます。TUNモードは仮想ネットワークインターフェースを通じて、ルーティング条件に合う通信を取り込みます。システムプロキシを参照しないアプリにも向いていますが、適切な権限やルーティング、DNSの設定が必要です。初めて設定する場合は、まずシステムプロキシだけを有効にして動作を確認し、必要に応じてTUNを試しましょう。クライアントによっては両方を有効にできますが、必須ではありません。切り分けでは個別に試し、条件を増やさないことが大切です。

Fake-IPモードでは、設定されたアドレスプールから割り当てたIPアドレスをアプリに返し、コアが対応表を使ってドメイン名を特定して接続を処理します。そのため、DNSの応答が接続先の実際のIPアドレスと異なる場合がありますが、それだけで名前解決に失敗したとは限りません。一部のLANサービスや実IPアドレスを必要とするアプリでは互換性の問題が起きることがあるため、除外範囲を広げるのではなく、該当ドメインに例外を設定しましょう。DNSモードを変更した後は、クライアントの手順に従って再読み込みし、OSやアプリに残った古いDNSキャッシュも処理してください。

設定またはサブスクリプションの画面で、新しい項目のダウンロードが完了したことを確認してから、選択、有効化、または現在の設定として適用します。ボタン名はクライアントによって異なります。サブスクリプションURLを保存しただけでは、コアに設定が読み込まれたとは限りません。その後、ログの読み込み結果とプロキシグループの画面を確認します。ダウンロードに成功してもグループが表示されない場合は、内容がプロキシ項目だけではないか、クライアントが対応する形式かを確認してください。古い設定は残し、現在有効な項目が分からなくならないよう、同じURLを続けて何度もインポートしないでください。

まず端末の時刻、通常のネットワーク接続、サブスクリプションURLが完全かを確認します。コピー時に空白や改行が入っていないかも確認してください。次に更新ログを確認します。401や403は認証やアクセス制限、404はURLの無効化、タイムアウトは接続経路に問題がある可能性を示します。ステータスコードはあくまで手掛かりなので、提供元の案内を優先してください。クライアントにサブスクリプション取得用プロキシの設定があれば、直接接続と利用可能なプロキシの両方を試します。それでも失敗する場合は提供元にURLの状態を確認し、認証情報を含むURL全体を公開しないでください。

まずログに記録されたフィールド名、プロキシタイプ、行番号を控え、クライアントが実際に使用しているコアとそのバージョンを確認します。新しい設定に含まれるプロトコルやパラメーターが、古いコアでは未対応の場合があります。画面を更新してもコアが同時に更新されるとは限りません。手動編集した場合は、YAMLのインデント、コロンの後の空白、リストの階層を確認し、タブは使わないでください。まず提供元に互換性のある形式での出力を依頼するか、設定に対応するクライアントを選びましょう。エラーのフィールドをむやみに削除して元ファイルに上書きしないでください。

まずクライアントでサービスモードのインストールや起動が必要かを確認し、OSの正規の認証手順で必要な権限を許可します。Windowsではバックグラウンドサービスの状態、macOSではシステムの許可ダイアログ、Linuxではクライアントのドキュメントに記載された権限や仮想インターフェースの要件を確認してください。次にログを見て、権限不足、インターフェース作成失敗、ルートの競合がないかを調べます。常に最高権限で実行することを一般的な解決策にしないでください。ほかのVPNやTUNを使うアプリを終了し、クライアントのドキュメントに従ってサービスを復旧しましょう。

移行前に、サブスクリプションの取得元、ローカルのYAML、クライアントのオーバーライド設定をそれぞれ保存します。必要に応じて、プロキシグループの選択やポート設定も記録してください。古いクライアントを終了し、システムプロキシとTUNを無効にしてから、新しいクライアントにコピーをインポートします。使用するコアが設定内のプロトコルやフィールドに対応しているかも確認しましょう。画面設定やデータベースの形式が異なる場合があるため、アプリのデータフォルダー全体をそのままコピーするのは避けてください。新しいクライアントで設定の読み込み、接続テスト、再起動後の動作を確認してから、古いアプリと設定を削除するか判断します。

サブスクリプション項目の設定で自動更新のオン・オフと更新間隔を確認し、提供元の推奨頻度に合わせて設定します。更新頻度が高すぎると、アクセス制限を受けることがあります。リモートのサブスクリプションは通常、内容を再ダウンロードするため、取得したファイルを直接編集すると更新時に置き換わるおそれがあります。長期的に保持したいルールやDNS設定は、クライアントが対応しているオーバーライド、マージ、拡張設定に追加するのがおすすめです。更新後は編集画面だけでなく、最終的に適用された設定とログを確認し、独自の設定が残っていることを確かめましょう。

手動選択グループは通常selectに対応し、ユーザーが現在の接続先を選びます。自動テストグループは通常url-testに対応し、設定されたテストURL、間隔、許容値に基づいて接続先を選びます。fallbackは利用可能な接続先を順番に使う仕組みで、常に最速の回線を選ぶという意味ではありません。テスト結果が示すのは指定URLへの疎通状況であり、あらゆる通信での実際の使い心地とは異なります。切り替え後は新しい接続で確認してください。既存の長時間接続には、切り替え前の接続先が使われ続ける場合があります。

まずクライアントでLAN接続の許可、リッスンアドレス、混合ポートの設定を確認します。次に、同じ信頼できるネットワーク上の端末に、PCのLAN内IPアドレスと対応するポートを設定します。OSのファイアウォールで、そのネットワークからの接続が許可されていることも確認してください。LANでのリッスンを有効にしただけでは、ほかの端末が自動的にプロキシを使えるわけではありません。利用する端末側でプロキシを設定するか、明確なゲートウェイ構成が必要です。プロキシポートをインターネットに公開せず、利用後は必要に応じてLANアクセスを無効にし、ファイアウォールの例外も削除してください。

多くのコマンドラインツールは、独自の引数やHTTP_PROXY、HTTPS_PROXY、ALL_PROXYなどの環境変数だけを参照し、デスクトップのシステムプロキシ設定は参照しません。まずクライアントのローカルリッスンアドレスとポートを確認し、使用するツールが対応する環境変数、プロキシプロトコル、変数名の大文字・小文字の扱いを調べましょう。HTTPS_PROXYの値にhttps://を指定するとは限りません。まずは現在のターミナルセッション内でテストし、全体設定の起動ファイルにはすぐ書き込まないでください。テスト後は一時的な環境変数を削除し、クライアント終了後にターミナルが古いポートを参照し続けないようにします。

OS、クライアント名、コアのバージョン、エラー発生時刻、再現手順を記録し、該当時間帯の読み込みエラーや接続エラーを抜粋してください。共有する前に、サブスクリプションURL全体、アクセストークン、アカウント名やパスワード、個人用ドメインなど、個人やサービスを特定できる情報を削除します。原因の特定にログレベルを一時的に上げた場合は、完了後に通常のレベルに戻してください。設定フォルダー全体や、内容を確認していない診断用アーカイブをそのままアップロードしないでください。YAMLを掲載する場合はフィールド構造を保ち、機密値を明確なサンプル値に置き換えましょう。

まずプロキシを無効にして、通常のネットワーク接続が使えることを確認します。次にサブスクリプションが正常に更新されているか、現在のプロキシグループで利用可能な接続先を選んでいるかを確認してください。同じ接続先から複数の宛先へアクセスし、可能であれば別のネットワークでも比較します。ログにドメイン名の解決失敗がある場合はDNSを確認します。接続確立時にタイムアウトする場合は、ノードのアドレスやポート、接続経路を調べてください。内蔵テストの結果はテスト先への接続状況に限られ、1つのノードがタイムアウトしても、サブスクリプション全体が無効とは限りません。最初からすべての設定をリセットするのは避けましょう。

まずOSに登録されたプロキシのアドレスとポートが、クライアントの実際のリッスン設定と一致しているか確認し、コアが正常に動作していることも確かめます。次にブラウザーのプロキシ拡張機能、個別のプロキシ設定、PAC、バイパスリストを確認します。必要であれば、一時的なブラウザープロファイルで比較してください。クライアントの接続ログを開いて新しいリクエストを送信し、記録がまったくない場合はまず通信の取り込み経路を調べます。記録があるのに直接接続される場合は、適用されたルールを確認します。ページが開くかどうかだけでプロキシの動作を判断したり、DNSとルーティングを一度に変更したりしないでください。

AppContainerで隔離された一部のWindowsアプリは、ローカルのループバックプロキシに直接アクセスできません。そのため、ブラウザーは使えても特定のアプリだけ接続できないことがあります。まず対象のアプリがローカルプロキシを使っていることを確認し、クライアントにUWPループバックやループバックの免除ツールがあるか調べてください。免除は必要なアプリだけに設定し、ツールの案内に従って許可します。Microsoftのドキュメントに従い、CheckNetIsolationで確認する方法もあります。すべてのストアアプリが同じ制限を受けるわけではありません。解決しない場合は、アカウント、システムネットワーク、ファイアウォールも確認してください。

まずTUNを無効にして比較し、仮想インターフェースやルーティングによる通信の取り込みが原因かを確認します。次に、別のVPN、仮想マシンのネットワーク、セキュリティソフトが同時にルートを変更していないか、対象サービスがLAN内の機器検出や専用DNSに依存していないかを調べます。必要に応じて、使用中のコアとクライアントのドキュメントに従い、特定のネットワーク範囲、インターフェース、ドメインをバイパス設定します。一度に広すぎるアドレス範囲を除外しないでください。一度に1項目だけ変更してテストし、社内ネットワークの設定はネットワーク管理者の指示を優先してください。

まずOSにローカルポートを指す手動プロキシやPACのアドレスが残っていないか確認し、使えなくなったプロキシ設定を無効にします。以前TUNを有効にしていた場合は、元のクライアントを再起動し、TUNとシステムプロキシを無効にしてから通常の手順で終了し、クリーンアップを実行させます。次に、ほかのVPN、ターミナルのプロキシ環境変数、DNS設定が有効なままになっていないか確認してください。ネットワークアダプターを削除したり、ネットワーク設定をすべてリセットしたりするのは避けましょう。通常のネットワーク接続にも問題が残る場合は、OSの診断結果に基づいて対処し、変更前の設定も記録しておきます。