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

Clashはルールベースのプロキシエコシステムで広く使われるプロジェクト名です。Clash Metaは関連するコアの旧称で、後にmihomoという名称が使われるようになりました。クライアントはサブスクリプション管理、ポリシー選択、システムネットワーク設定などのGUIを提供します。画面に項目があっても、コアでその機能が有効とは限りません。設定を読み込めるかどうかは、コアのバージョンや対応フィールドによって異なります。設定エラーが出た場合は、まずクライアントの「情報」またはコアの画面で実際に使われているコアを確認し、そのドキュメントに沿って調べてください。インストーラーの名前だけで互換性を判断しないようにしましょう。

クライアントは設定を読み込んで通信を中継するもので、それ自体が利用可能なプロキシサービスというわけではありません。リモートプロキシを使うには、通常、サービス提供元のサブスクリプションを読み込むか、有効なサーバー情報を自分で入力します。直結ルールを使う場合はリモートノードは不要です。サブスクリプションにはノード、プロキシグループ、ルール、DNS設定が含まれる場合もあれば、ノード一覧だけが返される場合もあります。読み込む前に形式と有効期限を確認してください。サブスクリプションURLにはアクセス用の認証情報が含まれることが多いため、公開コメントやスクリーンショット、オンライン変換サービスに貼り付けないでください。サポートを求める場合は、機密情報を隠したエラーメッセージだけを共有しましょう。

通常はルールモードを選び、rulesに記載された順に接続先のポリシーを適用します。グローバルモードでは、コアに届いた通常の接続にグローバルポリシーを適用しますが、利用可能なノードの選択は必要です。すべてのアプリの通信が自動的にコアを経由するわけではありません。直結モードはネットワーク状態を一時的に比較する際に便利ですが、設定済みのDNS、TUNルート、アプリ独自のプロキシがテスト結果に影響することがあります。調査時は元のモードを記録し、設定を一度に一つだけ変更してから接続し直してください。グローバルモードへの切り替えを、サブスクリプション、権限、システムプロキシの問題を解決する万能策にしないでください。

システムプロキシは、PCのプロキシアドレスをOSの設定に登録します。通常は、その設定に従うブラウザーやアプリで使われますが、無視するプログラムもあります。TUNは仮想ネットワークインターフェースとルートを使って、対象範囲のIP通信を処理します。より多くのアプリをカバーできますが、権限、ルート、DNSの設定が必要です。初回はまずシステムプロキシでサブスクリプションとノードを確認し、必要に応じてTUNを有効にしてください。両方を同時に使えるかはクライアントの実装によります。スイッチを増やしても必ず対象範囲が広がるとは限らず、かえって原因の切り分けが難しくなることがあります。

まず、エラーがダウンロード中と解析中のどちらで発生したかを確認します。ダウンロードに失敗する場合は、URL全体、アクセス権限、現在のネットワークを確認してください。解析に失敗する場合は、返された内容がYAML設定なのか、ログインページやエラーページ、Base64形式のノード一覧ではないかを確認します。「不明なフィールド」や「未対応のプロトコル」と表示されたら、mihomoコアとクライアントの対応状況を調べてください。動作中の設定を何度も上書きせず、まずコピーを保存してから新しい設定を試しましょう。形式に互換性がない場合は、サブスクリプション提供元に対応版を問い合わせてください。認証情報を含むURLを、公開の変換サービスに渡さないでください。

まずTUNを無効にし、クライアントにサービスモード、補助サービス、権限のインストール項目があるか確認してください。Windowsでは通常、クライアントの手順に沿ってサービスをインストールするか、権限を昇格する必要があります。macOSでは補助コンポーネントの許可が必要な場合があります。Linuxの権限要件はインストール方法とディストリビューションによって異なります。許可後に関連サービスを再起動してTUNを有効にし、ログで仮想ネットワークインターフェースとルートが作成されたか確認してください。エラーを消すために、システムのセキュリティ機能を長期間無効にしないでください。解決しない場合は、ほかのVPNや仮想ネットワークツールを終了し、一時的な接続手段としてシステムプロキシを使いましょう。

Androidクライアントは通常、VpnServiceでローカルVPNインターフェースを作成し、選択したアプリの通信をプロキシコアに渡します。そのため、初回起動時にシステムの許可が必要です。この許可を得てもサブスクリプションが有効になるわけではありません。設定を読み込み、利用可能なポリシーを選ぶ必要があります。別のVPNが接続中の場合は、先に切断してください。同じユーザープロファイルでは、通常、この種のVPNを同時に2つ実行できません。許可画面が繰り返し表示される場合は、仕事用プロファイル、常時接続VPN、VPN未接続時の通信をブロックする設定を確認し、現在のクライアントが有効になっていることを確かめてから再接続してください。

OS起動時の自動起動、コアの起動、システムプロキシの復元は、それぞれ別の設定です。まずクライアントでログイン時の起動を有効にし、前回の設定の自動読み込み、ポリシーの復元、必要なネットワークモードの有効化を個別に確認してください。TUNはバックグラウンドサービスが先に起動している必要がある場合があり、スタートアップにショートカットを追加するだけでは不十分です。設定後に一度完全に再起動し、設定名、動作状態、プロキシのスイッチを確認しましょう。共有PCではユーザーごとに設定し、別のアカウントでログインした際に不適切なプロキシが引き継がれないようにしてください。終了後にネットワークに問題が出たら、まずシステムプロキシを無効にし、バックグラウンドでコアが動作していないか確認してください。

