Clashのよくある質問

Clashは一般に、プロキシコアとその設定エコシステムを指します。Mihomoはそのエコシステムで開発が続くコアで、初期にはClash Metaの名称で知られていました。Clash Verge RevやClash Meta for AndroidなどのGUIクライアントは、サブスクリプション管理、ポリシー選択、システムとの連携を担います。実際に対応するプロトコルや設定項目は、使用するコアによって異なります。チュートリアルを探す際は、まずクライアントの「バージョン情報」やコア設定で名称を確認し、該当するドキュメントを参照してください。画面にClashと表示されているだけで、異なるクライアント間の設定が完全に共通だとは限りません。

クライアントは主に設定を読み込み、通信を転送する役割を担います。インストールしただけでは、利用可能なプロキシの出口が用意されるわけではありません。サブスクリプションは通常、利用するサービスの提供元から取得します。ノード、プロキシグループ、ルール、DNS設定などが含まれる場合があります。一方、単一のノードリンクは、多くの場合ひとつの接続先だけを示します。まず、現在のコアに対応した設定サブスクリプションを入手していることを確認し、読み込んで現在の設定として選択してください。サブスクリプションURLにはアカウント情報が含まれる場合があります。公開フォーラムやスクリーンショット、見知らぬオンライン変換サイトに掲載しないでください。問題を報告する際は、機密情報を伏せたエラーメッセージだけを共有してください。

ルールモードでは、設定内のルールに従って通信の経路を決めます。ドメイン、IPアドレス、アプリごとに日常的な通信を振り分ける場合に適しています。グローバルモードでは、コアに入った通信をグローバルポリシーに渡しますが、利用可能な出口の選択は必要です。クライアントを経由していないアプリの通信まで自動で取り込むわけではありません。DIRECTモードでは通常、コアに入った通信を直接接続します。特定のサイトの問題を調べる場合は、一時的にグローバルモードへ切り替え、利用可能と分かっているノードを選んでルールモードと比較できます。確認後は元のモードに戻し、一時的なテスト設定を残さないようにしてください。

必ずしも必要ではありません。システムプロキシはOSの設定にローカルプロキシのアドレスを書き込み、その設定に従うアプリで利用されます。TUNは仮想ネットワークインターフェースとルーティングを通じて通信を取り込みますが、対象範囲はプラットフォーム、権限、ルーティング設定によって異なります。ブラウザーが正常に使えるなら、システムプロキシだけで問題ありません。設定項目を増やすためだけにTUNを追加する必要はありません。システムプロキシに従わないアプリを使う場合は、クライアントのドキュメントに沿ってTUNを有効にし、DNSも確認してください。一部のクライアントでは両方を併用できますが、すべての通信が取り込まれるとは限りません。また、別のVPNのルートと競合しないようにしてください。

クライアントで「設定」「サブスクリプション」「Profiles」などの画面を開き、URLから読み込む項目を選択します。URLを最後まで貼り付けて保存してください。ダウンロード後は、その設定を現在使用する項目に指定し、プロキシまたはプロキシグループの画面で出口を選びます。YAMLの解析エラーが出る場合は、URLの応答がClash互換の設定ファイルであることを確認してください。ログイン画面、通常のWebページ、別形式のサブスクリプションでは読み込めません。最後に必要なシステムプロキシまたはTUNを有効にし、ブラウザーで対象サイトにアクセスして接続ログを確認します。設定名が一覧に表示されるだけでは、有効化されたことや通信がコアに入ったことの証明にはなりません。

Windowsでは「設定」のシステム情報からシステムの種類を確認し、x64とARMのどちらかを判別します。macOSでは「このMacについて」でAppleシリコンかIntelプロセッサかを確認してください。Androidは端末のプロセッサアーキテクチャとクライアントの配布情報を基準に選びます。比較的新しい端末ではARM64が一般的ですが、OSのバージョンだけでは判断できません。ユニバーサル版は、クライアントが実際に提供している場合に選んでください。Linuxはプロセッサアーキテクチャに加え、ディストリビューションに合ったdeb、rpmなどのパッケージ形式も確認が必要です。インストールに失敗したら、まずこれらの条件を確認し、その後にOSのバージョン要件を調べてください。出所不明のインストーラーを次々に試すのは避けましょう。

