Clashのよくある質問

Clashはプロキシ用コアとそのエコシステムの名称、ClashXはmacOS向けクライアントの名称、mihomoは継続的に開発されている互換コアです。クライアントはメニューやサブスクリプション管理、システム連携を担い、コアは接続、DNS、ルール処理を担います。クライアントによって同梱されるコアやメンテナンス状況、機能の場所は異なるため、名称だけでTUNや特定のプロトコルに対応しているかは判断できません。選ぶ際はプロジェクトの説明とコアの情報を確認し、各クライアントのドキュメントに沿って操作してください。

クライアントには接続や通信の振り分け機能がありますが、利用可能なプロキシサービスが付属するわけではありません。リモートサブスクリプションには通常、ノード、プロキシグループ、ルールが含まれます。自分で管理するローカルのYAML設定を使うこともできます。インポート前に、提供元が信頼できること、サービスの有効期限内であること、出力形式が現在のコアに対応していることを確認してください。サブスクリプションURLのトークンにはアクセス権限があることが多いため、スクリーンショットを公開したり、一般公開の変換サイトに送信したりしないでください。このサイトのサンプルURLは入力方法の説明用で、実際の接続には使えません。

普段はルールモードから使い始めるのがおすすめです。接続は設定内のルール順に従って、利用する出力先が選ばれます。グローバルモードでは、コアが処理する接続にグローバルポリシーを適用しますが、すべてのアプリの通信が自動的に捕捉されるわけではありません。システムプロキシやTUNも正しく有効にする必要があります。DIRECTモードはプロキシを経由せずに接続するため、比較検証に役立ちます。モードを切り替えたら新しい接続でテストしてください。既存の長時間接続は以前の経路を使い続ける場合があるため、同じページを再読み込みするだけで判断しないようにしましょう。

システムプロキシはOSにローカルプロキシのアドレスを登録し、その設定に従うアプリに適用されます。TUNは仮想ネットワークインターフェースを使い、ルーティング条件に合う通信を捕捉するため、通常はより広い範囲をカバーしますが、権限、ルート、DNSの設定が必要です。両方を同時に有効にする必要はなく、あらゆるネットワーク通信を捕捉できるとも限りません。初期設定ではまずシステムプロキシを確認し、ゲームやコマンドラインなど、実際の用途に応じてTUNを有効にしてください。複数の通信捕捉方法を同時に変更すると、原因の特定が難しくなります。

レイテンシテストで分かるのは、特定のテスト先に対して、その時点で指定ノードを経由した応答があったことだけです。すべてのWebサイト、プロトコル、ポートにアクセスできる保証にはなりません。実際の閲覧可否は、プロキシグループの選択、ルールの適用、DNSの名前解決、接続先サイトの制限にも左右されます。接続ログで対象ドメイン、適用ルール、実際の出力先を確認し、目的のアプリから新しいリクエストを送ってください。レイテンシの最小値だけでノードを選ばず、リクエストが連続して安定して完了するかを重視しましょう。

クライアントの「サブスクリプション」「設定」または「Profiles」画面でリモート設定を追加し、URL全体を貼り付けて保存します。その後、設定をダウンロードして選択してください。項目名や場所はクライアントによって異なり、保存できても設定が有効になったとは限りません。解析に失敗する場合は、提供元が互換性のあるClash YAMLを出力しているか確認しましょう。Webページ、単一のノードURL、Base64形式のノード文字列だけのデータには対応できません。まず提供元の変換機能を利用してください。変換が必要な場合は、トークンの漏えいやルールの書き換えに注意が必要です。

まずコアが起動していることを確認し、クライアントに表示されるローカルの待ち受けアドレスと混合ポートを確認します。次に、Windowsのプロキシ設定にあるアドレスとポートが一致しているか確認してください。すべての設定が7890を使うとは限りません。続いてブラウザー拡張機能、個別のプロキシ設定、プロキシの除外リストを確認し、システム設定が上書きされていないか調べます。新しいページを開いてクライアントの接続ログを確認してください。新しい接続が記録されない場合は通信の捕捉を、記録がある場合はルールとプロキシグループの実際の出力先を確認します。

