Clashのよくある質問

Clashは一般にプロキシコアとその設定エコシステムを指し、mihomoはその設定エコシステムを引き継ぐコアプロジェクトです。GUIクライアントはサブスクリプションのインポートやポリシーの選択、システムプロキシの設定などを行い、実際の接続は使用中のコアが処理します。そのため、同じ画面でも対応する設定項目が同じとは限らず、同じコアでも設定画面の場所が一致するとは限りません。チュートリアルを探す際は、まずクライアント名を確認し、概要ページや実行ログでコアを特定しましょう。旧版Clashの制限をmihomoに当てはめないよう注意してください。

クライアントはプロキシ接続の設定・利用に使うツールであり、インストールしても利用可能なノードが自動で作成されるわけではありません。使用権限のあるサブスクリプションURL、またはプロキシノード、プロキシグループ、ルールを含む設定ファイルが必要です。サブスクリプションは通常、サービス提供元や自分で構築したサービスから取得します。このサイトのダウンロードページはサブスクリプションサービスではありません。インポート前に、利用するクライアントに対応した形式か確認し、URLに含まれる認証情報を安全に管理してください。サブスクリプションURL全体を公開の掲示板に貼り付けたり、提供元不明のリモート設定をインポートしたりしないでください。

ルールモードでは、設定内のルールの順序に従って、接続ごとにDIRECT、PROXY、REJECTなどの処理を選びます。グローバルモードでは、コアに渡された接続をグローバルポリシーで処理しますが、利用可能なノードの選択は必要です。DIRECTモードでは、コアに渡された接続が宛先へ直接アクセスします。これらのモードが変えるのは、接続を受け取った後のコアの処理方法であり、アプリが通信をコアに渡すかどうかではありません。そのため、グローバルモードに切り替えてもシステムプロキシやTUNの設定の代わりにはならず、すべてのアプリの通信がプロキシ経由になるとは限りません。

Clashのエコシステムには、別々にメンテナンスされている複数のコアやGUIクライアントがあります。ページに「公式」と書かれているだけで、エコシステム全体を代表しているとは限りません。利用するクライアントごとに、プロジェクト名、メンテナンス情報、配布元を確認しましょう。このサイトではダウンロード先と日本語の設定情報をまとめていますが、異なるプロジェクトを同じ開発チームが管理しているものとして扱ってはいません。Clash for Windowsの代替クライアントを探す場合は、画面を比べる前にメンテナンス状況、対応プラットフォーム、設定の互換性を確認してください。古いチュートリアルに記載されたインストーラーや設定項目名は、現在と異なる場合があります。

設定を共用できるかどうかは、OS名だけでなくコアや設定項目の対応状況によります。基本的なルールや一般的なプロキシ設定は互換性がある場合もありますが、デスクトップのシステムプロキシ、TUN、ファイルパス、スクリプト関連の設定をモバイル版にそのまま適用することはできません。モバイル端末では通常、システムのVPNインターフェースを通じて通信を処理するため、権限の設定場所もデスクトップとは異なります。端末間で設定をインポートする際は、まずサービス提供元が対応を明示している設定を使い、インポートログを確認してください。未対応の項目がある場合は、設定全体を安易に削除せず、利用中のクライアントの説明を確認しましょう。

クライアントの設定またはサブスクリプション画面でリモート設定を追加し、URL全体を貼り付けて保存した後、更新を実行します。リストに新しい設定が表示されたら、ダウンロード成功だけで終わらせず、現在の設定として選択してください。プロキシ画面を開き、想定したプロキシグループが表示されていることを確認してから、利用可能なノードを選択し、システムプロキシまたはモバイル端末のVPNを有効にします。最後に実際に使うサイトへアクセスし、接続ログで適用されたポリシーを確認します。画面にサブスクリプションが保存済みと表示されても、URLが保存されたことを示すだけで、設定の読み込みや通信の取り込みが完了したとは限りません。

まず、更新エラーがネットワークのタイムアウト、HTTPステータスエラー、設定の解析失敗のどれに当たるか確認します。URLが完全か、サブスクリプションの期限が切れていないか、サービス提供元が接続先を変更していないかを確認してください。401や403は認証やアクセス制限、404はURLの変更が原因の可能性があります。現在のプロキシが使えない場合は、利用可能なノードに切り替えるか、クライアントが対応していればDIRECTで更新してみましょう。ログイン画面や認証画面などのHTMLがダウンロードされても、設定の解析に失敗します。クライアントを何度も再インストールするのではなく、まずサブスクリプション側から有効な設定が返されているか確認してください。

