1. Clash、Mihomo、Clash Verge Revの違いは？

Clashはこの種のプロキシツールや設定エコシステムで広く使われる名称、Mihomoはプロキシコア、Clash Verge RevはMihomoを利用するデスクトップクライアントです。クライアントはサブスクリプション管理、プロキシ選択、システムプロキシの切り替え、ログ表示などを担い、コアは実際の接続、DNS処理、ルール判定を行います。クライアントをインストールしただけでは、利用可能なノードは手に入りません。

Mihomoは以前、Clash.Metaという名称で知られていました。古いガイドを調べるとClash MetaやMetaコアといった呼び方が見つかることがありますが、コアやバージョンによって対応する設定項目は異なります。設定エラーが出た場合は、まずクライアントとコアのバージョン、エラー全文を記録し、互換性の問題かどうかを確認してください。

  • クライアント：Clash Verge Revのように、設定や操作を画面上で扱えるようにするソフトウェアです。
  • コア：実行時の設定を読み込み、プロキシ接続を確立して通信ルールを適用します。
  • サブスクリプション：サービス提供元から取得する設定やノードの配信元です。クライアントが自動生成するものではありません。

この記事では、Clash Verge Revのデスクトップ版の操作を中心に説明します。AndroidのVPN許可とデスクトップのシステムプロキシは仕組みが異なるため、両方の設定をそのまま対応づけることはできません。クライアント選びはクライアント比較をご覧ください。

2. サブスクリプションURLとは？どこで取得する？

サブスクリプションURLは設定を取得するためのアドレスで、通常はアカウント用のトークンが含まれています。サービス提供元によっては、アカウント管理ページ、汎用ノードURL、Clash用設定URLなど複数のリンクが用意されています。Clash Verge Revに追加する際は、ClashまたはMihomoの設定に対応したリンクを選び、ブラウザーのアドレスバーに表示されているアカウントページのURLをコピーしないでください。

追加前に確認する3項目

  1. 自分のサービスアカウントから取得したリンクで、契約や利用権限が有効であることを確認します。
  2. 返される内容が対応している設定データであり、ログイン画面、支払い案内、Webエラーページではないことを確認します。
  3. URLが完全な状態であることを確認します。チャットでの改行、コピー時に混入した空白、クエリパラメーターの欠落などでリクエストが失敗する場合があります。

設定全体にはproxies、proxy-groups、rulesなどの項目が含まれることがあります。また、proxy-providersでノードを読み込む構成もあるため、proxiesがないだけで無効とは判断できません。ノード一覧だけのサブスクリプションは、既存の設定と組み合わせて使う場合があります。

3. Clash Verge Revにサブスクリプションを追加する方法

まず追加し、次に設定を有効化して、最後にノードを選びます。この3つの操作はそれぞれ、設定の取得、コアへの設定読み込み、プロキシの出口選択にあたります。追加に成功しただけでは、最初の手順が完了した段階です。

  1. 左側の「サブスクリプション」画面を開き、URL入力欄にリンクを貼り付けて「追加」を実行します。バージョンによっては「新規サブスクリプション」メニュー内に項目があるため、実際の画面に合わせて操作してください。
  2. サブスクリプションのカードが表示されるまで待ちます。更新結果、ノード数、通信量などを確認します。これらが表示されるかどうかは、サービス側が該当データを提供しているかによります。
  3. 追加したサブスクリプションを選択し、現在使用する設定として有効にします。YAMLの解析エラーや項目エラーが表示された場合は、エラーを解消してから操作してください。ネットワークを全面的に取り込む設定をすぐに有効にするのは避けましょう。
  4. 「プロキシ」画面を開き、ルールから実際に参照されているポリシーグループを見つけて、利用可能なノードを選択します。
  5. 初回の動作確認では「ルール」モードと「システムプロキシ」を使い、ブラウザーでテストしてから「接続」画面でリクエストを確認してください。

手動更新に失敗しても古い設定が使える場合は、まずサブスクリプションURLと更新リクエストの経路を確認します。唯一使える設定を先に削除しないでください。サーバーから401または403が返る場合は、利用権限、トークン、サーバー側のアクセス制限を確認します。200が返っても内容が正しいとは限らないため、HTMLページが誤って返されていないかも確認してください。