まずアプリを「アプリケーション」フォルダに移動し、使用中のクライアントの案内に従って初回起動を完了してください。ネットワーク拡張機能、補助サービス、キーチェーンの許可画面が表示されるのは、それらを使う実装の場合だけです。すべてのClashXクライアントで同じ画面が表示されるわけではありません。システム設定で許可する場所はmacOSのバージョンによって異なるため、「プライバシーとセキュリティ」やネットワーク関連の設定を確認してください。許可する前に、要求元がインストールしたアプリであることを確認しましょう。以前に許可を拒否した場合は、プロジェクトのドキュメントに従って再度要求を表示させてください。システムのセキュリティ機能をそのまま無効にするのは避けてください。

まずTUNを無効にし、クライアントが現在のOSで使える通信捕捉方式に対応していることを確認します。次に、サービスモード、補助サービス、ネットワーク拡張機能がインストールされ、許可されているか確認してください。Windowsのクライアントではシステムサービスのインストールが必要な場合があります。Linuxではサービス権限やネットワーク管理機能、macOSでは実装に応じて補助プログラムや拡張機能の許可が必要です。現在のプロジェクトの説明に従い、必要な権限だけを付与してください。管理者として何度も起動することを、原因調査の代わりにしないようにしましょう。許可後にTUNを再度有効にし、インターフェース、ルート、起動ログを確認してください。

モバイル端末では通常、OSのVPNインターフェースを使って通信を捕捉します。初回接続時はシステムの許可が必要です。まず、別のVPN、広告ブロックアプリ、ファイアウォールアプリが同じ機能を使用していないか確認し、ほかの接続を切ってから再試行してください。Androidでは常時接続VPN、「VPNを使用しない接続をブロックする」設定、バックグラウンド動作やバッテリー制限も確認します。iOSでは既存のVPN構成とオンデマンド接続の設定を確認してください。設定が有効で、プロキシグループに利用可能なノードがあることを確認してから権限を見直すと、サブスクリプションの問題をシステム権限の問題と誤認しにくくなります。

サブスクリプション設定で適切な更新間隔を選び、定期更新にクライアントの起動が必要か確認してください。端末がスリープ中だったり、ネットワークが制限されていたりすると、更新が遅れる場合があります。リモート設定は更新時に全体が置き換わることが多く、直接編集したルールが失われる可能性があります。長期的に独自設定を使う場合は、クライアントが対応するオーバーライド、マージ、ルール拡張機能を利用してください。更新前に使える設定のコピーを保存し、更新後はプロキシグループ名と選択状態を確認しましょう。提供元がノードを削除したり名前を変更したりする場合にも注意が必要です。

selectは出力先を手動で指定する場合に適しています。url-testはテスト結果に応じてノードを選び、fallbackは設定された順に利用可能な候補を探します。これらの動作は、設定内のテスト先、間隔、候補リストに依存します。名前が似ていても動作は同じとは限りません。まずルールがどのグループを参照しているか確認し、そのグループ内に別のプロキシグループが含まれていないか調べてください。原因調査中は、動作確認済みのノードを一時的に固定すると、自動切り替えによる変動を減らせます。通常利用に戻す際に、自動グループの候補を調整してください。

ルールは上から順に評価され、通常は最初に一致したルールが適用されます。そのため、先行する広範なルールや最終ルールによって先に処理されていないか確認してください。ドメインルールはコアがドメイン情報を取得できるかどうかにも左右され、プロセスルールはプラットフォームやプロセス識別機能の影響を受けます。まず接続の詳細で実際の接続先、適用ルール、出力先を確認してから、該当するルールを変更してください。設定にルールが書かれているだけで適用されるとは限りません。保存して再読み込みした後、新しい接続で検証します。リモート設定の場合は、オーバーライドで変更を保持する方法を優先してください。

