Clash よくある質問

クライアントはクリックして操作する画面、コアは接続を処理してルールを適用するプログラム（mihomoなど）、サブスクリプションは設定を取得・更新するためのURLです。この3つは別のものです。クライアントをインストールしたら、通常は利用権限のあるサブスクリプションかローカル設定を取り込み、選択して起動します。クライアントが起動しても、サブスクリプションが利用できるとは限りません。また、サブスクリプションを更新できても、すべてのノードに接続できるとは限りません。トラブル対処では、画面、設定の取得、実際の接続のどの段階で問題が起きているかを確認しましょう。

普段は、設定内のルールに従って通信を指定のポリシーへ振り分けるルールモードを使いましょう。グローバルモードは、コアに入った通信をグローバルポリシーへ送るため、短時間の比較や切り分けに向いています。ダイレクト接続モードでは、コアに入った通信が接続先へ直接つながります。モードを切り替えても、どのアプリの通信がコアに入るかは変わりません。対象となる通信は、システムプロキシ、アプリ側の設定、TUNによる取り込みなどで決まります。グローバルモードでもページが開かない場合、ルールの誤りと決めつけず、グローバルポリシー、ノードの接続状況、名前解決も確認してください。テスト後は元のモードに戻しましょう。

ノードは個別のプロキシ接続設定、プロキシグループはノードやダイレクト接続、ほかのグループをまとめて選ぶための入口です。ルールは通常、個々のノードではなくプロキシグループ名を参照します。変更したグループが現在の通信に適用されていなければ、接続経路は変わりません。まず接続一覧から対象ドメインを見つけ、適用されたルールとポリシーの経路を確認してから、該当するグループを変更してください。自動選択グループでは、ヘルスチェックによって接続先が再選択される場合があります。接続先を固定するには、設定にある手動選択グループを使います。

最初から両方を有効にする必要はありません。システムプロキシは、システム設定に従うアプリにプロキシのアドレスを通知する仕組みです。TUNは仮想ネットワークインターフェースを使い、ルーティング条件に合う通信を取り込みます。対象範囲はクライアントと設定によって異なります。まずシステムプロキシでブラウザーの接続を確認し、ゲームやコマンドラインなど、必要なアプリに応じてTUNを有効にするとよいでしょう。トラブル対処では一度に一つの設定だけ変更し、通信を取り込む経路同士が干渉しないようにします。TUNを有効にしても、すべての通信が必ずプロキシを通るわけではありません。実際の経路はルーティング、ルール、アプリの通信動作によって決まります。

まずサブスクリプション提供元のアカウントページで、サービスの状態、有効期限、データ容量を確認します。次にクライアント専用のサブスクリプションURLをコピーし直し、前後の空白や改行がないか確認してください。ログインページのURLがサブスクリプションURLとは限りません。応答が通常のWebページ、ログイン画面、エラーページの場合、クライアントは設定として読み込めません。更新ログのステータスコードも確認しましょう。401や403はアクセス権限、404はURLの変更、429は時間をおいて再試行する必要があることを示す場合があります。アクセス情報を含むサブスクリプションURL全体を、公開の掲示板に投稿しないでください。

取り込んだ設定が現在の設定として選択されているか確認します。設定一覧に表示されているだけでは、実行中とは限りません。次に、取り込み結果にプロキシノードまたはプロキシグループが含まれているか確認し、グループ自体の更新エラーも調べてください。ノード一覧だけを提供するサブスクリプションは、そのままでは完全な実行設定として使えない場合があります。また、設定によっては追加リソースの取得が必要です。既存ファイルをすぐに上書きせず、動作する設定を残したうえで、提供元が指定するクライアント形式とコアの互換性を確認しましょう。更新できたら、プロキシグループに選択肢が表示されるか確認します。

YAMLはインデントで階層を表すテキスト形式です。まず元のファイルをコピーし、ログに表示された行番号の前後を確認します。特にコロン、リストのハイフン、スペースによるインデントをチェックしてください。タブとスペースを混在させず、特殊文字を含む文字列はYAMLの構文に従って引用符で囲みます。構文チェックに通ったら、プロキシグループが参照するノード名やルールが参照するグループ名が実在するか、名前が一致しているかも確認しましょう。一度に少しずつ変更して再読み込みします。それでも失敗する場合はバックアップに戻し、複数の項目をまとめて変更せず、マニュアルと照らし合わせながら確認してください。

TUNで仮想ネットワークインターフェースを作成したりルートを変更したりするには、追加の権限が必要な場合があります。まずクライアントに表示される手順を確認してください。Windowsではサービスのインストールと起動、macOSではヘルパーツールの許可が必要になることがあります。Linuxでは導入方法に応じた権限やサービス管理が必要です。許可したらTUNを再度有効にし、インターフェースの作成に失敗していないかログを確認します。出所のわからないスクリプトでシステム権限を一括変更しないでください。管理対象の端末では、組織のポリシーで許可されているか先に確認しましょう。必要な権限があっても失敗する場合は、ほかのVPN、仮想ネットワークアダプター、セキュリティソフトとの競合を調べます。

