Clashのよくある質問

Clashは、プロキシコアや設定エコシステムを指す名称として広く使われています。mihomoは関連する設定体系を引き継ぐオープンソースのコアで、Clash Verge Revはコアを利用するデスクトップ向けGUIクライアントです。サブスクリプションの追加、トレイメニュー、自動起動はクライアントの機能であり、ルール判定、DNS、通信の転送は主にコアが処理します。設定の互換性を確認するときは、画面に表示されたClashの文字だけで判断せず、クライアント名と実際に動作しているコアの両方を確認してください。

クライアントは設定を読み込み、通信を転送するソフトウェアであり、それ自体が利用可能なプロキシサービスではありません。初回利用時は、利用権限のあるサブスクリプションURLまたはローカル設定を用意し、読み込んで選択した後、プロキシグループで利用可能な出口を選びます。そのうえでシステムプロキシを有効にするか、必要に応じてTUNを設定します。クライアントを起動しただけで、すべてのアプリが自動的にプロキシを使うわけではありません。設定が有効になっていること、コアが正常に起動していること、対象アプリが適切な接続方法を使っていることも確認してください。

ルールモードはルールの順序に従って、接続ごとに使用するポリシーを決めるため、日常的な通信の振り分けに適しています。グローバルモードは、コアに入った通信をグローバルポリシーグループに渡します。ダイレクトモードでは、コアに入った通信が宛先へ直接接続します。グローバルモードにしても端末全体の通信が必ず制御されるわけではなく、DNSや利用できない出口の問題も自動では解決しません。原因を切り分ける際は一時的にグローバルモードへ切り替えて結果を比較し、確認後はルールモードに戻しましょう。ルールの問題と通信の取り込みに関する問題を混同しないことが大切です。

まずシステムプロキシを使って、ブラウザーに接続できるか確認しましょう。システムプロキシ設定に従うアプリ向けの方法ですが、一部のゲーム、コマンドラインツール、独自のネットワーク機能を持つアプリでは使われないことがあります。TUNは仮想ネットワークインターフェースとルーティング設定で通信を取り込むため、こうしたアプリも扱いたい場合に便利です。ただし、権限やDNS、他のVPNとの互換性に注意が必要です。システムプロキシとTUNは通信の入口、ルールモードとグローバルモードは転送方針です。TUNを有効にしてもルールモードを利用でき、必ずしもグローバルモードにする必要はありません。

Clash for Windowsはすでにメンテナンスが終了しています。既存のインストールが引き続き動作する場合もありますが、今後のOS互換性やコアの新機能を、アーカイブ版で解決できるとは限りません。新たに導入する場合は、ダウンロードセンターで現在もメンテナンスされているクライアントを比較してください。移行前にサブスクリプションの入手元、ルールの上書き設定、必要なローカル設定を保存し、古いフォルダーをそのまま上書きしないようにしましょう。新しいクライアントに設定を読み込み、接続を確認してから古いクライアントを終了し、古い自動起動設定を削除してください。2つのプロセスがポートを奪い合ったり、システムプロキシを繰り返し変更したりするのを防げます。

クライアントのサブスクリプションまたは設定画面で、リモート設定の追加を選びます。サブスクリプションURLを省略せずに貼り付けて保存し、ダウンロードと解析が完了したら、その設定を選択してください。WebアカウントのURL、購入ページ、サブスクリプションURLは別のものです。サービス提供元のサブスクリプション画面からURLをコピーしましょう。URLの前後に空白や改行、チャットアプリが付けた句読点が入らないようにしてください。サブスクリプションURLには認証情報が含まれる場合があります。公開フォーラムに投稿したり、提供元が不明なオンライン変換サイトに入力したりしないでください。

ファイルを読み込んだだけでは、通常は設定が追加されるだけです。設定一覧で対象を選び、コアが正常に再読み込みされたことも確認してください。まずログを確認し、構文エラー、ポリシーグループの不足、存在しないルール参照などの表示がないか調べます。YAMLのインデントにはスペースを使い、タブと混在させないでください。プロキシグループ名とルール内の参照名も一致させる必要があります。外部ルールセットを使う設定では、必要なリソースを取得できるかも確認しましょう。変更前にコピーを保存し、一度に一か所だけ変更すると、再読み込み結果を比較しやすくなります。

