Clash よくある質問
設定・接続のトラブル対処

Clash Vergeはデスクトップクライアントのプロジェクト名で、Clash Verge Revはその後継として開発が続けられているプロジェクトです。両者のリリース状況やメンテナンス状況は、それぞれ確認してください。mihomoはプロキシ接続、DNS解決、ルール判定を行うコアです。クライアントが設定の読み込みや切り替え、画面表示を担い、コアが実際の通信を処理します。そのため、画面が正常に開いてもコアが起動しているとは限りません。また、新しいクライアントをインストールしても、以前の設定ファイルのすべての項目がそのまま使えるとは限りません。問題を調べる際は、まずクライアント名を記録し、設定画面でコアの情報を確認して、クライアントとコアのバージョンを混同しないようにしましょう。

クライアントは接続を管理するもので、インストールしただけで利用可能なプロキシサーバーが自動生成されるわけではありません。サブスクリプションは通常、サービス提供元が発行する設定用URLで、ノード、プロキシグループ、ルールなどが含まれます。ローカルのYAMLファイルでも同じ情報を読み込めます。初回利用時は、設定画面でURLまたはファイルを読み込み、正常に解析されたことを確認してから、使用する設定として選択してください。設定名が表示されているだけでは有効になっているとは限りません。プロキシ画面でプロキシグループが表示されることも確認しましょう。サブスクリプションURLには認証情報が含まれる場合があります。アカウント情報と同様に安全に管理し、公開スクリーンショットや掲示板、オンライン変換サイトには貼り付けないでください。

ルールモードは設定ファイルのルールを上から順に照合し、一致したルールに対応するポリシーを適用します。普段の通信を振り分けるのに適しています。グローバルモードは、コアが処理する接続をすべてグローバル用プロキシグループに渡すため、一時的な比較テストに便利です。ただし、そのグループで利用可能なノードを選ぶ必要があります。ダイレクトモードでは、コアが処理する接続がプロキシノードを経由せず、宛先へ直接アクセスします。モードが決めるのはコアに入った後の処理方法であり、どのアプリがコアに接続されるかではありません。システムプロキシを使わないアプリは、グローバルモードに切り替えただけではプロキシ経由になりません。まずアプリのプロキシ設定を確認し、必要に応じてTUNモードを検討してください。

システムプロキシは、OSのプロキシ設定を変更する機能です。その設定に従うアプリの通信がクライアントに送られます。TUNモードは仮想ネットワークインターフェースを使い、ルーティング条件に合う通信を取り込みます。システムプロキシを参照しない一部のアプリにも使えますが、通常はサービスの権限が必要で、ルーティングやDNSの設定にも関わります。初めて使う場合は、まずシステムプロキシだけを有効にして接続を確認し、必要に応じてTUNを使いましょう。両方を併用するかどうかは、クライアントの実装や設定によって異なります。必ず同時に有効にする必要はありません。問題を調べる際は一度に一つの設定だけを変更し、接続画面で宛先やルールの判定を確認してください。どの設定が影響したのか分からなくなるのを防げます。

まず、アカウントのトップページや決済ページ、共有方法の説明ページではなく、サブスクリプションURL全体をコピーしているか確認します。URLの前後に空白や改行が入っていないかを確認し、設定画面から再度更新してエラーメッセージを読みましょう。認証失敗やアクセス拒否が返る場合は、提供元に有効期限とURLの変更有無を確認してください。Webページの内容が返る場合は、URLが違うか、ログイン認証が必要な可能性があります。接続がタイムアウトする場合は、クライアントの画面で利用できる項目に応じて、直接更新と、現在利用可能なプロキシ経由の更新をそれぞれ試してください。古い設定をすべて続けて削除するのは避けましょう。引き続き使える設定を一つ残し、新しいサブスクリプションの読み込みと選択を確認してから整理してください。

設定画面に戻り、読み込んだ項目が現在の設定として選択されていることを確認してください。ダウンロードしただけでは利用中になりません。次にコアのログを確認し、設定の解析失敗、リモートのノード一覧の取得失敗、設定自体にノードがない場合を切り分けます。proxy-providersでリモートのノード一覧を参照する設定では、メインのファイルをダウンロードできても、参照先にアクセスできるとは限りません。マージ設定、スクリプト、オーバーライド機能を使っている場合は、一時的に無効にして元の設定を再読み込みし、比較してください。それでも一覧が空の場合は、サブスクリプションがmihomoに対応しているか提供元に確認しましょう。拡張子を変更して、別のクライアント向けの形式を無理にYAMLに変えるのは避けてください。

