Clashのよくある質問

クライアントは設定の読み込みやポリシーの切り替え、ログの確認を行うための画面を提供します。Mihomoなどのコアは実際の接続、ルール判定、DNS処理を担い、サブスクリプションはノードや一部の設定情報を提供します。クライアントをインストールしても、利用可能なプロキシサービスが付属するわけではありません。設定を始める前に、サブスクリプションの提供元、有効期限、対応形式を確認し、互換性のあるクライアントを選びましょう。問題の切り分けでは、画面操作の失敗、コアの起動失敗、サブスクリプションサービスの異常を区別します。

普段はルールモードがおすすめです。現在の設定にあるルールに従って、通信を直接接続またはプロキシのポリシーに振り分けます。グローバルモードでは、コアに届いたリクエストをすべてグローバルポリシーに渡しますが、利用可能なノードの選択は必要です。DIRECTモードでは、コアに届いたリクエストを接続先へ直接送ります。グローバルモードでも端末の全通信が自動的に取り込まれるわけではなく、コアを経由するかどうかはシステムプロキシ、アプリのプロキシ、TUNの設定によって異なります。モードを比較するとルールの問題を特定しやすくなりますが、テスト後は元の設定に戻してください。

公開はおすすめしません。サブスクリプションURLには通常、アカウントに紐づく認証情報が含まれており、URL全体を知っている人がノード情報を取得したり、サービスの利用枠を消費したりするおそれがあります。スクリーンショットを共有する際は、ドメイン名だけでなく、URLのパスやクエリ、ノードのパスワード、コントロールAPIのキーも隠してください。URLを公開してしまった場合は、提供元の管理画面で再発行し、各端末の古いURLを差し替えます。チャット履歴を削除しても、漏えいしたURLが無効になるわけではありません。

iOSではApp StoreからClash Plusをインストールできます。公式サイトはclashplus.ioです。本サイトのダウンロードページからApp Storeへ移動できます。読み込む前に、サブスクリプションの提供元がクライアント対応の形式を提供しているか確認してください。スクリプト、ルールセット、拡張フィールドの対応状況はクライアントごとに異なります。パソコンで使える設定がスマートフォンでもそのまま動くとは限りません。まず提供元が案内する互換性のあるサブスクリプションを読み込み、基本接続を確認してから、カスタムルールを一つずつ追加しましょう。

必ずしもそうとは限りません。一般的なノード速度テストでは、指定したテスト先への応答時間を測定します。これは接続の確立から応答を受け取るまでの時間であり、継続的なダウンロード帯域を直接示すものではありません。実際の速度は、接続先のサイト、回線の混雑、サービスの利用枠、ローカルネットワークにも左右されます。同じテスト先とネットワーク環境で比較し、実際に使うサービスでも確認してください。応答時間が短くても動画が止まる場合は、スループットやパケットロス、適用ルールも調べましょう。

まず、アカウントのログインページや購入ページではなく、サブスクリプションURL全体をコピーしているか確認します。特に、チャットアプリによって末尾が切れていないか注意してください。次に提供元の管理画面でサービスが有効か、URLが再発行されていないかを確認し、サブスクリプションの形式がコアの要件に合っているか調べます。ログに認証エラーが出る場合は、URLとアカウントを優先して確認します。設定の解析エラーなら、返された内容がWebページになっていないか、互換性のない設定ではないかを確認してください。サブスクリプションURL全体を公開の検査サイトに入力しないでください。

現在のクライアントがサブスクリプションの形式に対応しておらず、提供元から互換URLも提供されていない場合に限り、変換を検討してください。まず提供元が用意する形式の選択肢を使い、次に自分で管理できるローカル変換ツールを検討します。第三者のオンライン変換サービスには、サブスクリプション全体やノードの認証情報が渡る可能性があるため、利用前に信頼できるサービスか判断してください。変換後はプロキシのプロトコル、ポリシーグループの参照先、ルールセットのURLを確認します。変換で形式は調整できますが、期限切れのアカウントや無効になったノードは復旧できません。