初回インストールからサブスクリプション追加までの手順はクイックスタートをご覧ください。クライアントを乗り換える場合は、まず元のサブスクリプションを再追加し、その後にローカル設定を個別に移行するのがおすすめです。

4. ルール・グローバル・ダイレクト、どのモードを選ぶ？

普段使いには、まずルールモードを選びましょう。モードはコアが通信の出口を選ぶ方法を決めますが、すべてのアプリの通信が自動的にコアへ入るわけではありません。通信を取り込む経路は、システムプロキシ、TUN、アプリ独自のプロキシ設定によって決まります。

モード動作用途
ルール（Rule）設定内のルールを上から順に照合し、該当するポリシーまたはポリシーグループに振り分ける日常的な振り分け。直接接続とプロキシ接続を使い分ける
グローバル（Global）コアに入ったリクエストを、グローバルポリシーで選択した出口に送る短時間の比較テストや、ルールによる経路選択の確認
ダイレクト（Direct）コアに入ったリクエストをプロキシノード経由ではなく、宛先へ直接接続するローカルネットワークの確認や、プロキシ経由の接続を一時的に無効化する

グローバルモードは「すべての端末の通信を取り込む」ことを意味せず、すべてのWebサイトが速くなるわけでもありません。アプリがシステムプロキシを使わず、TUNにも取り込まれていない場合、グローバルモードに切り替えても通信がクライアントを通らないことがあります。グローバルポリシーにDIRECTを選んだ場合も、リモートのプロキシノードは経由しません。

ルールモードでは通常、ルールを上から順に照合し、最初に一致したルールのポリシーが適用されます。宛先が先行するダイレクトルールに一致している場合、リスト末尾のフォールバックルールを変更しても、そのリクエストには影響しません。接続ログで適用されたルールを確認し、Webサイトの所在地域だけで判断しないでください。

5. システムプロキシとTUNモードの違いは？

ブラウザーの動作確認にはシステムプロキシ、より多くの通信を取り込むにはTUNが適しています。システムプロキシはOSにローカルプロキシの接続先を登録しますが、アプリによっては設定に従わないことがあります。TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込み、明示的なプロキシに対応していないアプリにも利用できますが、サービス権限が必要で、既存のネットワーク環境に影響する場合があります。

必要に応じて段階的に有効化

  • ブラウザーだけで使う：まずシステムプロキシを有効にし、設定の競合を避けるため、ブラウザー独自のプロキシ拡張機能は一時的に無効にします。
  • ターミナルツール：ツールがシステム設定を参照するか確認するか、HTTP・SOCKSプロキシを個別に設定します。
  • ゲームや一部のデスクトップアプリ：プロトコルとノードの対応状況を確認してからTUNを検討します。システムプロキシだけでは、すべてのUDP通信に対応できないことがあります。

Clash Verge Revでは「設定」から「システムプロキシ」や「TUNモード」の項目を確認できます。TUNが使えない場合は、そのバージョンのサービスモードがインストールされ、実行中かを確認してください。OSによって権限の手順は異なります。常に管理者権限で起動する方法だけに頼るのはおすすめしません。

会社のVPN、別のプロキシソフト、仮想ネットワークアダプターを同時に使っている場合は、現在の状態を記録したうえで、通信を取り込む方式を1つだけ残してテストしてください。TUNの問題はルーティング、DNS、サブネットの競合が原因となることがあり、ノードを何度も切り替えても解決しない場合があります。

6. ノードに遅延時間が表示されるのに、Webサイトが開かないのはなぜ？

遅延テストで確認できるのは、特定のテストリクエストがその時点で応答を受け取ったことだけです。ダウンロード速度やWebサイトへのアクセス可否、すべてのポリシーグループがそのノードを選んでいることを示すものではありません。たとえばノードに80msと表示されていても、別のWebサイトに接続できないことがあります。この数値は説明用の例で、実測値ではありません。

  1. 対象のリクエストがどのポリシーグループを使っているか確認します。サブスクリプションの更新後は、グループ名やノードの選択肢が変わることがあります。
  2. そのグループが最終的にどの出口を使うか確認します。グループ名を選択した先で、さらに別のポリシーグループを参照する場合があります。
  3. 利用できることが分かっている別のHTTPSサイトでテストし、特定サイトだけの問題か、全般的な問題かを切り分けます。
  4. 「接続」と「ログ」画面でリクエストの結果を確認してください。「プロキシ」画面の遅延表示の色だけで判断しないようにしましょう。