まずTUNを無効にし、クライアントの設定でサービスモードがインストール済みで、実行中か確認します。サービスのインストールが必要な場合は、クライアントのサービス管理画面から操作し、OSの案内に従って許可してください。組織管理下の端末では、管理者に権限を確認してもらいましょう。インストールまたは修復後にクライアントを再起動してTUNを有効にし、仮想インターフェースやルートの作成エラーがログに残るか確認します。他のVPN、仮想NICツール、セキュリティソフトを併用している場合は、許可された範囲で一つずつ一時停止して比較してください。ネットワークアダプターを削除したり、すべての保護機能を無効にしたりしないでください。権限に問題がないのに失敗する場合は、設定ファイルのTUN関連項目が現在のコアに対応しているかも確認します。

クライアントの設定画面で現在のプロキシポートを確認してください。HTTP、SOCKS、mixed-portはそれぞれ異なります。mixed-portでは、同じ待ち受けポートでHTTPとSOCKSのプロキシリクエストを受け付けます。実際に適用されている設定とコアのログを確認し、解説記事の数字をそのまま使わないようにしましょう。アドレスが使用中というエラーが出たら、まずプロキシクライアントが重複して起動していないか確認します。必要であればOSのネットワークツールで使用中のプロセスを調べてください。利用可能なポートに変更した後、設定を再読み込みし、ブラウザー拡張機能、ターミナルなど、プロキシを手動設定したアプリも更新します。管理用ポートはプロキシ用ポートではないため、アプリのHTTPプロキシ欄に入力しないでください。

まず、現在の設定とプロキシグループの選択が反映されていることを確認してから、システムプロキシを有効にします。ブラウザーでプロキシルールに一致する宛先にアクセスし、すぐにクライアントの接続画面を開いて、宛先ドメイン、適用されたルール、最終的に使われたポリシーまたはノードを確認してください。システムプロキシのスイッチがオンになっているだけでは、通信経路を検証できません。有効化の前後で同じIP確認サービスを使い、出口を比較する方法もあります。ただし、接続画面と合わせて判断してください。確認用のドメインがルールによって直接接続される場合があるためです。テスト中はブラウザーで別途プロキシを設定する拡張機能を無効にし、設定の競合を避けましょう。TUNを使う場合は、普段システムプロキシを参照しないアプリでも別途確認してください。

selectはユーザーがノードを手動で選ぶ方式で、出口を固定したい場合や問題の切り分けに適しています。url-testは設定されたテスト先と間隔に基づいて候補ノードを比較し、許容差も考慮して選択します。結果が示すのは、そのテスト先への接続状況だけです。fallbackは候補の順番に従って利用可能な項目を選ぶため、メインと予備の優先順位を決めておきたい場合に向いています。プロキシグループが別のグループを参照することもあるため、画面で選んだグループとは別の下位グループが最終的な出口を決める場合があります。特定のリクエストを確認するには、接続詳細で実際の経路を確認してください。一度のテスト結果だけを見てグループの種類を何度も変更するのは避けましょう。まずテスト先が利用可能か確認し、出口を固定したいのか自動で切り替えたいのかに応じて選びます。

リモートのサブスクリプションは更新時に元の設定を再生成することが多く、設定ファイルを直接編集した変更は上書きされる場合があります。長期的に残したいルールは、クライアントが対応するオーバーライドまたはマージ設定の画面に追加し、現在のサブスクリプションに適用されていることを確認してください。ルールは通常、上から順に判定されます。独自のルールは、先に一致する可能性のある広範なルールより前に配置し、特にMATCHのフォールバックルールより後ろに置かないようにしましょう。追加時には、参照先のプロキシグループが存在することも確認してください。名前の大文字・小文字や空白も一致させます。保存後に設定を再読み込みし、接続画面で対象のリクエストにどのルールが適用されたか確認してください。編集画面に文字が残っているだけでは十分ではありません。