まず現在使える設定を保存し、クライアントのログで、権限の要求、仮想インターフェースの作成、ルートの書き込みのどこで失敗しているか確認します。Windowsではサービスモードのインストールや、ドキュメントに記載された管理者権限が必要な場合があります。macOSでは特権ヘルパーやネットワーク関連コンポーネントの許可を求められることがあります。AndroidではシステムのVPN接続要求を承認し、別のVPNが使用中でないか確認してください。Linuxで必要な権限や実行方法は環境によって異なるため、クライアントの説明に従います。TUNの表示だけを理由にシステムのセキュリティ設定を変更しないでください。必要な権限を付与しても解決しない場合は、他のVPN、仮想NIC、ルーティングとの競合を調べます。

まず通常のブラウザーで同じプロキシを使ってアクセスできることを確認し、問題がアプリコンテナーの制限を受けるUWPアプリだけで起きるかを調べます。こうしたアプリからローカルプロキシへ接続する際、ループバック制限が影響する場合があります。クライアント付属のループバック解除ツールを使うか、Windowsのドキュメントに従い、CheckNetIsolationで対象アプリのパッケージに解除設定を行ってください。通常は管理者権限が必要です。必要なアプリだけを対象にし、元に戻せるよう変更内容を記録してください。ストアアプリがすべてUWPとは限らず、接続エラーの原因が常にループバック制限とも限りません。解除しても解決しない場合は、アプリがシステムプロキシを使うか、アプリ自身のネットワーク設定も確認してください。

まずクライアントのコアが実行中か、システムプロキシのアドレスとポートが現在の設定の待ち受けポートと一致しているかを確認します。次に、ブラウザーのプロキシ拡張機能、企業ポリシー、独自のプロキシ設定がシステム設定を上書きしていないか、対象アドレスがシステムの除外リストに含まれていないかを調べてください。対象サイトへのアクセス時にクライアントの接続ログを確認します。ログがまったくなければ、まず通信の入口を調べます。ログがあり、DIRECTで接続されている場合は、ルールとプロキシグループの選択を確認してください。設定のポートを変更した後は、システムプロキシの設定も再適用します。複数のプロキシクライアントを同時に使っている場合は、ほかのクライアントを終了し、同じシステム設定が繰り返し書き換えられないようにしてください。

いいえ。クライアントの遅延テストは通常、ノード経由で指定されたテスト先にリクエストを送り、その時点での接続状況と応答時間を測定します。継続的な通信速度を示すものではなく、対象サイトにアクセスできることも保証しません。テスト先に接続できない場合、ノード自体は使えても速度テストがタイムアウトすることがあります。ノードを選ぶ際は実際のアクセス結果、接続ログ、サービス提供元の稼働状況をあわせて確認し、短時間に大量のテストを繰り返さないでください。ダウンロード体感を比較するなら、同じ対象、近い時間帯、同じネットワーク条件で測定します。テストでサブスクリプションの通信量を消費する可能性にも注意してください。1回の遅延が最短のノードが、あらゆる用途で最適とは限りません。

Fake-IPは、一部のコアが対応するDNSの拡張方式です。ドメイン名に対応するマッピングアドレスを返し、コアが元のドメイン名と関連付けて接続を処理します。プロキシの出口に実際に割り当てられたアドレスではありません。LAN内のデバイス、実際の名前解決結果に依存するアプリ、特定のデバイス検出プロトコルでは追加の設定が必要な場合があります。まず、このモードを有効にした後だけ問題が発生するか確認し、ローカルの名前解決、DNSの制御、LANのルーティングを調べます。必要に応じてコアのドキュメントを参照し、対象ドメインをfake-ip-filterに設定するか、該当するDNSポリシーを調整してください。範囲の広い除外ルールを安易に追加しないでください。変更後はアプリやシステムに残った古いDNSキャッシュを消去して再テストします。

