Clash Vergeの使い方 FAQ 10選｜サブスクリプションの追加・プロキシモード・接続できないときの対処法

初めて設定するときは、問題を3段階に分けて考えましょう。サブスクリプションが正常に読み込まれているか、コアがノード経由で接続できるか、アプリの通信がコアに届いているかを確認します。サブスクリプションを追加できても、システムプロキシが有効とは限りません。ノードの遅延に数値が表示されても、すべてのサイトにアクセスできるわけではありません。以下では実際の設定順に、よくある10の質問に回答します。切り分けでは一度に変更する設定を1つにし、変更前後のログを残してください。

1. Clash Vergeをインストールしたのに、なぜサブスクリプションが必要？

クライアントは設定管理やシステムプロキシの制御、コアの起動を担います。サブスクリプションには通常、ノード、プロキシグループ、振り分けルールが含まれます。クライアントをインストールしただけでは、接続先となるリモートプロキシサーバーは自動で用意されません。サブスクリプションURLは利用権限のあるサービスから入手してください。クライアントはサービスアカウントの代わりにはならず、プランの通信量や有効期限も管理しません。

Clash Verge Rev：サブスクリプションを管理し、コアを操作するデスクトップ向けGUIクライアントです。
mihomo：プロトコル接続、DNS処理、ルール判定を実行するコアです。Clash Meta と呼ばれることもあります。
サブスクリプション設定：ノードやルーティング動作を記述したデータです。インストーラーやWebログイン用のURLではありません。

事前にサブスクリプションURLを用意し、サービスの有効期限が切れていないことを確認してください。手元にあるのが単体の ss:// または vmess:// ノードURLだけの場合、それを完全な Clash 設定として読み込めるとは限りません。サービス提供元に Clash または mihomo 専用のサブスクリプションがあるか確認しましょう。

2. サブスクリプションURLの追加方法と、反映の確認方法は？

左側の「サブスクリプション」ページを開き、URL入力欄にアドレスを貼り付けて「追加」をクリックします。設定カードが表示されたら、その設定を現在の設定として選択してください。バージョンによっては「新規作成」から追加します。その場合はリモートサブスクリプションを選び、URLを入力します。追加後は「プロキシ」ページにプロキシグループとノードが表示されていることを確認してください。サブスクリプションカードだけが表示されていても、設定が反映されたとは限りません。

元のURLをコピーし、先頭や末尾の空白、チャットアプリが付けた句読点を取り除きます。
追加して設定を選択したら、解析エラーやコアの再読み込み失敗がないか確認します。
「プロキシ」を開き、外部向け通信を担当するプロキシグループを展開して、利用可能なノードを選びます。
まず「ルール」モードを使い、次に「システムプロキシ」を有効にしてから、Webページを開いて確認します。

サブスクリプションURLのトークンからアカウント設定を読み取れることが多いため、パスワードと同様に扱ってください。スクリーンショットではURL全体を隠し、ログを共有する前にもリクエストURLを確認しましょう。設定について相談する場合は、サーバーの認証情報とサブスクリプショントークンを削除した部分だけを共有してください。

3. サブスクリプションの追加でYAMLエラー、403、タイムアウトが出たら？

まず「ダウンロードに失敗した」のか、「内容を解析できない」のかを切り分けます。403 はアクセス拒否、トークンの失効、サーバー側の制限などが原因として考えられます。404 は通常、指定したパスが存在しないことを示します。タイムアウトの場合は、現在のネットワークからサブスクリプションサーバーに接続できるか確認してください。いずれもYAMLのインデントエラーとは別の問題です。

表示された症状	まず確認すること	対処方法
HTMLまたはログインページが返される	管理画面のURLをコピーしていないか	サービスのページに戻り、Clash専用のサブスクリプションを取得する
YAMLの解析に失敗する	エラーページが返されていないか、インデントが崩れていないか	エラー行を確認し、元の設定を取得し直す
unsupported proxy type	ノードのプロトコルとコアの対応状況	mihomo の対応プロトコルとコアのバージョンを確認する
リクエストがタイムアウトする	サブスクリプションのドメイン解決とネットワーク接続	別のネットワークでも試し、サブスクリプション更新時のプロキシ設定を確認する

サブスクリプションサーバーへの接続にプロキシが必要なのに、利用可能な設定がまだない場合、初回追加時に行き詰まることがあります。利用許可のある別のネットワークから設定を取得するか、サービス提供元にアクセス可能なURLを問い合わせてください。トークンを含むURLを、運営元の分からないオンライン変換サイトに送信しないでください。