使い終わったら、まずシステムプロキシとTUNを無効にし、トレイメニューからクライアントを正常に終了してください。関連設定を元に戻す時間を確保できます。ブラウザー、ターミナル、開発ツールに個別のプロキシを設定した場合は、それぞれのアプリでも無効にします。異常終了後にネットワークへ接続できない場合は、システムプロキシがまだローカルホストを指している一方、対応する待ち受けプロセスが停止していないか確認してください。確認後、そのプロキシ設定を無効にして再度接続を試します。最初からネットワーク設定をすべてリセットしたり、設定ファイルを削除したりしないでください。起動時に自動で使いたい場合は、クライアントの自動起動、コアの実行、プロキシの適用状態をそれぞれ確認しましょう。OS起動時にクライアントが立ち上がることと、接続が使えることは別です。

まずプロキシを無効にして、基本的なネットワーク接続が使えることを確認します。次に、クライアントのコアが動作しているか、ローカルポートが待ち受けているか、対象アプリの通信が実際にクライアントへ入っているか確認してください。続いてサブスクリプションの有効期限を確認し、同じプロキシグループ内の別のノードで比較して、該当リクエストのログを調べます。ドメイン名の解決に失敗する場合はDNSを優先して確認します。認証失敗の場合はノードの認証情報とサブスクリプションの状態を確認し、接続拒否の場合はサーバーアドレス、ポート、サービスの稼働状況を確認してください。すべてのノードで同時に失敗する場合、すぐに各ノードのプロトコル設定を変更するのではなく、まず端末のネットワークと設定を確認します。一度に変更するのは一項目だけにし、同じ宛先で再試行して前後のログを残すと、変更の効果を判断できます。

まずOSのプロキシ設定で、アドレスとポートが現在のクライアントを指していることを確認し、コアが待ち受け中か調べます。次に、対象アプリに独自のプロキシ設定、ブラウザー拡張機能、プロキシ除外リスト、既存のVPNがないか確認してください。いずれも通信経路を変える可能性があります。テスト用の宛先にアクセスしたら、接続画面を確認します。記録がまったくない場合は、まず通信がクライアントに取り込まれているかを調べます。記録がありDIRECTと表示される場合は、クライアントを何度も再インストールするのではなく、ルールとポリシーを確認してください。システムプロキシを参照しないアプリでは、アプリ内で対応するプロキシ方式を設定するか、TUNモードを検討できます。ターミナルではプロキシ環境変数が影響する場合もあるため、OSの設定を変更した後に別途確認しましょう。

まず、どのドメインをどのDNSリゾルバーで問い合わせたいかを明確にし、設定ファイルのDNSリスナー、上流リゾルバー、ルールの設定を確認します。ブラウザーのセキュアDNS、アプリ独自のDoH、OSの暗号化DNSでは、異なる名前解決経路が使われる場合があります。無効にするかどうかは、想定している設定に応じて判断してください。スイッチ一つだけを見て決めないようにしましょう。テストサービスを使う際は、プロキシの出口アドレスと再帰DNSリゾルバーのアドレスを区別してください。両者が異なるだけではDNS漏えいの証明にはなりません。重要なのは、問い合わせが想定した経路を迂回しているかどうかです。比較のため一時的にブラウザー独自のDNSを無効にし、コアのログも確認できます。TUNを使う場合は、DNSのリダイレクトとルーティングが実際に適用されているかも調べてください。

AppContainerによる分離を使う一部のWindowsアプリでは、ローカルループバックへのアクセスが制限され、クライアントが待ち受けているローカルプロキシに接続できない場合があります。まず通常のブラウザーが同じプロキシ経由で通信できることを確認し、クライアントにUWPのループバック除外設定があるか調べてください。設定があれば、必要なアプリだけを選んで許可します。すべてのアプリを追加する必要はありません。管理者はWindowsのCheckNetIsolationツールで除外設定を管理することもできますが、アプリのパッケージIDを正確に確認する必要があります。ストアアプリすべてに同じ制限があるわけではありません。設定後も解決しない場合は、除外設定を繰り返し追加するのではなく、アプリがシステムプロキシを参照しているか、アカウントにログインしているか、接続画面に記録があるかを確認してください。