Clash Vergeのよくある質問

Clash Vergeはデスクトップ向けプロキシクライアントのプロジェクト名です。Clash Verge Revは同様の使い方を引き継ぐコミュニティプロジェクトですが、両者は別々のリリース系列です。インストーラーとメンテナンス状況をそれぞれ確認してください。Mihomoはプロトコル接続、ルール判定、DNS処理を担うコアで、GUIクライアントはサブスクリプション管理、システムプロキシ、設定、ログ表示を担当します。問題を調べるときは、クライアントの「バージョン情報」や設定画面で正式名称を確認し、コアの情報も記録してください。「Clash」とだけ記載するのは避けましょう。デスクトップ版はスマートフォン向けアプリとは別です。AndroidとiOSでは各プラットフォーム対応のクライアントを選び、サブスクリプション形式への対応も確認してください。

クライアントは設定を読み込み、通信を転送するためのソフトウェアです。インストールしても、利用可能なプロキシサービスが自動で提供されるわけではありません。通常は利用権限のあるサービスからサブスクリプションURLを取得するか、プロキシノードとポリシーグループを含む設定ファイルを自分で用意します。サブスクリプションを読み込めても、アカウントが有効であることや、すべてのノードに接続できることを意味しません。初回はサブスクリプションの状態を確認し、利用可能なポリシーグループを選んでからシステムプロキシを有効にし、接続先のWebサイトで動作を確認してください。サブスクリプションURLにはアカウント情報が含まれる場合があるため、機密情報として扱いましょう。トラブルの調査時も、URL全体やQRコード、未加工の設定ファイルを公開しないでください。

ルールモードでは、設定ファイルのルールを上から順に適用し、通信ごとにダイレクト接続、拒否、またはプロキシのポリシーグループを選びます。グローバルモードでは、コアに入った通信をグローバルポリシーグループで処理します。ダイレクトモードでは、コアに入った通信を宛先へ直接接続します。グローバルモードでも、端末上のすべての通信が自動的に対象になるわけではありません。通信がコアに入るかどうかは、システムプロキシ、アプリごとのプロキシ、TUNなどの入口によって決まります。通常の振り分けにはルールモードを使い、一時的な切り分けにはグローバルモードで利用可能なノードを明示的に選んでから、元のモードに戻すとよいでしょう。モード切り替え後は接続をやり直してください。既存の長時間接続は出口がすぐに切り替わらない場合があります。DNSの問い合わせも、DNS設定を別途確認する必要があります。

システムプロキシは、OSにローカルプロキシのアドレスを登録する方式です。その設定に従うブラウザーやアプリに適していますが、一部のゲーム、コマンドラインツール、独自のネットワーク処理を行うアプリは設定を参照しません。TUNは仮想ネットワークインターフェースとルーティングを使い、設定条件に合う通信を取り込みます。より広範囲をカバーできますが、権限、ルート、DNSの設定が必要で、構成も複雑です。初めて設定するときは、まずシステムプロキシでサブスクリプションとノードの動作を確認し、必要に応じてTUNを有効にしてください。両方を併用できる場合もありますが、同時に有効にすることをトラブル対処の定番手順にしないでください。ほかのVPNや通信制御ツールも動作している場合は、ルートが競合しないよう、まずどちらかを停止してください。

まず、ダウンロードの失敗と設定の解析エラーを切り分けます。リクエストのタイムアウト、認証エラー、HTTP 403は、ネットワーク、アカウント、サーバー側の制限が原因の可能性があります。YAMLの解析エラーは、取得した内容をクライアントが設定として読み込めないことを示します。URLを最後まで正しくコピーしたか、アカウントの期限が切れていないか、サービス側でサブスクリプションのURLが変更されていないかを確認してください。ログインページやエラーページが返されている場合、何度追加し直しても解決しません。HTTP 403もアカウントの期限切れとは限らないため、サービス提供元の案内を確認しましょう。プロキシ経由でしかサブスクリプションにアクセスできない場合は、既存の接続を使って更新できます。更新方法はクライアントの設定によって異なります。出所のわからないオンライン変換サービスに、非公開のサブスクリプションを渡さないでください。

デバイスのメーカー名だけでなく、OSに表示されるCPUアーキテクチャを確認してください。一般的なIntelまたはAMD搭載のWindows PCではx64版を使います。ARMデバイスでは、対応するクライアント版が提供されているか、OSが互換実行に対応しているかを確認してください。macOSでは「このMacについて」でAppleシリコンかIntelかを確認し、対応するインストーラーを選びます。Linuxのamd64とarm64はアーキテクチャ、debとrpmはディストリビューションのパッケージ形式です。それぞれ別の区分であり、相互に置き換えることはできません。実行できない、または依存関係が不足している場合は、再インストールの前にアーキテクチャ、ディストリビューション、システム要件を確認してください。出所や互換性が不明なインストーラーに対処するために、OSのセキュリティ機能を無効にしないでください。

