Clash よくある質問

クライアントは設定管理やポリシー選択、システムプロキシの切り替えを行います。コアは設定の解析、ルールの照合、接続の確立を担当します。サブスクリプションでは、サービス提供元からノードや設定一式が提供されます。クライアントをインストールしても、利用可能なプロキシサービスが自動で使えるようになるわけではありません。トラブル時は、画面上の操作、コアのエラー、サブスクリプションの状態を切り分け、混同しないようにしましょう。同じサブスクリプションでも、実際に使うコアと対応フィールドによってクライアント間の互換性は異なります。移行前にクライアントの「バージョン情報」やコア設定でコア名を確認し、インポートログも確認してください。

通常はルールモードを使い、設定内のルールに従ってプロキシ経由か直接接続かを決めます。グローバルモードでは、コアに渡された接続をグローバルポリシーで処理します。DIRECTモードでは、通常それらの接続が接続先へ直接アクセスします。グローバルモードでも、端末上のすべてのアプリの通信が自動的に取り込まれるわけではありません。通信がまずコアに届く必要があります。特定サイトへの接続失敗がルール分岐によるものか確かめるには、一時的にグローバルモードへ切り替え、同じノードで比較してください。テスト後はルールモードに戻します。どちらのモードでも失敗する場合は、ノード、名前解決、端末側の通信取り込み経路を確認しましょう。

システムプロキシはHTTPまたはSOCKSプロキシの接続先をOSに登録しますが、それを使うかどうかはアプリ次第です。一部のゲーム、コマンドラインツール、独自のネットワーク機能を持つソフトは、システムプロキシを参照しません。TUNモードは仮想ネットワークインターフェースとルーティングで通信を取り込むため、一般により広い範囲をカバーします。その分、必要な権限やDNS設定もあります。ブラウザーでは接続できるのに特定のアプリだけ失敗する場合は、まずそのアプリがシステムプロキシに対応しているか確認し、それからTUNの使用を検討してください。ルーティングを取り込むクライアントを複数同時に起動すると、デフォルトルートの競合や二重転送が起きやすくなります。

利用できるかどうかはノードのプロトコル、設定形式、サーバーの状態によって決まり、料金の有無だけでは判断できません。いわゆるVPNサービスのサブスクリプションは、設定を取得するための非公開URLであることが一般的です。公開ノードはいつ使えなくなるかわからず、運営元やデータの取り扱いも確認しにくい場合があります。インポート前に提供元、対応コア、利用規約を確認し、複数の設定一式をそのまま結合しないでください。統合する場合は、クライアントが対応するマージ機能やルールの上書き機能を使い、元の設定に戻せるようにしておきましょう。このページではノードの提供やサブスクリプションの運営は行っていません。

どちらも確認してください。まずWindows、macOS、Android、LinuxからOSに合うクライアントを選び、次に端末のアーキテクチャに合ったパッケージを選びます。x64とAMD64は通常同じ系統のアーキテクチャを指し、ARM64は別のプロセッサ向けです。macOSでは「このMacについて」、Windowsでは「システム情報」でチップやシステムの種類を確認できます。Androidでは端末の仕様も確認してください。OSのバージョンだけでアーキテクチャを判断しないようにしましょう。インストール後に起動できない場合は、表示されたエラーを記録してクライアントの最低動作要件を確認してください。同じ非対応パッケージを何度もインストールしないでください。

まずサービス提供元の管理ページで、有効期限、アカウントの状態、URLが再発行されていないかを確認します。コピー時に空白や改行、ページの説明文が混入していないかも確認してください。クライアントにHTTPステータスコードが表示される場合、401や403は認証、404はURLの変更、429は短時間の再試行を控える必要がある可能性があります。ダウンロードはできても解析に失敗する場合は、取得したものがログインページやノード共有用テキストではなく、クライアント対応の設定ファイルか確認しましょう。ログやスクリーンショットを共有する際は、サブスクリプションURL全体を隠してください。漏えいした場合は、提供元のページからURLを再発行します。

まず権限の問題か設定ミスかを切り分けます。デスクトップ版では、サービスコンポーネントのインストールや補助プログラムの許可、初回設定時の管理者権限が必要な場合があります。Androidでは通常、システムのダイアログでVPN接続を許可します。許可した後も、権限、デバイス作成、ルート設定に関するエラーがログに残るか確認してください。コンポーネントのインストールに失敗した場合は、クライアントの手順に従ってサービスを再インストールします。システムドライバーをむやみに変更したり、セキュリティ機能を無効にしたりしないでください。他のVPNや仮想ネットワークインターフェースを使うソフトも終了します。設定の解析に失敗している場合、権限を上げてもフィールドやインデントの誤りは直りません。

まず元のファイルを保存し、ログにある行番号とフィールド名を確認します。YAMLの階層にはスペースを使い、リスト項目、コロン、インデントの対応を確認してください。ポリシーグループ名とルールから参照される名前も、大文字・小文字や空白を含め完全に一致させます。プロトコルやフィールドが未対応と表示された場合は、該当行をすぐ削除せず、コアとの互換性を確認してください。一度に変更するのは一か所だけにし、再読み込みして原因を特定します。サブスクリプションの更新後に問題が起きた場合は、直前に使えていた設定へ戻し、個人情報を伏せたエラー部分とクライアントのコア名を提供元へ伝えましょう。

