Clashのよくある質問とトラブル対処

Clashは、プロキシ用コアや関連する設定エコシステムを指す一般的な呼び方です。mihomoはこのエコシステムで開発が続くコアで、以前はClash Metaとも呼ばれていました。Clash Verge Revは、設定管理やプロキシの切り替え、システム設定へのアクセス機能を備えたデスクトップクライアントです。クライアントの画面と実際に動作するコアは別の層にあります。YAMLの各項目が使えるかどうかは、クライアントに搭載されたコアとそのバージョンによって異なります。問題を調べる際は、まず「概要」画面でクライアント名を確認し、コア情報または起動ログでコアを特定しましょう。別のクライアントのメニュー位置をそのまま当てはめないようにしてください。

クライアントは設定を読み込んで通信を中継するソフトウェアであり、インストールしただけで利用可能なプロキシサービスが使えるようになるわけではありません。サブスクリプションURLは通常、サービス提供元から発行され、ノードやプロキシグループ、ルールなどの設定を取得するために使います。提供元のサブスクリプションページを開き、Clashまたはmihomoに対応した設定URLを選んでから、クライアントの設定画面でリモート設定として追加してください。アカウントのログインページのURLをサブスクリプションURLとして使わないでください。また、URLに含まれる認証情報から他人が設定を取得できる場合があるため、公開の場に貼り付けないようにしましょう。ローカルに設定ファイルがある場合は、ファイルから読み込むこともできます。

普段はルールモードを選び、読み込み済みの設定にあるルールに通信先を振り分けさせましょう。グローバルモードでは通常、コアに届いた接続がグローバル用のポリシーで処理されますが、すべてのアプリの通信が制御されるわけではありません。システムプロキシやTUNが有効かどうかも確認してください。直接接続モードでは、コアが受け取った通信を宛先へ直接接続します。一時的に接続状況を比較する場合に便利です。テストではモードだけを切り替え、DNSやノードは同時に変更しないでください。グローバルモードで特定のサイトだけ開ける場合は、グローバルモードを常用して設定の問題を覆い隠すのではなく、ルールの照合結果とプロキシグループの選択を確認しましょう。

システムプロキシは、プロキシのアドレスをOSの設定に登録し、その設定に従うアプリの通信に適用します。TUNは仮想ネットワークインターフェースとルーティングを使って、対象となる通信を取り込みます。通常、追加の権限が必要です。接続するために両方を有効にする必要はありません。まずシステムプロキシだけでブラウザーの接続を確認し、ゲームやコマンドラインなどのアプリで必要に応じてTUNを試してください。クライアントによっては両方を併用できますが、通信を取り込む範囲はルーティングや除外設定にも左右されます。TUNを有効にして問題が起きた場合は、いったん無効にして比較し、原因がルーティングによる通信の取り込みなのか、プロキシサービス自体なのかを確認しましょう。

まず設定画面に戻り、追加した設定が一覧に保存されているだけでなく、現在の設定として選択されていることを確認してください。次に更新履歴とコアのログを見て、ダウンロードが成功したか、YAMLが正常に解析されたかを確認します。設定によってはproxy-providersを使ってノードを別途取得します。メイン設定の読み込みに成功しても、ノードプロバイダーが更新済みとは限らないため、プロバイダー画面でも確認してください。提供元からログインページやエラーメッセージが返された場合、またはクライアントが対応していない形式の場合は、対応するURLを再取得しましょう。同じ名前の設定を何度も作成するのではなく、比較用に1つ残して確認してください。

まず提供元のアカウントページで、契約の期限切れや通信量の上限到達、URLの再発行がないか確認してください。401は通常、認証に関するエラーです。403はアクセス拒否を示しますが、詳しい原因は提供元の案内を確認してください。サブスクリプションURLを先頭から末尾までコピーし直し、誤って含まれた空白や改行を取り除いてから、既存の設定のURLを置き換えて手動で更新します。別のネットワークでは使える場合、現在のネットワークがリクエストを遮断していないか確認しましょう。問い合わせにはエラーコードと機密情報を伏せたログだけを添え、URL全体は載せないでください。更新ボタンを何度も押しても、サーバー側のアクセス制限は通常解除されません。