クライアントの設定にあるポートまたはネットワークの項目で混合ポートを確認してください。実際の画面と現在の実行設定を基準にし、別のクライアントの初期値をそのまま使わないようにしましょう。混合ポートはHTTPとSOCKSのプロキシ接続を受け付けます。アプリには、使用するプロトコルに合わせてローカルアドレスとこのポートを指定してください。外部コントローラーのアドレスはコアの管理用であり、ブラウザーのプロキシ接続先ではありません。ポートを変更したら、ブラウザー拡張機能、端末の環境変数、その他の手動プロキシ設定も更新し、ポート競合のログが出ていないか確認してください。

まずTUNを無効にし、通常のシステムプロキシで接続できることを確認してから、仮想ネットワークアダプターの問題を調べてください。デスクトップクライアントによっては、サービスモードのインストールと起動、またはシステムの許可を通じたネットワーク管理権限が必要です。詳しくはクライアントの設定説明を確認してください。Windowsではサービスの状態やドライバーのブロックを確認します。macOSとLinuxでは、権限の付与状況と関連ログを確認してください。許可を設定したらTUNを再度有効にします。警告を回避するためだけにシステム保護を無効のままにしたり、提供元不明のネットワークドライバーをインストールしたりしないでください。

設定を追加したら、まず対象の設定とプロキシポリシーを選択して接続を有効にし、システムからVPN設定の権限が付与されていることを確認します。Androidでアプリごとのプロキシを有効にしている場合は、対象アプリが通信の取り込み対象になっているか確認してください。iOSでは、現在の接続に追加した設定が使われているか確認します。通常、VPNベースのプロキシやフィルタリングツールを複数同時に動作させることはできません。切り替える前に、ほかのツールを切断してください。バックグラウンドで切断されやすい場合は、バッテリー管理とバックグラウンド実行の権限も確認しましょう。サブスクリプションをダウンロードできたことと、接続できたことは別です。

サブスクリプションの詳細にある編集または更新設定で、自動更新のオン・オフと間隔を確認してください。画面によって単位が分、時間、秒のいずれかの場合があります。まずはサービス提供元の推奨設定を使い、特に指定がなければ1日1回を目安にします。設定の変更が多い場合は、間隔を適宜短くしてください。更新頻度が高すぎると、サーバー側で制限されることがあります。設定後に手動更新を試し、URLにアクセスできるか確認しましょう。スリープ中やクライアント終了中に自動更新が停止するかも確認してください。自動更新を設定しても、現在接続できない出口が自動的に復旧するわけではありません。

リモートサブスクリプションを更新すると、通常は設定が再生成されます。ダウンロードしたYAMLを直接編集すると、更新時に変更が上書きされることがあります。クライアントの上書き設定、設定のマージ、スクリプト拡張機能などを優先して使い、その機能がどのサブスクリプションに適用されるか確認してください。ルールは記載順に判定されるため、特定のドメインに対するルールは、より広範なルールや最後のフォールバックルールより前に置くのが一般的です。保存後、実行中の設定と接続詳細を確認し、ルールが意図した位置に追加されているか確かめましょう。エディターに表示されているだけでは、コアに読み込まれたとは限りません。

自動起動は通常、システムへのログイン後にクライアントを起動する設定です。サイレント起動は、起動時にメインウィンドウを表示しない設定を指します。システムプロキシ、TUN、前回の設定を復元するかどうかは、クライアントの個別設定で決まります。まずクライアントを通常終了して再度起動し、各状態が復元されるか確認してから、再ログイン時の動作を試してください。サービスモードを使っている場合は、バックグラウンドサービスの起動方法も確認します。古いクライアントの自動起動、システムのタスクスケジューラ、新しいクライアントの自動起動を同時に残さないでください。プロセスが重複し、プロキシ設定が互いに上書きされるおそれがあります。

クライアントでLAN接続を有効にし、待ち受けアドレスがLANからのアクセスを許可していることを確認します。次に、別の端末でパソコンのLAN内IPアドレスと混合ポートを指定してください。両方の端末が相互に通信できるネットワークに接続されている必要があります。ファイアウォールでは、信頼できるネットワークに限り、必要なポートを許可してください。アドレスにループバックアドレスを指定したり、ルーターでプロキシポートをインターネットに公開したりしないでください。LAN接続は明示的なプロキシの接続先を提供するもので、透過プロキシとは異なります。手動プロキシに対応していないアプリには、別途ゲートウェイやルーティングの構成が必要です。