まずクライアントにサービスモードや補助サービスのインストール機能があるか確認し、使用中のバージョンの案内に従ってインストールしてから、クライアントを再起動します。Windowsでは関連サービスのインストールに管理者権限が必要な場合があります。macOSでは補助ツールやネットワーク拡張の許可が求められることがあります。Linuxでは仮想ネットワークインターフェースの作成やルート設定を行う権限が必要です。それでも失敗する場合は、ログで権限、インターフェース作成、ルートの競合に関する情報を確認してください。出所不明の権限昇格コマンドをそのまま実行したり、システムのセキュリティ機能を長期間無効にしたりしないでください。

まずコアが起動していることと、システムプロキシの接続先が現在のクライアントで実際に待ち受けているアドレスとポートであることを確認します。以前のクライアントが残したポートを指定していないかも確認してください。ブラウザー拡張機能が別のプロキシを指定していないか、接続先のドメインがシステムプロキシの除外リストに含まれていないかを調べます。その後、新しいリクエストを送り、接続ログに表示されるか確認します。ログに表示されるのに直接接続される場合はルールやモードを、表示されない場合はアプリ側の設定を確認してください。システムプロキシを参照しないアプリは、個別にプロキシを設定するかTUNを使う必要があります。

例として示されたポートを固定値と考えず、クライアントの現在の設定に表示されている待ち受けポートを使ってください。Mixedポートは通常、HTTPとSOCKSの両方のプロキシリクエストを受け付けます。アプリがHTTPプロキシを要求する場合はHTTPまたはMixedポートを、SOCKS5を要求する場合はSOCKSまたはMixedポートを指定します。同じ端末上のアプリでは通常127.0.0.1を使い、別の端末から接続する場合はプロキシを動かしている端末のLANアドレスを指定します。ポート番号が同じでもプロトコルの指定方法は異なるため、アプリの入力欄に合わせて選んでください。

サブスクリプションの更新では、通常、リモートの設定が再取得されます。サブスクリプションから生成されたファイルを直接編集すると、変更が上書きされることがあります。まず既存のルールをバックアップし、クライアントがオーバーライド、マージ、独立したルールファイルに対応しているか確認して、個別の変更はその永続化できる場所に保存してください。マージ後はルールの順序やポリシーグループ名が有効か確認し、特にカスタムルールがフォールバックルールより前にあることを確かめます。サブスクリプションURLのエクスポートだけでは、通常ローカルのオーバーライドは保存されません。複数端末へ移行する場合は、関連ファイルも別途バックアップしてください。

クライアントの接続画面を開き、不要なログを消してから対象サイトに再アクセスします。対象ドメイン、適用されたルール、ポリシーの経路、最終的な出口を確認してください。ルールは通常、上から順に照合されるため、先に一致したルールが後続の判定に影響します。変更後は既存の接続を切ってから再テストしてください。Webページは複数のドメインに同時にリクエストする場合があり、アドレスバーのドメインだけでは画像やログインAPIへの接続を見落とすことがあります。接続ログに該当リクエストがまったくない場合は、ルールを変更する前に通信の取り込み方法を確認しましょう。

可能ですが、端末同士が通信できるLANに接続されている必要があります。パソコンのクライアントでLAN接続を許可し、LANからのリクエストを受け付けるアドレスで待ち受けるように設定してください。ファイアウォールでは、信頼できるネットワークに限って必要なポートを許可します。スマートフォンのネットワーク設定では、パソコンのLANアドレスとHTTPまたはMixedポートを指定し、127.0.0.1は入力しないでください。Wi-FiのHTTPプロキシ設定に従わないアプリもあります。利用後は共有を停止し、プロキシポートや外部コントロール用インターフェースをインターネットに直接公開しないでください。

常に両方を有効にする必要はありません。ブラウザーなどシステム設定に従うアプリは、まずシステムプロキシを使います。システムプロキシに従わないアプリの通信も取り込みたい場合に、TUNの使用を検討してください。TUNは通信の入口や一部のルーティング動作を変更するため、ほかのVPN、仮想ネットワークアダプター、セキュリティソフトと併用すると競合することがあります。問題を切り分ける際は、まず取り込み方法を一つだけ有効にし、接続とDNSが正常なことを確認してから併用を検討します。モードを変更する前に元の設定を記録し、複数の項目を同時に変更して原因が分からなくならないようにしましょう。

