Clashのよくある質問

Clashはもともとプロキシコアとその設定エコシステムを指します。派生コアプロジェクトの旧称はClash Metaで、現在はmihomoの名称で開発が続いています。GUIクライアントはサブスクリプションの読み込み、プロキシグループの選択、システムプロキシの設定、ログの表示を担い、コアは設定の解析、ルールの照合、接続の確立を担います。クライアント名が似ていても、コアや対応プロトコルが同じとは限りません。トラブルシューティングの前に、バージョン情報画面でクライアント名・バージョン・コアのバージョンを確認し、それぞれのプロジェクトに対応する設定を使ってください。別のクライアントの画面をそのまま参考にしないようにしましょう。

クライアントは操作画面と通信処理機能を提供し、設定ファイルはプロキシサーバー、プロキシグループ、ルール、DNSの設定を定義します。クライアントをインストールしただけでは、接続可能なプロキシサーバーは利用できません。設定を用意している場合は、設定画面からURLまたはローカルファイルを読み込み、有効化した後、プロキシグループに選択可能な項目が表示されるか確認してください。サブスクリプションには通常、アクセス認証情報が含まれます。信頼できる提供元からのみ取得し、完全なURLを公開フォーラムやオンライン変換サイト、問い合わせ用のスクリーンショットに貼り付けないでください。

通常はルールモードを使います。rulesの上から順に照合し、接続先をDIRECT、プロキシグループ、REJECTのいずれかに振り分けます。グローバルモードは、コアに届いた接続をグローバル設定に従って処理します。ルールの影響を短時間で比較する場合に便利です。DIRECTモードでは、すでに制御対象となっている接続が宛先へ直接アクセスします。モードの選択は通信を制御する機能のオン・オフとは別です。アプリがシステムプロキシ、明示的なプロキシ、TUNのいずれも使っていない場合、グローバルモードに切り替えてもそのアプリの通信は自動的に制御されません。テスト後はルールモードに戻し、接続を新しく作り直してください。

システムプロキシはプロキシのアドレスをOSの設定に登録し、その設定に従うアプリの通信に使われます。TUNは仮想ネットワークインターフェースとルーティングを使って対象の通信を制御するため、システムプロキシを無視するアプリにも対応できます。両方を同時に有効にしなければ動作しないわけではありません。まずシステムプロキシでブラウザーの動作を確認し、その後、必要に応じてTUNを有効にしましょう。一度に複数の設定を変更しないでください。TUNで実際に制御される範囲は、ルーティング、除外設定、DNS設定にも左右されます。スイッチがオンになっただけで、すべての通信が制御されているとは限りません。

プロキシサーバー、プロキシグループ、一般的なルールは、多くの場合そのまま使えます。ただし、移行先クライアントのコアが同じ構文とプロトコルに対応していることが前提です。ネットワークインターフェース名、ファイルパス、スクリプト、外部コントローラー、TUNに関する設定は、OSに応じた変更が必要になることがあります。移行時はまず元の設定を読み込んで解析結果を確認し、通信制御機能は別途有効にしてください。古い端末の実行ディレクトリを新規インストール先にそのままコピーしないでください。サブスクリプションの更新でローカルの変更が上書きされることもあるため、継続的な変更にはクライアントが対応するオーバーライドやマージ設定を使いましょう。

まず設定画面でエラーの全文を確認します。タイムアウトの場合は、ネットワークに接続できるか、更新時に現在のプロキシが必要かを確認してください。HTTP 401または403の場合は、サブスクリプションの認証やURLの有効性を確認します。証明書エラーが出たら、まずシステム時刻を合わせ、証明書チェーンとネットワーク環境を確認してください。証明書検証を安易に無効化しないでください。解析エラーの場合は、取得した内容がWebページやログイン画面、別形式のノード一覧ではなく、ClashのYAMLであることを確認します。URLをコピーし直す際は前後の空白を取り除き、パラメーターを含めてすべてコピーしてください。公開ログにURLが含まれないよう注意しましょう。

まずクライアントの設定チェック機能を使い、エラー行からインデント、フィールド、参照先の問題を確認します。YAMLの階層にはスペースを使い、タブは避けてください。プロキシグループが参照するノード名や、ルールが参照するプロキシグループ名は、大文字・小文字も含めて定義と一致させる必要があります。未対応のプロキシタイプやフィールドが見つかった場合は、何度も再インストールするのではなく、コアとの互換性を確認してください。変更前に元のファイルを保存し、一度に一項目ずつ変更して再チェックします。読み込みに成功しても、ファイルを読み取れたことを示すだけです。設定を有効化し、コアが正常に起動したことも確認してください。