多くの端末ツールは、デスクトップのシステムプロキシ設定を参照しません。ツールの引数やHTTP_PROXY、HTTPS_PROXYなどの環境変数でプロキシを指定する必要があります。まずクライアントの混合ポートを確認し、ツールが対応するプロキシ引数で一度テストしてください。接続できたら、端末の設定に追加するか検討します。接続先がHTTPSでも、プロキシの接続方式までHTTPSである必要はありません。クライアントが実際に提供している接続先を指定してください。既存の環境変数、NO_PROXY、ツール独自の設定が互いに上書きし合う場合があるため、切り分け時はすべて確認しましょう。

まず、エラーがネットワーク接続の失敗、HTTPステータスの異常、内容の解析失敗のどれに当たるか確認します。前の2つはネットワーク、URLの有効期限、サーバーの状態を調べてください。解析に失敗する場合は、ログイン画面やエラーメッセージ、別形式のデータではなく、クライアントが対応する設定が返されているか確認します。サービス提供元にアカウントとURLの状態を問い合わせ、必要に応じて現在のコアに対応したURLをコピーし直してください。1回タイムアウトしただけで無効と判断したり、同じURLを何度も読み込んで問題を覆い隠したりしないでください。エラーの種類を記録してから、一つずつ対処しましょう。

まずプロキシを切断した状態で、通常のネットワークが使えるか確認します。次に、システム時刻、サブスクリプションの有効期限、クライアントログの接続エラーを調べてください。タイムアウトテストの結果は、テスト先や方法に左右されるため、異常が出ても実際の通信がすべて失敗しているとは限りません。利用可能と分かっている出口を選び、実際にWebページへ接続してみましょう。現在のネットワークと、信頼できる別のネットワークでも比較してください。ログに認証エラーがある場合は、認証情報を更新するかサービス提供元に問い合わせます。複数のツールが同時に通信を取り込んでいる場合は、ほかのプロキシやVPNを終了して再確認してください。

まずシステムプロキシのアドレスとポートが、クライアントの混合ポートと一致しているか確認します。次に、ブラウザーの拡張機能や個別のプロキシ設定がシステム設定を上書きしていないか調べてください。新たにアクセスを試し、クライアントの接続詳細に該当する通信が記録されるか確認します。記録がなければ、アプリの接続方法、バイパス設定、ほかのプロキシソフトを重点的に確認します。記録がある場合は、マッチするルールと出口を調べましょう。システムプロキシを何度も切り替える必要はありません。テスト中は明確なプロキシ設定を1つだけ使い、古いポートや自動設定スクリプトが同時に有効にならないようにしてください。

一部のAppContainerアプリにはローカルループバックの制限があります。デスクトップブラウザーからは接続できるのに、そのアプリからローカルプロキシへ接続できない場合は、この制限を確認してください。クライアントにUWPループバック用のツールがある場合は、案内に従って許可を設定し、必要なアプリだけを対象にします。Windowsの管理に詳しいユーザーは、CheckNetIsolationで既存の許可設定を確認することもできます。ストアアプリがすべて同じネットワークモデルを使うわけではないため、一律に設定しないでください。変更後に対象アプリを再起動し、解決しない場合は、システムプロキシへの対応状況とネットワーク権限を確認しましょう。

まずTUNを無効にし、ほかのVPNを終了して、DNSの取得方法を自動に戻します。システムプロキシが停止済みのローカルポートを参照していないかも確認してください。システムプロキシをオフにすると接続が復旧する場合は、残っているプロキシ設定を先に処理します。TUNを有効にしたときだけ失敗する場合は、仮想ネットワークアダプター、ルート、DNSのログを確認し、ほかのネットワークツールとの競合を調べましょう。DNS、ルール、TUNのネットワークスタックを同時に変更しないでください。元の設定を保存し、一度に一項目だけ変更します。通常の接続を復旧してから、クライアントの推奨設定に従って通信の取り込みを再度有効にしてください。