遅延テストがタイムアウトしても、ノードが必ず使えないとは限りません。テスト先に到達できない、サーバーがその宛先を制限している、タイムアウト設定が短すぎるといった可能性があります。実際のWebリクエストや接続エラー、同じネットワークでの他のノードの状態も合わせて判断してください。

通常のWebページは開けても、大容量ファイルや動画の再生が繰り返し失敗する場合は、ノードの品質、接続先サービスの制限、プロトコルの互換性を確認してください。遅延が最も小さいことだけを基準にノードを選ばないようにしましょう。

7. 「接続済みなのにWebサイトが開かない」場合の確認手順

まずリクエストがクライアントに届いているかを確認し、次にルール、ノード、DNSを調べます。画面上で実行中と表示されていても、通常はコアや通信取り込み機能が起動したことを示すだけで、Webサイトへの接続が完了したとは限りません。

1つのリクエストを決めて、6か所を確認

  1. ローカルネットワーク：システムプロキシとTUNを一時的に無効にし、通常は直接接続できるサイトが開くか確認します。基本的なインターネット接続に問題がある場合は、Wi-Fi、ゲートウェイ、ネットワークのログイン画面を先に確認してください。
  2. 現在の設定：サブスクリプションが有効になっているか、コアで設定読み込みエラーが発生していないか確認します。
  3. 通信の入口：対象のWebページを再読み込みし、「接続」に該当するドメイン名または宛先IPが表示されるか確認します。記録がない場合は、ブラウザー独自のプロキシ、システムプロキシのポート、TUNのルート、除外リストを確認してください。
  4. ルールの結果：新しい接続に適用されたルールとポリシーの経路を確認し、誤ってDIRECTが選ばれていないか、REJECTに一致していないか確認します。
  5. プロキシの出口：同じポリシーグループ内でノードを切り替えてから、新しいリクエストを送信します。既存の長時間接続は、ノードを選び直してもすぐに移行しない場合があります。
  6. エラーの種類：ログを確認し、ドメイン名の解決失敗、接続拒否、接続タイムアウト、TLSエラーを区別して対処します。

確認が終わったらルールモードに戻します。システムファイアウォールを長時間無効にしたり、TLSエラーを隠すために証明書検証をスキップしたりしないでください。後者の場合は、システム時刻、証明書チェーン、接続先サービス、HTTPS検査ソフトの有無を確認します。

8. DNSの問題とプロキシポートの誤りを見分ける方法

DNSはドメイン名をIPアドレスに変換し、プロキシポートはアプリからのリクエストを受け付けます。両者は異なる段階で動作します。ログにlookupやno such hostなどが表示された場合は、まず名前解決を確認します。ローカルのプロキシアドレスへの接続が拒否される場合は、ポートとコアの待ち受け状態を確認してください。

以下はHTTPプロキシの入口を明示してテストする例です。7897はサンプルのポート番号なので、クライアントの実行時設定にあるHTTPポートまたは混合ポートに置き換えてください。古いガイドにある7890を固定の既定値として使わないでください。

curl --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 --head https://example.com/

Windows PowerShellではcurl.exeを使用すると、一部の環境でcurlが別のコマンドに割り当てられる問題を避けられます。この例では接続タイムアウトを10秒、全体のタイムアウトを20秒に設定しています。接続先はテスト方法を示すためのもので、実際の調査では問題が発生しているURLに置き換えてください。HTTPレスポンスを受信できたことは、リクエストがアプリケーション層まで進んだことを示しますが、そのサイトのすべての機能が使えるとは限りません。

  • ローカル接続が拒否される：ポート、待ち受けアドレス、コアの実行状態、ポートを使用している他のプロセスを確認します。
  • リクエストがクライアントに届いた後、名前解決に失敗する：実行時のDNS設定と、上流のDNSサーバーに接続できるかを確認します。
  • ブラウザーだけで問題が起きる：ブラウザーのプロキシ拡張機能、セキュアDNS、キャッシュ、アプリ独自の設定を確認します。