Fake-IPはアプリに仮想アドレスを返し、後続の接続でコアがそのアドレスとドメインを対応付けます。実際のサーバーアドレスではありません。LAN内の機器、特定のアプリ、ドメインの名前解決に互換性の問題がある場合は、まずリクエストがコアに届いているか、どのDNSが使われているか確認してください。互換性がないと分かったドメインは、現在のコアの構文に従ってfake-ip-filterに追加します。その後、クライアントの説明に従って再読み込みし、関連するDNSキャッシュを消去してください。すべてのドメインを除外リストに追加するのは避けましょう。DNSモードを切り替える前に、設定をバックアップして元の状態を記録してください。

まず問題が発生した時刻、OSのバージョン、クライアントとコアの情報を記録します。次に、問題を再現できる範囲でログレベルを一時的に上げ、通常はinfoから確認します。障害発生時刻付近の必要なログだけを出力し、提出前にサブスクリプションURL、トークン、認証情報、ノードのアドレス、個人用のアクセスドメインが含まれていないか確認してください。設定ファイル全体やサブスクリプション画面全体のスクリーンショットを公開しないでください。調査後は通常のログレベルに戻し、再現のために作成した機密情報を含むコピーを削除して、不要なアクセス情報が長期間残らないようにしましょう。

まずURLが完全で、余分な空白が入っていないことを確認し、更新ログを確認してください。401や403は認証情報やアクセス権限、404はURLの変更、429はリクエスト頻度の制限が原因であることが多いものの、提供元の案内も確認が必要です。接続タイムアウトの場合は、現在のネットワーク、DNS、サブスクリプションのダウンロードに使われる出力経路を確認します。ログイン画面やエラーページが返されると、クライアントで解析エラーになることもあります。何度も連続して更新するのは避け、サービスの有効期限を確認してから、提供元の案内に従ってURLを再発行または再取得してください。

まずほかのプロキシツールを終了し、通常のネットワーク接続が使えることを確認してから、ノードを1つ固定して明確なテスト先に接続します。ログに記録された接続失敗先を確認してください。ノードサーバーのアドレスなら、ノードの状態、ドメインの名前解決、ポート、ローカルネットワークの制限を重点的に調べます。接続先サイトなら、出力ポリシーも含めて原因を確認しましょう。ノードやネットワークを変えて比較し、一度に変更する項目は1つにします。1つのノードがタイムアウトしても、サブスクリプション全体が無効とは限りません。タイムアウトを解消するためにOSのファイアウォールを無効にするのも避けてください。

まず元のクライアントを再度起動し、システムプロキシとTUNを無効にしてから、通常の手順で終了し、ネットワークが復旧するか確認してください。アプリを起動できない場合は、OSのプロキシ設定に残っているローカルプロキシを削除し、手動DNSやVPN設定が残っていないか確認します。会社や学校のネットワークで必要なプロキシやDNSは削除しないでください。判断に迷う場合は、変更前の値を記録します。複数のプロキシツールを使っていた場合は、それぞれの通信捕捉状態を確認してください。必要に応じてネットワークに再接続してDNSキャッシュを消去し、復旧後はクライアントを1つだけ起動して確認します。

AppContainerで隔離された一部のアプリは、ローカルのループバックプロキシに直接アクセスできないため、ブラウザーが接続できても動作しない場合があります。まず、対象アプリが実際にシステムプロキシを使っていることを確認してください。次に、クライアント付属のUWPループバックツールでアプリ一覧を確認し、ローカルプロキシへのアクセスが必要なアプリだけを除外対象にします。操作には管理者権限が必要な場合があり、設定後は対象アプリを再起動してください。ストアアプリのネットワーク動作は一律ではありません。問題が続く場合は、すべてのアプリをまとめて許可するのではなく、個別のプロキシ設定、DNS、ログを確認してください。

GeoIPの更新に失敗した場合は、ログにあるダウンロード先、ネットワークエラー、ファイルへのアクセス権限を確認します。設定がGeoIPデータベースを使っているのか、別形式の地理ルールデータを使っているのかも確認してください。異なる形式のデータファイルを安易に置き換えることはできません。ログにaddress already in useと表示される場合は、ローカルポートのバインドに失敗しています。別のクライアントや重複したコアが起動していないか確認し、重複プロセスを終了するか、待ち受けポートを変更してシステムプロキシの設定も合わせて更新してください。この2つは別の問題なので、サブスクリプションを何度もインポートして対処しないでください。