Clashのよくある質問

Clashは、プロキシコアとその設定エコシステムを指す一般的な呼び名です。mihomoはClash.Metaから発展したコアで、接続、ルール判定、DNS処理を担います。Clash PlusやClash Verge RevなどのクライアントはGUIを提供し、設定やシステムプロキシ、コアのプロセスを管理します。同じ設定ファイルを使えるかどうかは、クライアントに搭載されているコアとそのバージョンによって異なります。ソフト名にClashが含まれているかだけでは判断できません。

クライアントは設定を実行するソフトであり、インストールしただけでリモートプロキシサービスが使えるようになるわけではありません。サブスクリプションには通常、サーバー情報、プロキシグループ、ルールが含まれます。自分で管理するYAML設定を使う方法もあります。読み込む前に、提供元が信頼できること、サービスが有効であること、形式が対応していることを確認してください。サブスクリプションURLには認証情報が含まれる場合があります。スクリーンショットやログを共有するときはURL全体を隠し、通常のWebアドレスのように公開しないでください。

通常はルールモードを使い、設定内のルールに従って接続先を振り分けます。グローバルモードでは、コアに届いた接続をグローバルプロキシグループに送るため、ルールがアクセスに影響しているかを一時的に調べるのに便利です。DIRECTモードでは、コアに届いた接続をそのまま宛先へ接続します。モードが制御するのはコアに届いた通信だけです。グローバルモードでも端末全体の通信を自動的に取り込むわけではなく、システムプロキシやTUNの代わりにもなりません。

新しく使い始めるなら、まずダウンロードページでClash Plusを確認し、画面の使いやすさに応じてClash Verge Rev、FlClash、Clash Nyanpasuと比較してみましょう。Clash for Windowsは開発終了しています。移行前に設定とカスタムルールをバックアップしてから、新しいクライアントに読み込んでください。以前の画面設定をそのまま引き継げるとは限らないため、混合ポート、サービスモード、TUN、DNSの上書き設定を個別に確認します。システムプロキシを複数のクライアントで同時に制御しないでください。

ノードの速度測定は、通常コアがテスト用アドレスに接続した際の所要時間です。ダウンロード速度や動画の再生速度、ゲームの快適さを示すものではありません。テスト用アドレス、タイムアウト時間、サーバーの負荷、接続先サービスのネットワーク環境によって結果は変わります。ノードを比較するときは、同じテスト用アドレスとネットワークを使い、実際のアプリでも確認してください。ノードがタイムアウトと表示されても、テスト用アドレスに到達できないだけの場合があります。ログを確認し、結果ひとつでノードを削除しないようにしましょう。

サービス提供元のページで、Clashまたはmihomo用と明記されたサブスクリプションURLを選びます。クライアントの設定またはサブスクリプション画面を開き、「URLからインポート」などの項目に貼り付けて保存し、その設定を現在のプロファイルとして選択してください。アカウントのログインページ、注文ページ、QRコード画像のURLは通常サブスクリプションではありません。Base64形式のノード一覧やSIP008データしかない場合は、まずクライアントの対応状況を確認してください。ファイルの拡張子をYAMLに変えるだけでは使えません。

まずクライアントのコアが正常に動作しているか確認し、OSに応じて権限を設定します。Windowsでは、クライアントが提供するサービスモードをインストールして起動するのが一般的です。macOSではヘルパーのインストールと許可が必要な場合があります。Linuxでは、クライアントが対応する権限昇格やサービス設定を確認してください。Androidでは、システムのVPN接続要求を許可します。設定後にTUNを再度有効にしてログを確認してください。サービスのインストール失敗を、毎回の権限昇格でごまかさないようにしましょう。また、別のVPNアプリを同時に有効にしないでください。

いいえ。7890はよく使われる設定値のひとつです。混合ポートでは、同じ待ち受けポートでHTTPとSOCKS5のプロキシ接続を受け付けます。実際のポート番号はクライアントの設定を確認してください。ブラウザー拡張機能や他のアプリにプロキシを手動設定する場合、ホストには通常127.0.0.1を指定し、ポート番号はクライアントと一致させます。ポートが使用中と表示されたら、古いクライアントを終了するか、使用中のプロセスを確認してください。ポートを変更した場合は、手動設定したすべてのアプリも更新します。

システムプロキシはアプリにプロキシ設定を通知する仕組みで、すべてのプログラムに利用を強制するものではありません。まずシステムプロキシに対応したブラウザーで確認し、クライアントの接続一覧にリクエストが表示されるかを見てください。コマンドラインツール、ゲーム、独自のネットワーク処理を使うアプリでは、プロキシの個別設定やプロセス環境変数の設定が必要な場合があります。TUNへの切り替えも選択肢です。接続一覧に表示されているのにDIRECTで接続される場合は、システムプロキシを何度も切り替えるのではなく、適用されたルールを確認してください。

各端末を同じ信頼できるLANに接続し、パソコンのクライアントでLAN接続を許可します。待ち受けアドレスがループバック限定になっていないことも確認してください。端末の手動HTTPプロキシには、パソコンのLAN内IPアドレスと混合ポートを指定します。127.0.0.1やルーターのゲートウェイアドレスを指定しないでください。パソコンのファイアウォールでは、必要なポートをプライベートネットワークに限って許可します。通常のHTTPプロキシだけで端末上のすべてのアプリやUDP通信を制御できるわけではありません。