サブスクリプションURLは互換性のあるクライアント間で再読み込みできますが、ローカルのオーバーライド、ルールファイル、ポリシーの選択、アプリの設定は同期されないことがあります。移行前にサブスクリプションの入手元とローカルの変更内容をそれぞれ記録し、クライアントのエクスポート機能でバックアップしてください。待ち受けアドレス、ファイルのパス、TUN設定は端末によって異なるため、設定一式をそのまま上書きするのは避けましょう。クラウドストレージやWebDAVを使う場合はアクセス権を制限してください。サブスクリプションの認証情報やノードのパスワードを含むバックアップは、安全な方法で保管します。

まずプロキシを無効にして、通常のネットワーク接続を確認します。次にシステム時刻とサブスクリプションの有効期限を確認し、設定を更新してください。速度テストの接続先にアクセスできることを確かめたうえで、複数の回線を手動で試し、ログに名前解決失敗、接続拒否、ハンドシェイクエラーが出ていないか確認します。同じサブスクリプションが別のネットワークで使える場合は、現在のネットワーク制限、端末のファイアウォール、DNSを優先して調べます。端末やネットワークを変えても失敗する場合は、提供元にサービス状況を確認してください。一つのテスト先だけで、すべてのノードが使えないと判断しないでください。

まずクライアントを再起動し、システムプロキシとTUNを無効にしてから正常に終了します。これにより、クライアントがプロキシやルートの設定を解除できます。クライアントを起動できない場合は、OSのネットワーク設定を開き、ローカルのポートを指す手動プロキシ設定が残っていないか確認します。該当クライアントの設定だと確認できたものだけを削除し、職場のネットワークで必要な設定は残してください。それでも解決しない場合は、仮想ネットワークアダプター、ほかのVPN、DNS設定を確認します。復旧前に元の値を記録し、企業ネットワークや固定IP設定に影響しないよう、ネットワーク設定を一括で初期化しないでください。

AppContainerで隔離された一部のアプリでは、ローカルプロキシへのアクセスがループバック制限を受けることがあります。すべてのストアアプリで同じ問題が起きるわけではありません。まずブラウザーがシステムプロキシ経由で正常にアクセスできることを確認し、次にクライアントにUWPループバックツールがあるか調べます。必要なアプリだけを例外に設定してください。操作には管理者権限が必要な場合があります。ループバックの例外設定で解決できるのはローカルプロキシへのアクセス制限だけで、すべてのアプリが自動的にシステムプロキシを使うようになるわけではありません。設定後は対象アプリを再起動し、接続画面でリクエストがコアに届いているか確認してください。

まずログに名前解決の失敗が明記されているか確認し、ノードサーバーのドメインを解決できないのか、接続先サイトのドメインで失敗しているのかを切り分けます。前者ではプロキシ接続を確立する前に使える名前解決経路を確認し、後者では設定のDNS振り分けとルールも調べます。TUNやクライアントのDNS機能との重複を避けるため、ほかのDNS制御ツールは一時的に無効にしてください。設定は一度に一つだけ変更し、既存の接続を切ってから、OSの方法でキャッシュを更新して再テストします。よく使われるDNSアドレスだからという理由だけで、設定全体を置き換えないでください。

まず設定とローカルのオーバーライドをバックアップし、OS、端末のアーキテクチャ、クライアント名、障害直前に行った操作を記録します。クライアントが指定するログフォルダーやOSのクラッシュ記録でエラーを確認し、起動失敗の前後にある情報を中心に保存してください。設定が原因と思われる場合は、バックアップを取ったうえで最小構成で検証し、すべてのデータをすぐに削除しないでください。ログを共有する前に、サブスクリプションURL、パスワード、コントロールAPIのキーを隠します。一時的に以前のバージョンへ戻す場合も、設定形式がそのバージョンに対応しているか確認してください。