4. ルール・グローバル・ダイレクトはどう使い分ける？

普段は「ルール」モードを選びます。コアは設定内のルールを上から順に照合し、一致したルールに応じたポリシーへ接続を振り分けます。ポリシーにはノードグループ、DIRECT、REJECT などがあります。ルールモードは「海外の通信はすべてプロキシ、中国国内の通信はすべて直接接続」という固定の仕組みではありません。実際の動作は現在の設定によって異なります。

ルール：ドメイン、宛先IP、プロセスなどのルールに従って通信を振り分けます。振り分け設定がある場合の普段使いに適しています。
グローバル：コアに入った通信をすべてグローバルポリシーに渡します。実際の接続先はグローバルグループで選ぶ必要があります。
ダイレクト：コアに入った通信をリモートノードを経由させず、宛先に直接接続します。

「グローバル」は、PC上のすべてのアプリを強制的にプロキシ経由にするという意味ではありません。コアに入った通信のルーティング方法を変えるだけです。システムプロキシに従わないアプリの場合、グローバルモードに切り替えても通信を取り込めないことがあります。一時的にグローバルモードでルールモードとの違いを確認し、原因が分かったらルールモードに戻してください。

5. システムプロキシを有効にしても、アプリによって直接接続されるのはなぜ？

システムプロキシは、アプリが参照するプロキシ設定であり、ネットワーク層で通信を強制転送する機能ではありません。一般的なブラウザーはシステム設定に従いますが、一部のダウンロードツール、ターミナルのアプリ、ゲーム、独自のネットワークスタックを持つアプリは、個別の設定を使うことがあります。まずクライアントの「接続」ページを開き、新しいリクエストを発生させたときに、対象のドメインやプロセスが記録されるか確認してください。

明示的なプロキシ接続で問題の場所を切り分ける

実際の混合ポートが 7897 の場合、Windowsではターミナルで次のリクエストを実行できます。プロキシを明示的に指定することで、アプリがシステムプロキシを参照しているかどうかに左右されずに確認できます。macOSまたはLinuxでは、curl.exe を curl に置き換えてください。

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

HTTPレスポンスが返れば、そのリクエストの接続処理は完了しています。ただし、どのポリシーが適用されたかを接続記録で確認してください。接続拒否エラーが出る場合は、まずローカルの待ち受けポートを確認します。明示的なプロキシ接続は成功するのに特定のアプリだけ失敗する場合は、そのアプリのプロキシ設定を確認し、必要ならTUNを検討してください。TUNを有効にする前に、明示的なプロキシ接続のテストが成功することを確認し、ノードの問題と通信の取り込みの問題を混同しないようにしましょう。

6. ノードがタイムアウトする、または遅延は正常なのにWebページが開かない場合は？

ノードの遅延テストでは通常、コアがノード経由で指定のテストURLにリクエストを送信します。結果が示すのは、そのリクエストの状態だけです。テスト先に接続できても、目的のWebサイト、UDP通信、すべてのDNS問い合わせが正常とは限りません。反対に、テスト先に接続できなくても、ノードが完全に使えないとは限りません。

「プロキシ」を開き、実際にルールから参照されているグループでノードが選択されているか確認します。関係のない別のグループで切り替えただけでは解決しません。
「接続」を開き、失敗したリクエストを見つけて、適用されたルール、ポリシーチェーン、宛先を確認します。
ほかの設定は変えずに別のノードへ切り替え、同じURLで再テストします。
「ログ」を開き、同じ時刻のエラーを確認して、認証失敗、DNSエラー、接続タイムアウトを切り分けます。

すべてのノードで同時に失敗する場合は、アカウントの有効期限、通信量の上限、ローカルネットワーク、システム時刻を優先して確認してください。特定のサイトだけ失敗する場合は、そのサイトに適用されるルールと名前解決の結果を確認します。遅延が80ミリ秒から120ミリ秒に変わっただけで、設定が壊れたと判断する必要はありません。接続確立、スループット、単発の遅延はそれぞれ異なる指標です。

7. ポートが使用中と表示されたとき、競合するプログラムを調べるには？

ログに address already in use と表示される場合、通常は待ち受けアドレスとポートがすでに使用されています。バックグラウンドで古いプロキシクライアントが動作している、または別のインスタンスが同じポートを使っていることが主な原因です。まず重複しているクライアントを終了してください。それでも競合する場合は、使用中のプロセスを調べます。見覚えのないシステムプロセスを安易に終了しないでください。