ポリシーグループで選んだノードが適用されるのは、そのグループを参照する接続だけです。まずクライアントがルールモードになっていることを確認し、接続履歴から対象のリクエストを探して、実際に適用されたルールと最終ポリシーを確認してください。DIRECTに一致している場合、別のポリシーグループを変更しても結果は変わりません。カスタムルールは通常、上から順に照合されます。広範囲に適用されるDIRECTルールが前にあると、後続のルールより優先されることがあります。使用中の設定が変更したファイルと同じか、サブスクリプション更新でローカルの変更が上書きされていないかも確認しましょう。変更後は新しい接続を作成してください。既存の接続は再照合されない場合があります。

クライアントが備えるオーバーライド、マージ、拡張スクリプト、永続ルール機能を優先して使い、更新のたびに置き換わるリモート設定ファイルを直接編集しないでください。まず各機能でルールが挿入される位置を確認し、特定ドメインのルールを適切な広域ルールより前に配置します。末尾にはフォールバックとしてMATCHを残してください。保存後にサブスクリプションを手動更新し、ルールが残っていることと実際に適用されることを確認します。オーバーライドの構文はクライアントごとに異なるため、移行時はあらためて確認が必要です。ルールプロバイダーはルールセットをまとめる機能であり、設定が保持されるかはクライアントの読み込み方式によります。

まずクライアントでローカルの待ち受けアドレス、ポート、対応プロトコルを確認し、各ツールの説明に従ってプロキシオプションや環境変数を設定します。多くのツールはHTTP_PROXYやHTTPS_PROXYに対応していますが、小文字の変数だけを参照するものや、独自の設定ファイルを使うものもあります。一度設定すればすべてのアプリで有効になるとは限りません。HTTPS_PROXYにはプロキシの接続先を指定します。通常のHTTPプロキシを使う場合、値がhttp://で始まることもあります。設定後は新しいターミナルを開いてテストし、使用後は一時的な環境変数を削除してください。単一の端末内ツールのために、ローカルの待ち受けアドレスを外部公開しないでください。

まず名前解決モードが原因か確認します。ノードとルールは変えず、影響を受けるドメインやアプリで比較テストしてください。実際のIPアドレス、LAN内のデバイス検出、特殊なドメイン解決に依存するアプリでは、コアが対応する形式で必要なドメインをfake-ip-filterに追加します。その後、対象アプリを再起動し、DNSキャッシュを消去してください。除外ドメインを追加しても名前解決の動作が変わるだけで、接続が必ずDIRECTになるわけではありません。通信の振り分けは引き続きルールに従います。すべてのドメインを除外リストに加えないでください。redir-hostへ切り替える必要がある場合は、DNSの上流設定、ルーティング、既存ルールが適用可能かも確認しましょう。

まずプロキシを一時停止して、通常のネットワーク接続を確認します。次にサブスクリプションの状態、システム時刻、ノードが現在も提供対象かを確認してください。その後、別のノードと別のネットワークでそれぞれテストし、特定ノードの障害、ローカルネットワークの制限、設定全体の問題を切り分けます。内蔵テストは指定されたテスト先へ接続します。タイムアウトしても、すべての接続先に到達できないとは限らず、ダウンロード速度を示すものでもありません。ログで、DNS解決、接続確立、TLSハンドシェイクのどこに失敗しているか確認し、連続して一括再試行しないでください。同じノードが異なるネットワークでも失敗し続ける場合は、個人情報を伏せたログをサービス提供元に送ります。

まずコアが起動していることと、ローカルのプロキシポートがシステムに登録されたポートと一致していることを確認します。ブラウザーの拡張機能や個別のプロキシ設定が上書きしていないかも確認してください。他のプロキシツールを終了し、システムプロキシをいったん無効にしてから再度有効にし、新しい接続でテストします。システムの除外リストに対象ドメインが含まれていないかも確認しましょう。システムプロキシを使うのは、通常その設定に従うアプリだけです。クライアントを終了しても接続できない場合は、システムにローカルポートを指すプロキシ設定が残っていないか確認してください。ノードを変えるだけでなく、ローカルの接続口も確認しましょう。ポートの競合やコアの起動失敗があると、すべてのノードで問題が起きることがあります。

AppContainerによるネットワーク分離を使う一部のアプリは、ローカルのプロキシポートへ直接アクセスできません。そのため、ブラウザーでは接続できても特定のアプリだけ失敗することがあります。まず対象アプリがこの種類に該当するか確認し、クライアントにループバックの除外設定がある場合は、ローカルプロキシへのアクセスが必要なアプリだけを許可してください。Windowsの管理ツールに詳しい場合は、CheckNetIsolationで除外設定を確認・管理できます。すべてのアプリを一括で許可しないでください。ループバックの除外設定ではサーバー側やDNSの障害は解決できません。許可後も失敗する場合は、接続履歴を確認しましょう。

ドメインに接続できない場合は、DNS解決の失敗とプロキシ接続の失敗を切り分けます。コアのログで名前解決エラーを確認し、dns-hijack、上流DNS、ルーティングの設定が現在のコアに対応しているか調べてください。Androidでは、プライベートDNSとクライアントのDNS取り込みが競合していないかも確認します。複数の設定を同時に変更しないでください。画面ロック後にだけ切断する場合は、バッテリー最適化、バックグラウンド実行権限、システムのVPN状態を確認し、他のVPNアプリが接続を占有していないかも確認します。設定を一つ変えるごとに再テストし、元の設定も残しておきましょう。バックグラウンド制限をノード障害と誤認しないためです。