まず通常のシステムプロキシで接続できることを確認してから、TUNの権限を調べましょう。デスクトップクライアントでは、サービスモードのインストールや起動が必要な場合があります。Windowsではクライアントの設定画面でサービスの状態を確認し、案内に従って許可してください。macOSでは該当するシステム権限の許可が必要です。Linuxではクライアントのドキュメントに従ってサービスや必要な権限を設定し、ディレクトリ全体に安易に書き込み権限を与えないでください。許可した後にクライアントを再起動し、デバイスの作成、ルートの設定、インターフェースへのアクセスに失敗した記録がログに残っていないか確認します。会社などで管理されている端末の場合は、管理者に権限ポリシーを確認し、システムの制限を繰り返し回避しようとしないでください。

AppContainerで分離された一部のWindowsアプリは、既定ではローカルのループバックアドレスにアクセスできません。ブラウザーでは接続できるのにストアアプリでは失敗する場合、ループバック制限を確認しましょう。クライアントにUWPループバックツールがある場合は、管理者として起動し、ローカルプロキシへのアクセスが必要なアプリだけを選択します。保存後、対象アプリを完全に終了してから再起動してください。設定画面の名称はクライアントによって異なります。ツールがない場合は、Windowsのループバック除外に関する説明を確認しましょう。必要なアプリだけに許可し、すべてを一括選択しないでください。ループバックの除外では、サブスクリプションの失効、リモートノードの障害、アプリ自体のネットワーク制限は解決できません。

まず提供元が推奨する更新間隔に従いましょう。特に指定がなければ、サブスクリプションへの過剰なリクエストを避けるため、1日1回程度から設定するのがおすすめです。リモート設定を更新すると、リモートYAMLを直接編集した内容は上書きされることがあります。独自のルール、DNS、ポリシーの変更は、クライアントが対応するオーバーライドやマージ設定に追加してください。設定後に手動で一度更新し、最終的に適用された設定に変更が残っているか確認しましょう。マージ順序や配列の扱いはクライアントによって異なるため、クライアントを移行した際は必ず再確認してください。オーバーライドファイルをコピーしただけで同じ結果になるとは限りません。

用途やサービス提供元などで区別できる名前を設定ごとにつけ、すべてを既定の名前のままにしないようにしましょう。切り替える際は、設定画面で目的の設定を現在の設定に指定し、プロキシ画面でプロキシグループや選択可能なノードも切り替わったことを確認します。切り替え後も、既存の接続が以前の経路を一時的に使い続ける場合があります。テスト前に対象アプリを終了して再起動するか、クライアントの接続管理機能で関連する接続を終了してください。新しい設定が使えることを確認してから古い設定を削除しましょう。削除前に必要なローカルルールを保存し、リモートサブスクリプションとローカルのオーバーライドが別々に保存されていないか確認してください。

クライアントの接続画面を開いてから対象サイトにアクセスし、ドメイン名または宛先アドレスで新しい接続を探します。適用されたルール、プロキシグループ、最終的な接続先を確認してください。既存の接続にはルールが再適用されないことがあるため、テスト前に古いページを閉じるか、該当する接続を終了します。画面にIPアドレスしか表示されない場合は、ログも確認してDNSが解決されたか、ルールがドメイン情報に依存しているかを調べましょう。通信がフォールバックルールに一致している場合は、対象のルールがフォールバックルールより前にあるか、ルールセットが正常に読み込まれているかを確認してください。プロキシ画面で特定のノードが選択されているだけで、すべてのサイトがそのノードを使っているとは限りません。