まずログに記載された行番号の前後を確認し、インデント、コロンの後のスペース、リスト項目の先頭にあるハイフンを重点的にチェックします。YAMLのインデントにはスペースを使います。コピー時にタブや全角の句読点が混ざると、構造が壊れることがあります。サブスクリプションから取得したファイルなら、まず元の設定を再ダウンロードしてください。説明のないパラメーターをサブスクリプションURLの末尾に追加しないでください。構文に問題がないのにエラーが続く場合は、現在のコアがその項目に対応していない可能性があります。編集前にコピーを保存し、一度に一か所だけ変更すると、書式の問題か項目の互換性の問題かを切り分けやすくなります。

まずTUNを停止し、クライアントが必要とするサービスコンポーネント、管理者権限、システムのネットワーク拡張機能がインストールされ、実行を許可されているか確認します。Windowsでは、クライアントのサービスモードをインストールして起動する必要がある場合があります。macOSでは、システム設定でネットワーク拡張機能の使用を許可する必要がある場合があります。詳細はクライアントの案内に従ってください。モバイル端末ではVPN接続の作成を許可します。クライアント全体を常に高い権限で実行することだけを解決策にしないでください。権限を設定したらコアを再起動します。それでも失敗する場合は、ほかのVPNがネットワークインターフェースを使用していないか確認し、ログに記録された具体的なエラーを保存してください。

mixed-portは、HTTPとSOCKSの両方のプロキシ接続を受け付けるローカルの待ち受けポートです。実際の値は現在有効な設定で確認してください。常に7890とは限りません。起動時にアドレスが使用中と表示された場合は、ほかのクライアントやコアのプロセスが重複して起動していないか確認します。重複したプロセスを終了するか、空いているポートに変更してください。変更後はブラウザー、ターミナル、手動でプロキシを設定したアプリのアドレスも更新し、コアを再起動します。設定ファイルを変更しただけで再読み込みしていない場合、古い待ち受けポートが使われ続けることがあります。

普段はルールモードを選び、宛先に応じて設定が接続経路を決めるようにするのが一般的です。特定のサイトに接続できない場合は、一時的にグローバルモードに切り替えて比較し、グローバルポリシーで利用可能なノードが選択されているか確認します。グローバルモードでは正常でルールモードでは問題が起きる場合、その接続に適用されたルールを確認し、該当するポリシーやルールの順序を調整してください。確認後は元のモードに戻し、ほかの接続まで同じ経路を通らないようにします。グローバルモードでのテストは原因の範囲を絞る手がかりにはなりますが、問題が必ずルールにあると断定することはできません。両方のモードで実際に選ばれたノードが同じかどうかも確認しましょう。

対象のドメインに完全一致ルールまたはドメインサフィックスルールを追加し、先に適用される可能性のある広範なルールやMATCHのフォールバックより前に配置します。ルートドメインとサブドメインの両方を対象にする場合はDOMAIN-SUFFIX、単一のホスト名だけを対象にする場合はDOMAINを検討できます。サブスクリプション設定を変更する前に、次回更新で変更が上書きされないよう、クライアントのオーバーライド機能やカスタムルールの設定場所を確認してください。保存して再読み込みした後、新しい接続を作成して適用されたルールを確認します。既存の接続は元の経路を使い続ける場合があります。複数のドメインに依存するサイトでは、各リソースのリクエストも個別に確認してください。

システムプロキシの設定が反映されるのは、システムプロキシを参照するアプリが中心です。コマンドラインツールの中には、独自の引数やプロキシ環境変数だけを参照するものもあります。まず対象ツールが対応するプロキシの設定方法を確認し、現在の待ち受けアドレスとポートに合わせてHTTP_PROXY、HTTPS_PROXY、またはALL_PROXYを設定します。変数名や優先順位はツールのドキュメントを参照してください。すでに開いているターミナルは再起動が必要な場合があります。また、ツール独自の設定が優先されることもあります。確認時は実際の接続ログを調べ、テスト後は一時的な環境変数を削除してください。クライアントを停止した後も、ターミナルが使用できないローカルポートを参照し続けるのを防げます。

Fake-IPはドメイン名に仮想IPアドレスを返し、コアが接続を元のドメイン名に対応付ける仕組みです。ドメイン名に基づく振り分けに役立ちますが、アプリのDNS問い合わせがコア管理下のDNSを経由する必要があります。有効にするかどうかは、スイッチだけを変更するのではなく、クライアントの初期設定と現在のネットワークとの互換性を基準に判断してください。LAN内の機器、一部のゲーム、実際のIPアドレスを必要とするアプリでは、例外設定が必要な場合があります。特定のドメインで問題が起きたら、まずログを確認し、現在のコアが対応するfake-ip-filterの構文で例外を設定します。変更後は関連するキャッシュを消去し、再接続してください。