リモートサブスクリプションの更新で設定全体が置き換わり、サブスクリプションファイルを直接編集した内容が上書きされることがあります。ノード名やプロキシグループ名の変更によって、以前の選択が一致しなくなる場合もあります。まず、編集中のものがリモート設定のキャッシュ、独立したローカル設定、クライアントのオーバーライド機能のどれかを確認してください。ルールを長期間維持するには、そのクライアントが対応するオーバーライド、マージ、スクリプト機能を使い、最終的に生成される設定のルール順も確認します。自動更新とプロキシ選択の記憶は別の機能です。更新を有効にするだけで、すべての選択が維持されるわけではありません。変更前に、元に戻せるコピーを保存してください。

まず更新時のHTTPステータスやログのエラーを記録します。401や403は認証、アクセス制限、資格情報に関係する場合があり、404はURLが無効になっている可能性があります。タイムアウトや名前解決の失敗では、まずネットワークとDNSを確認してください。ステータスコードだけで原因を断定せず、サービス提供元にも確認しましょう。提供元のアカウントページで有効期限、通信量、サブスクリプションURLの変更有無を確認し、完全なURLをコピーし直します。ログイン画面や認証画面が返される場合は、クライアントに対応したURLを提供元に問い合わせてください。ブラウザーでURLを開けても、クライアントが同じネットワーク経路を使うとは限りません。必要に応じてクライアントの設定で、直接接続とプロキシ経由の更新をそれぞれ確認し、短時間に再試行を繰り返して制限されないようにしてください。

再インストールより先に、共通する条件を確認するほうが効果的です。端末から直接インターネットに接続できること、サブスクリプションの有効期限内で通信量も残っていることを確認し、システムの日付、時刻、タイムゾーンが正しいか調べます。次に、現在のコアがサブスクリプション内のプロトコルやパラメーターに対応しているか確認し、ログにハンドシェイク、証明書、名前解決のエラーがないか確認してください。すべてのノードが同時にタイムアウトする場合、テスト先に到達できない可能性もあります。アプリからの実際のアクセスは別途確認しましょう。現在のネットワークだけで失敗する場合は、利用条件に合う別のネットワークでも試し、端末側の問題かネットワーク経路の問題かを切り分けます。証明書エラーを回避するために、証明書検証を安易に無効にしないでください。

通信の入口、DNS、ルール、出口の順に確認します。まず接続ログにブラウザーのリクエストが表示されるか見てください。ログがなければシステムプロキシやTUNが実際に有効か確認します。リクエストはあるのに名前解決に失敗する場合は、DNS設定と現在のネットワークからDNSへ到達できるかを調べます。次に、その接続に適用されたルールとプロキシグループを確認し、利用できない出口や意図しないDIRECTが選ばれていないかチェックします。最後に、利用可能と分かっている別のノードで比較し、対象サイト自体に障害がないかも確認してください。画面の「接続済み」は、コアや仮想インターフェースが起動したことを示すだけの場合があり、Webサイトへのアクセス成功を意味しません。一度に変更するのは1項目にし、変更前後の結果を記録してください。

まず、エラーの対象がmixed-portなどのプロキシ待ち受けポートなのか、外部コントロールポートなのか確認します。両者を混同しないでください。Windowsではnetstat -anoで待ち受け状態とPIDを確認し、タスクマネージャーでプロセスを特定します。macOSやLinuxではlsof -i :7890で使用状況を調べます。環境によっては適切な権限が必要です。古いクライアントが原因と確認できたら、通常の手順で終了してください。正体の分からないシステムプロセスを強制終了しないでください。複数のクライアントを併用する場合は、新しいクライアントに空きポートを割り当て、実際に適用されている設定またはクライアントのポート設定を変更します。システムプロキシやアプリ独自のプロキシのポートも更新し、再起動して確認してください。