Fake-IPはドメイン名を対応づける仕組みであり、実際のリモートサーバーのアドレスではありません。有効にした状態で合成アドレスが返っても、必ずしも問題ではありません。DNSを変更する前に、実際に適用されている設定を確認してください。システムコマンドのnslookupの結果が、コアと同じ名前解決経路を示すとは限りません。

9. サブスクリプションを更新するとノード選択やローカルルールは上書きされる？

リモートのサブスクリプション内容は更新のたびに変わるため、ローカルのカスタマイズはオーバーライドに保存します。ダウンロードしたリモートYAMLを直接編集すると、次回の更新で変更が置き換えられることがあります。ノード選択が保持されるかどうかは、クライアントの保存方式に加え、更新後もポリシーグループ名とノード名が同じかどうかによります。

3種類の設定を区別する

  • リモート設定：サービス提供元から配信されるノード、ポリシーグループ、ルールなどの設定です。
  • ローカルオーバーライド：サブスクリプションの項目を統合・調整し、自分用の振り分けやパラメーターを保存します。
  • 実行時設定：クライアントが処理した後、最終的にMihomoへ読み込まれる設定です。

Mergeオーバーライドでは、すべてのリストが自動的に追加されるとは限りません。ルールリストの統合方法、スクリプトの実行順序、クライアント独自の拡張設定が最終結果に影響する場合があります。保存後は実行時設定を確認し、実際のリクエストでルールが適用されるかテストしてください。

たとえば特定のドメインを直接接続したい場合、DOMAIN,example.com,DIRECTを記述するだけでは不十分です。有効なルール内での順序や、先行するルールに一致しないかも確認してください。初めて設定する場合はサブスクリプションの既存ルールを残し、安定してから応用的な使い方を参考に、ローカルオーバーライドを1項目ずつ追加しましょう。

10. クライアント終了後にネットに繋がらない場合の復旧方法と、問い合わせに必要な情報

まず、ローカルホストを指すプロキシ設定が残っていないか確認します。システムプロキシが127.0.0.1のプロキシポートを参照したままコアが停止していると、その設定に従うアプリは接続できません。

  1. クライアントを再度開き、「システムプロキシ」と「TUNモード」を無効にしてから、通常の手順で終了し、ネットワークが復旧するか確認します。
  2. Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシセットアップ」を確認します。自分で設定したローカルプロキシだけを解除し、組織によって管理されている設定はむやみに削除しないでください。
  3. macOSでは「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」を開き、HTTP、HTTPS、SOCKSの項目を確認します。
  4. まだ問題が続く場合は、他のVPN、ブラウザー独自のプロキシ、ターミナルのHTTP_PROXY、HTTPS_PROXY、ALL_PROXY環境変数を確認します。

TUNの異常終了は、システムプロキシの設定が残るケースとは異なり、仮想ネットワークアダプター、ルーティング、DNSの状態が関係する場合があります。まずクライアントから通信の取り込みとサービスを正常に停止し、必要であればネットワークに再接続してください。用途が分からないままルートや仮想ネットワークアダプターをまとめて削除するのは避けましょう。

問い合わせ時に添える最低限の診断情報

  • OSのバージョン、クライアントのバージョン、Mihomoコアのバージョン。
  • 現在のモード、システムプロキシとTUNの有効・無効、使用中のローカルポート。
  • 問題が発生した時刻、対象のドメイン名、「接続」画面に表示されたルールとポリシーの経路。
  • 発生時刻前後のエラーログ、試した手順、その手順ごとの結果。

共有する前にサブスクリプショントークンなどの認証情報を削除してください。ノード一覧のスクリーンショットを画面いっぱいに貼るより、問題を再現する手順を明確にするほうが原因を特定しやすくなります。初心者向けの基本的な確認順序は、サブスクリプションが有効か、設定が反映されているか、リクエストが届いているか、ルールが正しいか、出口が使えるか、最後にDNSや高度な通信取り込み設定を確認する、です。