Windowsでは、次の2つのコマンドを実行できます。1つ目はローカルの 7897 を使っているTCPの待ち受けを検索し、PIDを表示します。2つ目は、確認したPIDからプログラム名を調べます。例の 1234 は、実際に取得した値に置き換えてください。

netstat -ano -p tcp | findstr LISTENING | findstr ":7897 "
tasklist /FI "PID eq 1234"

別の方法として、「設定」→「Clashの設定」でポート項目を開き、混合ポートを 7898 などの未使用ポートに変更できます。バージョンによってメニューの場所が異なる場合は、mixed-port に対応する実際の項目を確認してください。変更後はコアを再読み込みし、システムプロキシをいったんオフにしてから再度オンにします。ブラウザー拡張機能、ターミナルなど、古いポートを手入力しているアプリも合わせて更新してください。

8. TUNモードが必要なのはどんなとき？有効にできない原因は？

TUNは仮想ネットワークインターフェースと関連するルートを使って通信を取り込みます。アプリごとにプロキシを設定しにくい場合に便利です。システムプロキシとは動作する階層が異なりますが、ルート、プロセスの除外設定、コア設定、システム権限の影響を受けます。すべての通信がリモートノードを経由するとは限りません。

Windows：まず「設定」→「サービスモード」で、サービスがインストールされ実行中か確認してからTUNを有効にします。サービスのインストールには通常、管理者権限が必要です。
macOS・Linux：クライアントの現在のバージョンで必要なネットワーク権限が付与されているか確認し、権限不足のログがないか調べます。
ほかのVPNを使用している場合：デフォルトルートやDNS設定が競合しないよう、ほかのVPNや仮想ネットワークアダプターを制御するツールを一時停止してください。

起動に失敗したら、最初に出た具体的なエラーを記録し、権限、インターフェースの作成、ルートの設定のどこに問題があるかを確認します。リモートデスクトップで操作している場合は、接続が切れるおそれがあるため、設定内容が分からないTUNを続けて切り替えないでください。TUNで通信を取り込めても、ノードがUDPに対応しているとは限りません。アプリに必要なプロトコルは、ノードとサーバーの両方が対応している必要があります。

9. サブスクリプション更新後にカスタムルールが消えるのはなぜ？

リモートサブスクリプションを更新すると、設定が再取得されます。ダウンロードした設定を直接編集しても、変更を長期保存する方法としては適していません。次回の更新でローカルの変更がリモート設定に置き換えられることがあります。ルールを継続して使うには、クライアントが対応するオーバーライド機能や拡張設定を使い、現在のサブスクリプションに適用されていることを確認してください。

ルールの位置を確認してから、ポリシー名を確認する

たとえば、例示用ドメインに直接接続するには、次のルールを追加します。このルールは、対象のリクエストを先に拾う広範なルールより前に配置してください。末尾のフォールバックルールである MATCH より後ろには置かないでください。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT

上記はルール項目の構造を示す例であり、完全なサブスクリプション設定ではありません。設定全体をこの例で置き換えないでください。オーバーライドの仕組みは、マージ、先頭への挿入、スクリプトによる変更など方式が異なります。rules 配列を貼り付ければ自動で追記されるとは限りません。宛先にカスタムプロキシグループ名を指定する場合は、最終的な設定内の名前と完全に一致させてください。保存後は実行中の設定と接続記録を確認し、サブスクリプションを手動で更新しても変更が残るか確かめます。各項目の意味は設定リファレンスを参照してください。

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

アプリを終了したあともシステムプロキシが 127.0.0.1 のポートを指していると、ブラウザーは待ち受けプログラムのないアドレスにリクエストを送信します。まずクライアントを再起動し、「システムプロキシ」とTUNを無効にしてから、通常の方法で終了してください。クライアントを起動できない場合は、システムのネットワーク設定を手動で元に戻します。

Windows 11：「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「プロキシサーバーを使う」と「セットアップスクリプトを使う」を確認します。このクライアントが設定した項目だけを元に戻してください。
macOS：「システム設定」→「ネットワーク」→ 現在のネットワークサービス →「詳細」→「プロキシ」を開き、Webプロキシ、安全なWebプロキシ、SOCKSプロキシを確認します。
ターミナル：以前 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY を手動設定した場合は、現在のターミナルと起動設定ファイルから該当する設定も削除してください。

会社の端末では、組織がプロキシ設定を一括配布している場合があります。すべての設定をそのまま消さず、元の値を記録して管理者に確認してください。直接接続に戻したら、コアの起動、ポートの待ち受け、明示的なプロキシリクエスト、システムプロキシの有効化の順に、一段階ずつ復旧します。TUNのテストは最後に行ってください。