サブスクリプションから生成された設定ファイルを直接編集しても、次回の更新時にリモートの内容で上書きされるのが一般的です。ルールを恒久的に残すには、クライアントが対応している上書き、マージ、スクリプトの仕組みを使いましょう。追加と置換の扱いはクライアントによって異なるため、設定前に説明を確認してください。変更後は最終的に適用される設定を確認し、カスタムルールがMATCHより前にあり、参照先のプロキシグループが実際に存在することを確かめます。まずドメインルールを1つだけ試し、段階的に追加してください。更新後に設定全体を読み込めなくなった場合は、上書きを無効にして接続を復旧し、ログから競合するフィールドを特定しましょう。

ルールは上から順に評価され、最初に一致したルールでポリシーが決まります。同じ選択で、それ以降のルールは適用されません。まず接続ログを開き、対象ドメイン、一致したルール、最終的なプロキシグループを確認し、次にグループで選択中のノードを調べてください。接続先がIPアドレスしか表示されない場合、ドメインルールの判定に必要な情報が不足している可能性があります。DNSとスニッフィングの設定も併せて確認しましょう。ルールを変更したら、該当アプリの既存接続を終了して再試行してください。接続済みの通信は以前の経路を使い続けることがあります。設定ファイルにドメインが記載されているだけでなく、そのファイルが実際に読み込まれていることも確認してください。

接続する端末を、信頼できる同じLANに接続します。PCのクライアントでLAN接続を許可し、待ち受けアドレスがローカルホスト限定になっていないことを確認してください。続いてスマホやテレビのネットワーク設定で、PCのLAN内IPアドレスと混合ポートを指定します。ポート番号は現在の設定を確認してください。PCのファイアウォールでは、必要なLANの範囲だけ通信を許可します。手動のHTTPプロキシは通常、その設定に従うアプリだけが対象で、端末全体の通信をカバーするわけではありません。使い終わったら共有を無効にし、混合ポートや外部コントローラーポートをインターネットに公開しないでください。

Fake-IPモードでは、コアがDNS問い合わせに合成アドレスを返し、内部のマッピングによって後続の接続をドメインに対応づけます。これはリモートノードのアドレスでも、Webサイトの実サーバーのアドレスでもありません。LAN内のデバイス検出や機器操作、実IPに強く依存するアプリでは個別の対応が必要な場合があります。その場合は対象ドメインに合わせてfake-ip-filterを設定し、現在のコアで使われているフィルターモードを確認してください。すべてのドメインをフィルターに追加すると、DNSの動作全体が変わるため避けましょう。調整後はアプリの接続を確立し直し、DNSログとローカルデバイスへのアクセスが復旧したか確認してください。

401や403は通常、アクセス用の認証情報、権限、サーバー側のアクセス制限に問題があることを示します。サービス提供元の管理画面でサブスクリプションの状態を確認し、URLが再発行されていないか調べてください。これらのステータスコードだけでアカウントの期限切れとは断定できません。タイムアウトの場合は、ローカルネットワーク、ドメインの名前解決、更新リクエストがすでに使えないプロキシに依存していないかを確認します。古い設定は残し、ノードをすべて削除するのは避けてください。クライアントで更新方法を選べる場合は、直結と利用可能な既存プロキシの両方を試し、エラーの発生時刻を記録して提供元に問い合わせましょう。送信時はサブスクリプションURLを隠してください。

まずプロキシを一時停止し、普段直結できるサイトにアクセスして基本のネットワーク接続を確認します。次にシステム時刻が正確か、サブスクリプションが有効かを調べてください。クライアントの接続テストはテスト先と方法に依存するため、すべてタイムアウトしても、すべてのノードが停止しているとは限りません。ノードを1つ選んで実際に対象サイトへアクセスし、ログも確認します。ドメインの名前解決に失敗する場合はDNSを優先して調べ、接続拒否やハンドシェイク失敗の場合はサーバー、ポート、プロトコル、認証情報を確認してください。一部のサイトだけで問題が起きるなら、一致したルールと接続先のサイトも調べましょう。すぐにクライアントを再インストールしたり、設定をすべて消去したりしないでください。

まずコアが混合ポートで正常に待ち受けていることを確認し、OSのプロキシアドレスとポートがクライアントの設定と一致しているか調べます。7890はよく使われる値ですが、固定の必須ポートではありません。ログにaddress already in useと表示されたら、使用中のプロセスを特定し、別のプロキシが動作していないか確認してください。重複したプロセスを終了するか、空いているポートに変更します。変更後は手動プロキシ、ブラウザー拡張機能、環境変数も合わせて更新してください。コアが正常に動作しているのに接続できない場合は、ブラウザーが独自プロキシを使っていないか、組織のポリシーで管理されていないかを確認しましょう。不明なシステムプロセスをむやみに終了したり、外部コントローラーポートをプロキシポートに設定したりしないでください。

アプリがネットワーク分離の制限を受けるAppContainerに属し、ローカルのループバックプロキシへ接続する場合は、個別にループバック免除を設定する必要があることがあります。ただし、ストアアプリがすべて該当するわけではありません。まずアプリがシステムプロキシを使っているか確認し、サブスクリプションのノードやアプリのサービス自体に問題がないことを確かめてください。管理者権限のターミナルでCheckNetIsolation LoopbackExempt -sを実行すると、既存の免除を確認できます。その後、クライアント付属のツールを使い、必要なアプリだけに許可を設定してください。TUNも別の通信経路ですが、正しいルートとDNS設定が必要です。すべてのアプリを一括で免除せず、調査後は不要になった許可を取り消しましょう。