まずコアが起動していることを確認し、システムプロキシのアドレスとポートがクライアントの設定と一致しているか確認します。7890はよく使われる混合ポートの例であり、すべてのクライアントで現在のポートが7890とは限りません。ブラウザーのプロキシ拡張機能、手動プロキシ設定、システムのプロキシ除外リストを確認し、別の設定がクライアントを上書きしていないか調べます。次に接続画面を開き、新しいタブで接続先にアクセスして、該当する接続と適用ルールが表示されるか確認してください。記録がまったくない場合は、まず通信が制御対象になる経路を確認します。DIRECTと記録される場合は、ノードを切り替えるだけでなく、ルールとプロキシ選択を確認してください。

WindowsではまずTUNを無効にし、クライアントにサービスモードのインストールまたは修復機能があるか確認します。画面の案内に従って許可を与え、クライアントを再起動してください。クライアントによっては、管理者として実行して操作を完了できます。macOSとLinuxでは、プロジェクトのドキュメントに従ってネットワーク拡張機能、補助サービス、必要な権限を許可してください。Windowsの手順をそのまま適用できるとは限りません。サービスが起動しない場合は、まずログに記録されたエラーを確認し、セキュリティソフトによるブロック、仮想ネットワークインターフェース、ほかのVPNとの競合を調べます。権限の問題を解決してからTUNを有効にし、インストールを繰り返さないでください。

まず、同じ名前の別設定ではなく、今読み込んだ設定が有効になっていることを確認します。proxy-providersを使っている場合は、プロバイダーのデータを正常に取得できたか、またプロキシグループのuse、filter、exclude-filterで全項目が除外されていないかを確認してください。設定にプロキシが定義されていても、すべてのプロキシグループに自動表示されるとは限りません。サブスクリプションの取得内容が不完全な場合、契約期限が切れている場合、コアがプロトコルに対応していない場合も、項目が表示されないことがあります。元の設定を保存し、更新エラーを確認してください。一時的にカスタムオーバーライドを無効にすると、サブスクリプション側とローカルのマージ設定のどちらに問題があるか切り分けやすくなります。

設定画面で対象のサブスクリプションを開き、編集または更新の設定から、自動更新間隔と更新用プロキシの項目を探します。項目名や間隔の単位はクライアントによって異なるため、画面の説明に従ってください。更新間隔は提供元の指定に合わせ、リクエスト制限にかからないよう短くしすぎないでください。DIRECTで更新に失敗しても現在のプロキシが使える場合は、プロキシ経由での更新を試せます。一方、接続前にサブスクリプションの更新が必要な場合、使えないプロキシに依存する更新経路を選ぶとループに陥ります。手動更新が成功したことを確認してから、自動更新の履歴が想定どおりに記録されているか確認してください。

ルールは記載順に照合され、通常、一致すると後続のルールは確認されません。具体的なドメインルールを広範囲なルールより前に置き、MATCHによるフォールバックは末尾に置いてください。たとえばDOMAIN-SUFFIX,github.com,Proxyを使う場合、設定内にProxyという名前のプロキシグループが必要です。サブスクリプション更新で変更が上書きされないよう、クライアントのルールオーバーライド機能でルールを追加するか、優先して配置してください。保存後に設定を再読み込みし、新しい接続を作って実際に適用されたルールを確認します。既存の長時間接続は、ルールを変更してもすぐに新しい出口へ切り替わらないことがあります。

接続画面を開き、接続先のドメイン、プロセス名、宛先アドレスで絞り込んでから、適用ルール、プロキシグループの経路、最終的に選ばれたプロキシを確認します。プロキシグループ名は選択の入口であり、最終的な接続先とは限りません。グループが入れ子になっている場合は、経路をたどって確認してください。テスト前に対象アプリの既存接続を閉じ、新しいリクエストを送信すると、接続の再利用による影響を抑えられます。ブラウザーに表示される出口IPだけでは、そのリクエストの結果しか分かりません。他のアプリ、UDP、すべてのドメインも同じ経路を使っているとは限りません。