ログで失敗しているのがサービスの起動、仮想ネットワークアダプターの作成、ルート設定のどれかを確認してください。スイッチが元に戻るかどうかだけで判断しないでください。Windowsでは、クライアントが必要とするサービスモードがインストールされ、実行中か確認します。サービスのインストールや修復には、通常、管理者権限が必要です。macOSではシステムが求める権限付与の手順を完了してください。Linuxではクライアントの説明に従って、サービスや必要なネットワーク権限を設定します。権限を付与したらコアを再起動して動作を確認してください。デバイスの使用中やルートの競合がログに記録されている場合は、ほかのVPN、古いプロキシサービス、重複して起動したクライアントを停止します。必要な権限はOSやクライアントのバージョンで異なります。個別のエラーを解決するために、すべてのプログラムを常に最高権限で実行するのは避けてください。

自動起動は、OSへのログイン後にクライアントを起動する機能です。ネットワークの準備、サブスクリプションの更新、TUNサービスの起動まで保証するものではありません。まず手動起動で、現在の設定、ポリシーグループの選択、プロキシの入口が正常に動作することを確認してから、自動起動を有効にしてください。サイレント起動は通常、ウィンドウを表示するかどうかを制御する機能で、接続を修復するものではありません。再起動後は、タスクバーやメニューバーでクライアントとサービスの状態、ログの時刻を確認してください。ウィンドウを閉じてもプロセスが動作し続けているのか、プロセス自体が起動していないのかを切り分けます。ネットワーク接続前にサブスクリプションの更新が実行されてしまう場合は、接続後に手動で更新して再試行してください。クライアントを終了する前に、終了時にシステムプロキシがどう復元されるかも確認し、停止したポートを指す設定が残らないようにしましょう。

ルールは通常、上から順に照合され、一致した時点で対応するポリシーが適用されます。末尾のMATCHによるフォールバックより後に書いたルールは、通常実行されません。まず接続ログで宛先ドメイン、一致したルール、実際に適用されたポリシーを確認し、ドメインルール、IPルール、ルールセットのどれを使うべきか判断してください。ルール末尾で指定するポリシーグループ名は、設定と完全に一致している必要があります。変更後は設定が再読み込みされたかも確認しましょう。ブラウザーのアドレスバーだけを見て判断しないでください。ページが複数のドメインからリソースを読み込む場合があり、既存の接続には以前のポリシーが適用され続けることもあります。長期間保持するルールは、クライアントが対応するオーバーライドまたはマージ機能に追加し、挿入位置を確認してください。サブスクリプションから生成されたファイルを直接編集すると、次回の更新で変更が上書きされる場合があります。

サブスクリプションを更新すると、リモートの設定が再取得されます。そのファイルを直接編集していた場合、更新時に変更が上書きされることがあります。ノード名やポリシーグループ名が変わると、以前の選択肢に該当項目が見つからず、デフォルトに戻る場合もあります。まず、保持したい内容がカスタムルール、DNSの項目、ポリシーグループの構成のどれかを確認してください。そのうえで、現在のクライアントが提供するオーバーライド、マージ、スクリプトの機能を使い、適用順序も確認します。編集前に復元可能なバックアップを保存し、更新後はエディター上の元ファイルだけでなく、最終的に適用された設定を確認してください。復元時は項目ごとにマージし、古いノード情報、期限切れのルールセットURL、サポートされなくなった項目で新しい設定全体を上書きしないようにしましょう。

fake-ipは、DNS応答と接続を対応付ける方式です。すべてのDNSリクエストが取り込まれていることを意味するわけではありません。システムDNS、ブラウザーのセキュアDNS、クライアントのDNSリスナーと上流DNSの設定、TUNがDNSを取り込む範囲をそれぞれ確認してください。テストする前に、利用する想定のDNSサービスを記録し、ログや実際の問い合わせ経路と照らし合わせます。テストサイトに表示されるDNSリゾルバーの所在地だけでは、漏れが起きているとは判断できません。ブラウザー内蔵の暗号化DNSはシステムの名前解決を迂回する場合がありますが、その通信自体はプロキシを経由することもあるため、実際のルートを確認してください。設定は一度に一か所だけ変更し、アプリのDNSキャッシュを消去してから再接続すると、原因を特定しやすくなります。