OS、クライアント名、クライアントとコアのバージョンに加え、問題が起きたときのモード、システムプロキシ、TUNの状態を伝えてください。どの種類のアプリを開くとどのようなエラーが出るかなど、再現可能な操作を説明し、同じネットワーク上のほかのアプリは正常に動作するかも記載します。ログは失敗した操作の前後だけを抜き出し、エラーコードと必要な前後関係を残してください。公開前にサブスクリプションURL全体、認証情報、ノードのパスワード、個人アカウント、不要なグローバルIPアドレスを伏せましょう。設定ファイルを丸ごと公開せず、関連する項目だけを抜き出して機密情報を置き換えてください。情報の露出を抑えながら、原因を調べやすくできます。

まずプロキシを無効にして、基本のネットワーク接続ができることを確認します。次に、端末の日付と時刻が正しいか、サブスクリプションが有効か、設定の更新が完了しているかを確認してください。利用可能と分かっているノードを1つ選んでテストし、ログからドメイン名の解決失敗、接続拒否、ハンドシェイク失敗のどれに該当するか調べましょう。テスト先に到達できない場合も速度測定がタイムアウトするため、実際のアクセス結果とあわせて判断してください。すべてのノードで同時に失敗する場合は、DNS、ネットワーク制限、ローカル設定を優先して確認します。1つのノードだけ失敗する場合は、別のノードに切り替えて提供元に問い合わせてください。ポート、DNS、ルーティングを同時に変更すると原因を特定しにくくなるため、一度に1項目だけ変更して記録しましょう。

まずクライアントのコアが動作しているか確認します。次に、システムプロキシに設定されたホストとポートが、クライアントの現在の待ち受けアドレスおよび混合ポートと一致しているか確認してください。スイッチがオンというだけで設定が正しいとは限りません。ほかのプロキシクライアントや、プロキシ設定を変更する可能性のあるブラウザー拡張機能を無効にしてから、ブラウザーを再起動してテストしましょう。Firefoxなどは独自のネットワーク設定を使う場合があるため、システムプロキシを選ぶか、正しいローカルプロキシを入力してください。接続画面に新しい記録がない場合は、アプリからクライアントまでの間で問題が起きている可能性があります。接続記録がある場合は、ルールの適用結果、ポリシーの選択、ノードの状態を確認しましょう。

まずTUNを無効にして比較し、基本ネットワークとシステムプロキシが正常か確認します。次にログを見て、DNSのタイムアウトや名前解決の失敗、ルーティングエラーがないか調べてください。設定でDNSサービスが有効になっているか、上流DNSアドレスに想定した経路でアクセスできるか、TUNのDNSハイジャック設定が現在のコアに対応しているかも確認します。fake-ipで合成アドレスが返されるのは正常な仕組みであり、設定が壊れているとは限りません。名前解決モードやフィルタールールを変更した後は、クライアントとシステムのDNSキャッシュを消去し、接続を再確立してください。一部のアプリだけに影響する場合は、関連ドメインへのfake-ipフィルターを検討し、出所の分からないDNS設定一式をそのままコピーしないでください。

ポートが使用中の場合は、ほかのプロキシクライアントを終了し、古いコアのプロセスがバックグラウンドで動作していないか確認してください。OSのネットワーク接続情報やプロセス確認ツールで使用中のプロセスを特定し、見覚えのないシステムプロセスを安易に終了しないでください。混合ポートを変更する場合、そのポートを手動で指定しているアプリの設定も更新します。クライアント終了後にネットへ接続できなくなった場合は、まずOSのネットワーク設定にローカルホストを指す手動プロキシが残っていないか確認し、その設定を無効にしてからテストしてください。改善しない場合は、TUNサービスとルーティングが復旧しているか調べ、必要なら通常の手順で端末を再起動します。次回終了する前に通信の取り込み機能を無効にしておくと、プロセスの強制終了によるネットワーク設定の残存を防ぎやすくなります。