まずクライアントでLANアクセスを許可し、待ち受けアドレスがローカルのループバックだけに限定されていないことを確認します。次にほかの端末で、クライアントを実行しているPCのLAN内アドレスと実際のポートを指定します。allow-lan: falseはLANアクセスを許可しない設定ですが、既定値は現在の設定を確認してください。ファイアウォールで通信を許可する場合は、信頼できるプライベートネットワークと必要なアドレスに限定し、コアが対応している場合は認証を設定します。プロキシポートをインターネットに公開しないでください。テスト後は不要になった共有を無効にし、外部コントローラーも公開されていないことを確認しましょう。

クライアントとコアのバージョン、OSのバージョン、発生時刻、操作手順、エラーの種類を残してください。ログレベルは通常infoから始め、問題を再現するときだけ一時的に上げて、確認後は元に戻します。ログが増え続けるのを防ぐためです。共有前にサブスクリプションURL、認証パラメーター、パスワード、コントローラーのキー、公開したくないアクセス先のドメインやアドレスを隠してください。設定ディレクトリ全体をアップロードせず、障害に関係する最小限のログと、機密情報を除いた設定の一部を共有します。システムプロキシとTUNの有効状態も記載してください。

ノードテストは、コアが指定されたテスト先にリクエストを一度送るものです。テスト先に到達できない、名前解決に失敗する、サーバーへの接続に失敗するといった理由でタイムアウトすることがあり、すべての接続が使えないとは限りません。まず、開けるWebページがDIRECTやキャッシュではなく、プロキシ経由になっているかを確認します。次に同じノードで複数の接続先を試し、エラーが名前解決、ハンドシェイク、データ転送のどの段階で発生するかを確認してください。すべての接続先で失敗する場合は、サーバーの稼働状況、サブスクリプションの有効期限、PCのネットワークを調べます。テスト先はクライアントのドキュメントに従って変更できます。1回のテスト結果だけで設定を削除しないでください。

まずTUNを無効にして基本のネットワーク接続が戻ることを確認し、テスト時は通信を制御するツールを一つだけ使います。他のVPN、仮想マシンのネットワークインターフェース、セキュリティソフトがデフォルトルートやDNSを同時に変更すると、通信の迂回やループ、名前解決の失敗が起きることがあります。ログでネットワークインターフェースの作成、ルート追加、DNSの待ち受けに関するエラーを確認し、サービスの権限、ポートの競合、自動ルーティングの設定を順に調べます。システムルートをすべて削除しないでください。企業VPNも併用する必要がある場合は、そのネットワーク要件に合わせて除外するサブネットを設定してください。2つの自動ルーティングがそのまま共存できるとは限りません。

まず、どのドメインをどの名前解決経路で処理するか、DNSリクエストをDIRECTにするかプロキシ経由にするかを明確にします。DNS検査サイトに表示されるのはリゾルバーの出口です。表示地域が違うだけでリークと判断することはできません。ブラウザーのセキュアDNS、OSの暗号化DNS、IPv6、TUNのDNSハイジャック設定によって、クライアントを経由せずに名前解決されることがあります。テストでは各設定を個別に記録し、関連するキャッシュを消去して再度検索したうえで、クライアントのログからリクエスト経路を確認してください。fake-ip、nameserver、システムDNSを一度に適当に変更すると、どの設定が影響したのか分からなくなります。

アプリコンテナーの制限がある一部のWindowsアプリは、ローカルのループバックプロキシに直接アクセスできません。ブラウザーが正常でも、そのアプリだけ接続に失敗することがあります。まず対象アプリがシステムプロキシを実際に使っているか確認し、クライアントにUWPのループバック免除機能があるか調べます。手動で設定する場合は、管理者権限でターミナルを開き、CheckNetIsolation LoopbackExempt -sで既存の免除を確認してから、対象アプリの実際のパッケージファミリー名を指定してください。他のアプリの名前をそのままコピーしないでください。信頼でき、必要性があるアプリだけに許可を与え、デバイスの管理ポリシーに従ってください。ループバック免除では、ノードやルールの問題は解決できません。

クライアント終了後に接続できない場合は、システムプロキシが停止済みのローカルポートを参照したままになっていないか確認します。残っている手動プロキシ設定を無効にして、再度試してください。TUNを使っていた場合は、補助サービスや仮想ネットワークインターフェースが動作し続けていないかも確認します。ポートが使用中の場合は、クライアントを二重に起動していないか確認し、重複したインスタンスを通常の方法で終了してください。正体の分からないシステムプロセスを強制終了しないでください。mixed-portを変更する必要がある場合は、システムプロキシと、そのポートを手動設定しているアプリも更新します。復旧後はクライアントの通常の終了手順を使い、強制終了を繰り返して設定が残るのを防いでください。