サブスクリプションの更新ではリモート設定を再取得するため、生成された設定ファイルを直接編集すると変更が上書きされることがあります。個別のルールとリモートのサブスクリプションは分けて管理し、クライアントの上書き、マージ、拡張設定、スクリプト機能を優先して使いましょう。マージの順序はクライアントによって異なります。ルール追加後は最終的に有効な設定を確認し、接続一覧で適用結果を検証してください。クライアントを移行した場合、上書き設定も改めて行う必要があります。サブスクリプションURLと一緒に引き継がれるとは限りません。

ルールモードのまま、カスタムルールに対象サイトのドメインマッチを追加し、先に適用される可能性がある広範囲のルールやMATCHのフォールバックルールより前に配置します。たとえばDOMAIN-SUFFIX,example.com,DIRECTは、そのドメインとサブドメインに一致します。サイトによってはログイン、画像、APIに別ドメインを使う場合があるため、接続ログを確認して必要なルールを追加してください。ひとつのサイトのために、大規模な共有サービスのドメイン全体をDIRECTにしないようにしましょう。

Fake-IPは、まずアプリに対応するIPアドレスを返し、コア側で接続とドメインを関連付ける仕組みです。これにより、ルール判定やその後の名前解決ができます。リモートサーバーの実際のIPアドレスではありません。実際の名前解決結果やLAN内の機器検出、特殊な認証手順に依存するアプリでは、互換性の問題が起きる場合があります。影響を受けるドメインを特定し、使用中のコアが対応するfake-ip-filterの仕様に従って例外を追加してください。設定変更後は該当アプリを再起動し、必要に応じてDNSキャッシュを消去してから、DNSモードの変更が必要か判断します。

まず、どのドメインをどのDNSリゾルバーで処理する想定かを確認します。そのうえでクライアントのDNS設定、TUNによるDNSの取り込み、ブラウザーのセキュアDNSが別経路を使っていないかを調べてください。テストサイトに表示されるリゾルバー名や地域は手がかりのひとつで、それだけで結論は出せません。コアのログ、システムのDNS設定、必要に応じてパケットキャプチャを使い、実際のリクエストを確認します。ルールでDIRECTが許可されている場合、ローカルDNSで名前解決されても設定の想定に反するとは限りません。

まずネットワークの再接続を待ち、新しいリクエストを試してください。ネットワーク切り替え後は、既存のTCP接続、DNSキャッシュ、TUNルートが一時的に無効になることがあります。古い接続を閉じ、速度を再測定し、現在のプロキシ制御方式を有効にし直してから、最後にクライアントを再起動してみましょう。LAN共有を使っている場合は、パソコンのIPアドレスが変わっていないかも確認してください。スリープのたびに問題が再発する場合は、OSのバージョン、コアのログ、復帰時刻を記録すると、ネットワークドライバーの問題かクライアントの復帰処理の問題かを切り分けやすくなります。

まず更新ログのステータスを確認します。401や403は認証、リンクの取り消し、アクセス制限などが原因の可能性があります。404はURLの変更、タイムアウトはネットワークやサブスクリプションのドメインの名前解決に問題がある場合があります。ステータスコードだけでサービスの期限切れと判断せず、提供元のページにログインして確認してください。利用中のノードが使えずサブスクリプションを取得できない場合は、提供元を確認したうえでDIRECTでの更新を試すか、使用可能な設定に切り替えてください。サブスクリプションURL全体を、見知らぬ変換サービスに送信しないでください。

まずクライアントのプロキシ制御を一時的に無効にし、通常のネットワークで本来DIRECT接続できるサイトを開けるか確認します。次にコアの起動状態、サブスクリプションの有効性、システム時刻を確認してください。その後、ノードをひとつだけ選んでテストし、ログを見てDNSの名前解決失敗、接続拒否、ハンドシェイク失敗、テスト用アドレスのタイムアウトを区別します。DNS、ポート、モードを同時に変更せず、一度にひとつだけ変更して再テストしてください。原因が分かるまでは元の設定をバックアップし、再インストールで手がかりを失わないようにしましょう。

AppContainerを使う一部のアプリは、ネットワーク分離の制限によりローカルのループバックプロキシに直接接続できません。まず通常のブラウザーが同じプロキシで正常に動作することを確認し、クライアントにUWPのループバック通信を許可する機能があれば、必要なアプリだけを許可してください。この操作には通常、管理者権限が必要です。アプリを再インストールした後は、設定を確認し直す必要がある場合があります。ストアアプリがすべてUWPとは限りません。TUNを使用している場合は、通信が取り込まれているかも別途確認し、すべての接続失敗をループバックの問題と決めつけないでください。

まずOSのネットワークプロキシ設定で、残っている手動プロキシや自動構成スクリプトを無効にします。以前のローカル待ち受けポートは、クライアントの終了後に応答しなくなっている可能性があります。TUNを有効にしていた場合は、クライアントを起動し、正しい手順でTUNを無効にしてルートが復旧するまで待ってください。その後、ネットワークアダプターのDNSが手動指定のままになっていないか確認します。組織管理の端末では、管理設定を勝手に削除しないでください。復旧後にDIRECT接続を再テストし、必要ならネットワークに再接続します。他のソフトにも影響するネットワーク全体のリセットを、最初から実行するのは避けましょう。

まず現在の設定をバックアップし、起動ログを確認してください。設定の解析に失敗する場合は、YAMLのインデント、キーの重複、プロキシグループの参照、コアが対応していない項目を確認します。起動直後に終了する場合は、ポートの競合、コアファイルの破損、OSの権限、ランタイムライブラリも確認してください。以前正常に使えていた設定で切り分ける方法もありますが、データフォルダー全体をすぐに削除しないでください。問い合わせる際は、クライアント名、システムのアーキテクチャ、個人情報を伏せたエラー部分を共有し、ノードのパスワードやサブスクリプションの認証情報は添付しないでください。