ほかのデバイスには、クライアントを実行しているPCの現在のLAN内IPアドレスと、クライアントが実際に待ち受けているプロキシポートを設定します。127.0.0.1は各デバイス自身を指すため、使用できません。LAN接続の許可が有効になっていること、待ち受けアドレスが外部デバイスからアクセス可能であること、両方のデバイスが通信できるネットワークに接続していることを確認してください。そのうえで、ファイアウォールが信頼できるネットワークに限ってポートを許可しているか確認します。ゲストWi-Fiや無線LANのクライアント分離によって、デバイス間通信が遮断される場合があります。PCがスリープ状態になっても接続は切れます。信頼できるLAN内でのみ使用し、プロキシポートをインターネットに公開しないでください。共有を使わなくなったら無効にしましょう。クライアントのポートを変更した場合は、ほかのデバイスの設定も更新してください。

まず、クライアントの接続ログに対象のリクエストが記録されているか確認してください。ログがまったくない場合は、コアが動作しているか、OSに登録されたアドレスとポートがクライアントの設定と一致しているか、アプリ独自のプロキシ設定、ブラウザー拡張機能、除外リストが使われていないかを確認します。コマンドラインツールには個別にプロキシの引数を設定する必要がある場合があります。その接続結果だけでシステムプロキシの不具合と判断しないでください。接続ログがある場合は、一致したルールとポリシーを確認します。プロキシの入口ではなく、ルールがダイレクト接続を選択している可能性があります。設定を変更した後は接続をやり直してテストしてください。ほかのプロキシツールがシステム設定を繰り返し上書きしていないかも確認します。複数のクライアントを同時に起動し、同じポートやシステムプロキシ設定を奪い合わないようにしてください。

まずプロキシの入口を無効にし、通常ダイレクト接続できるサイトにアクセスできるか確認します。次に、サブスクリプションが有効か、システム時刻が正確かを確認してください。速度テストのタイムアウトは、テスト先に到達できないだけの場合もあり、それだけでノードの停止とは判断できません。実際のWebサイトへの接続結果とコアのログも合わせて確認します。利用できることが分かっているノードを1つ選び、一時的にグローバルモードでテストし、エラーが名前解決、接続確立、プロトコルのハンドシェイクのどこで発生するかを確認してください。一部のノードだけ失敗する場合はノードやサービスの状態を優先して確認します。すべて失敗する場合は、ローカルポート、DNS、ネットワーク制限、ほかのVPNとの競合を調べましょう。変更は一度に1項目にし、元の値も記録してください。原因を再現・特定できる問題を、何度も再インストールして覆い隠さないようにしましょう。

AppContainerで分離されている一部のWindowsアプリは、既定ではローカルのループバックアドレスにアクセスできません。そのため、ブラウザーが正常でも、アプリから127.0.0.1上のプロキシに接続できない場合があります。まず対象アプリがこのケースに該当するか確認し、管理者権限のターミナルでCheckNetIsolation LoopbackExempt -sを実行して、既存の例外を確認してください。Get-AppxPackageで対象アプリのPackageFamilyNameを調べ、CheckNetIsolation LoopbackExempt -a -n=にそのパッケージファミリ名を指定します。必要なアプリだけに例外を追加し、アプリを再起動して動作を確認してください。TUNで通信を取り込む方法も検討できますが、ネットワーク接続の失敗がすべてループバック制限によるとは限りません。企業の管理デバイスでは管理ポリシーに従い、すべてのアプリに一括で例外を追加しないでください。

証明書の警告を無視することを通常の解決策にしてはいけません。アクセスを続けるために、出所のわからないルート証明書をインストールするのも避けてください。まずシステムの日付、タイムゾーン、時刻同期を確認し、プロキシを無効にした場合の同じWebサイトの状態と比較します。プロキシを有効にしたときだけエラーが出る場合は、HTTPS復号ツール、セキュリティソフトの暗号化通信スキャン、DNSの誤応答、ログインが必要なネットワークポータルの有無を確認してください。通常のプロキシ転送で、接続先Webサイトの証明書を置き換える必要はありません。複数のサイトに同じ見覚えのない発行者が表示された場合は、機密情報を扱う操作を中止し、証明書チェーンを確認してください。1つのサイトだけで発生し、異なるネットワークでも再現する場合は、サイト側の証明書に問題がある可能性があります。ブラウザーの検証を弱めず、サイト側の修正を待ちましょう。