プロキシグループのボタン表示だけでなく、接続一覧にある実際の通信を確認してください。クライアントの接続画面を開いてから対象サイトを再読み込みし、ドメイン名やアプリ名で通信を探します。適用されたルール、使用中のポリシー、最終的な接続ノードを確認しましょう。Webページは複数のドメインに同時にアクセスすることがあるため、ページ本体と画像・動画の通信経路は異なる場合があります。ルールは通常、上から順に照合され、最初に一致したルールが適用されます。末尾のMATCHは、それまでのルールに一致しなかった場合のフォールバックです。古い接続が表示されている場合は、そのサイトのタブを閉じて開き直し、新しい接続を確認してください。

サブスクリプションを更新すると、通常はリモート設定が再取得されます。サブスクリプションのファイルに直接書き加えた内容は、更新時に上書きされることがあります。クライアントに上書き、マージ、拡張機能があれば優先して使い、カスタム設定をリモート設定と分けて保存しましょう。機能名やマージ順序はクライアントごとに異なるため、別のクライアントの記述方法をそのまま使わないでください。変更後は最終的に適用される設定を確認し、カスタムルールが適切な位置にあり、参照先のプロキシグループが存在することを確かめてから、手動更新を試します。上書き設定を保持できないクライアントでは、ローカル設定を別に管理できますが、ノードやルールの更新は自分で行う必要があります。

まず、変更したのが対象の通信で実際に使われるプロキシグループか確認し、古い接続が残っていないか調べます。アプリによっては長時間接続を再利用するため、ポリシーを切り替えても確立済みのセッションは切断されないことがあります。対象のWebページを閉じるかアプリを終了してから、もう一度リクエストを送ってください。必要であれば、ほかの通信を中断しないよう、クライアントの接続一覧から該当する接続だけを切断します。出口IPの確認ページがキャッシュを使っている場合もあるため、接続一覧と新しいテストリクエストをあわせて確認しましょう。ポリシーの経路に自動選択グループやネストしたグループがある場合は、外側のグループ名だけでなく、最終的に選択されたノードまで確認してください。

GeoIPはIPアドレスの地域情報をまとめたデータで、関連するルールの判定に使われます。サブスクリプションに含まれるノード情報とは別のリソースです。設定でGeoIPを使っている場合に限り、更新が該当する判定に影響します。まず現在のコアが使用するデータ形式を確認し、クライアントが対応する更新機能から取得してください。異なる形式のファイルをそのまま置き換えないようにしましょう。更新後はクライアントの手順に従って設定を再読み込みするか、コアを再起動し、テスト接続に適用されたルールを確認します。地域データだけで、すべてのサービスが期待どおりに振り分けられるとは限りません。特定のサイトを対象とする場合は、明示的なドメインルールのほうが確認しやすいことがあります。

タイムアウトは、今回のテストが制限時間内に完了しなかったことを示すだけで、サブスクリプションの期限切れを証明するものではありません。まず端末の通常のインターネット接続を確認し、ほかのノードも個別にテストして、特定のテスト先だけが失敗していないか調べましょう。一部のノードが使える場合は、ノードや回線の問題が考えられます。すべて失敗する場合は、端末の時刻、設定の読み込み結果、ネットワークの制限、ほかのVPNの影響も確認してください。遅延テストとWebサイトへの実際のアクセスは同じではないため、対象サービスにも接続してみましょう。トラブル対処では具体的なエラーと発生条件を記録し、提供元に問い合わせる際はサブスクリプションURLやパスワードなどの機密情報を隠してください。

まずシステムプロキシのアドレスがローカル端末を指しているか、ポートが現在のコアのHTTPプロキシまたは混合プロキシのポートと一致しているか確認します。よく使われるポート番号だけを頼りに判断しないでください。次にブラウザーの拡張機能、個別のプロキシ設定、プロキシの除外リストを確認します。アプリによってはシステム設定を無視することがあります。新しいWebページを開きながらクライアントの接続一覧を確認してください。新しい接続が記録されない場合は、通信がコアに入っているかを調べます。接続が記録されている場合は、ルールと出口を確認しましょう。別のプロキシソフトがシステム設定を繰り返し書き換えていないかも確認し、テスト後は通信を取り込む方法を一つに決めてください。

まず通常のブラウザーが同じプロキシ経由で接続できることを確認し、対象アプリがネットワーク分離の影響を受けるUWPアプリかどうかを調べます。ストアアプリがすべてUWPとは限りません。ループバックとはアプリがローカル端末のアドレスにアクセスすることです。一部のUWPアプリでは、これが既定で制限されています。クライアントにループバック免除ツールがある場合は、案内に従って管理者権限で起動し、必要なアプリだけを許可して保存してから、アプリを再起動して試してください。システムのドキュメントに従ってCheckNetIsolationで免除を管理する方法もあります。すべてのアプリを一括で許可しないでください。改善しない場合は、アプリ自体のネットワーク権限、プロキシ対応状況、ログを確認しましょう。

まずTUNとシステムプロキシを無効にし、クライアントを通常の手順で終了して、通常のネットワーク接続が復旧するか確認します。つながらない場合は、システムプロキシにローカルアドレスが残っていないか、ほかのVPNがルートを制御していないかを調べてください。最初からネットワーク設定全体をリセットするのは避けましょう。通常の接続に戻ったら、通信を取り込む方法を一つだけ有効にして再試行し、エラーがDNS、ルーティング、仮想インターフェースのどれを示しているか確認します。DNSはドメイン名をIPアドレスに変換する仕組みで、名前解決に失敗してもWebページが開かなくなります。ログと元の設定を保存し、最近の変更を一つずつ戻してください。必要に応じて端末を再起動してから、通常の接続を確認します。