既存のTCP接続は通常、ポリシーを変更しても新しい出口へ自動で移行しません。アプリが接続プールを再利用することもあるため、切り替え直後は古いノードを使っているように見える場合があります。対象アプリの接続を終了するか、クライアントの接続画面で該当する接続を切断してから、リクエストを再送してください。ルールやDNS設定の更新後は、アプリの再起動、DNSキャッシュの消去、コアの再読み込みが必要な場合もあります。すでに開いているページの状態だけで変更の成否を判断せず、新しい接続のポリシーログを確認してください。進行中の作業を中断しないよう、すべての接続を一度に切断するのは避けましょう。

まずコアが起動していて、現在の設定が有効か確認します。次にシステムプロキシのアドレスが、実際に待ち受けているローカルポートを指しているか確認してください。ブラウザー拡張機能、ブラウザー独自のプロキシ設定、ほかのプロキシソフトがシステム設定を上書きしていないかも確認します。その後、接続画面から新しいリクエストを送信します。ログに記録されない場合は通信の取り込みを、記録される場合は適用されたポリシーとエラーを確認してください。別のブラウザーでも一時的に試すと、ブラウザー設定とネットワークの問題を切り分けられます。DNS、ルール、ノードを同時に変更せず、通信の取り込み、ポリシー、出口の順に一つずつ確認しましょう。

まず別のノードに切り替え、同じ接続先へアクセスして、障害が特定のノードだけで起きるか確認します。テストのタイムアウトは、ノードに到達できない、テスト先に問題がある、プロトコルに互換性がない、現在のネットワークに制限があるなどの原因が考えられます。一度のテストだけでサブスクリプション全体が無効と判断しないでください。サブスクリプションが最新か、端末の時刻が正確かを確認し、そのノードへの接続ログも確認します。テストだけ失敗して実際のアクセスは正常な場合は、テストURLを確認してください。実際のアクセスも失敗する場合は、利用可能なノードに切り替えたうえで、発生時刻、ネットワークの種類、機密情報を除いたエラーの概要をサービス提供元に伝えましょう。

アプリコンテナーによる隔離のため、一部のUWPアプリはローカルのループバックプロキシアドレスに直接アクセスできません。ブラウザーは正常なのに特定のUWPアプリだけ失敗する場合は、まずこの制限が原因か確認します。クライアントにループバックの除外ツールが用意されていれば、必要なアプリだけに許可を設定してください。ツールがない場合は、WindowsのCheckNetIsolationに関するドキュメントを参照し、対象パッケージの除外状態を確認できます。この操作には管理者権限が必要な場合があり、すべてのストアアプリに適用できるわけではありません。許可後に対象アプリを再起動してください。アプリ自体がシステムプロキシを参照しない場合は、別途通信を取り込む方法を確認する必要があります。

まずアプリのDNS問い合わせをどの設定が処理しているか確認し、コアのDNS設定、システムDNS、ブラウザーのセキュアDNSを照らし合わせます。ブラウザー内蔵の暗号化DNSは独自の経路を使う場合があり、コアのDNSポリシーに従うとは限りません。DNS漏れテストに表示されるDNSサービスの場所は手がかりの一つであり、地域だけで漏れの有無を判断することはできません。DNSログと通信経路も確認し、問い合わせが想定どおり送信されているか調べてください。TUNやDNSの設定を切り替えた後は、新たにDNS問い合わせを行い、必要に応じてキャッシュを消去します。IPv6の問い合わせやLAN内機器の名前解決も、設定に含まれているか確認してください。

クライアント終了後にネットワークへ接続できない場合は、システムにローカルポートを指す手動プロキシ設定が残っていないか確認し、続けてDNSとVPNの接続状態を調べます。システムプロキシとTUNは、できるだけクライアントの通常の終了手順で無効にしてください。TUNを有効にした後、プリンター、ルーター、LAN内サービスだけが使えない場合は、ファイアウォールをすべて無効にするのではなく、プライベートネットワークのルート除外やDIRECTルールを確認します。自動ルーティングの仕組みはクライアントごとに異なるため、変更前に現在の設定を記録してください。ネットワークが復旧したら機能を一つずつ有効にします。問題が続く場合はルート情報とログを保存し、ネットワーク設定全体をむやみにリセットしないでください。