Clash Verge Rev：ambiguous で選べないノードの対処

Clash Verge Revのノード画面でambiguousの表示、グレーになって選べない項目、別の配信元のノードに対応する遅延テストを記録します。次に、それらのノードが複数のプロキシproviderから提供され、同じ名前になっているか確認してください。

2026/10/9 に公開された公式 v2.5.8 では、この二つの問題の修正が明記されています。issue #8021 には、旧版でノードをクリックして選べない一方、既存の接続は使えるというユーザー報告があります。ただし、灰色になるノードがすべてこの問題に該当するわけではなく、すべての旧版や OS に影響があるとも判断できません。

実行設定に複数の proxy-providers があり、出所の異なるノード名が重複して、画面や測定結果に違いが出ることが手掛かりです。集合未読み込み、ノード利用不可、設定解析エラーは、それぞれのエラーを処理し、すべてを ambiguous と呼ばないでください。

クライアントの正確なバージョン、OS、現在の Profile、問題のグループ、重複したノード名を記録します。サブスクリプションの原文と実行中の設定を比較し、proxy-providers 配下のプロバイダー名、各プロバイダーのノード名、問題のグループの use リストを確認してください。プロバイダーのキー名自体が重複している場合は別の設定エラーであり、更新では直せません。

include-all-providers、include-all、exclude-type も確認します。対象バージョンの実装では、前二つの指定で全プロバイダーが取り込まれるため、use だけを書けば出所を分離できるとは言えません。種類の除外も候補ノードを変えます。これらの条件がない場合に、グループ自身が参照するプロバイダーの範囲で比較してください。

まずプロバイダーが読み込まれ、同名ノードが実際にあることを確認します。次に、そのノードとプロキシグループを別々にテストし、同じ信頼できるテスト先で結果を記録してください。元の選択で新しい HTTPS リクエストを送り、接続記録に想定どおりのグループと出口ノードが表示されるか確認します。ブラウザーがプロキシを迂回してアクセスできた結果は、比較材料になりません。

設定の Verge 詳細設定からバックアップ設定に入り、手動バックアップでローカルバックアップを選んで記録を作成します。その後、記録一覧からこの更新前のバックアップをエクスポートし、アプリのデータディレクトリ以外に保存してください。画面の訳語は異なる場合があります。ローカルの記録を作成しただけでは、独立したオフラインのコピーを取得したことにはなりません。

公式のバックアップ実装には profiles 内の通常ファイルとアプリ設定が含まれますが、データディレクトリ全体の複製ではありません。外部の Provider ファイルや自分で管理する他のリソースは、別途安全なコピーを保存してください。サブスクリプションのトークン、パスワード、元のバックアップは自分の端末だけに保管し、公開の不具合報告には添付しないでください。

画面の異常だけを理由に、動いているサブスクリプションを削除しないでください。

v2.5.8 は各プロキシグループが実際に使う Provider からノードを探し、別のプロバイダーにある同名ノードをそのグループのメンバーと取り違えないようにします。変更されるのは、クライアントがメンバーと取得元を対応付ける処理です。同じグループ内に全く同名の出口が二つある場合、それぞれ選べるかは実際の接続で確認し、表示の復旧だけで判断しないでください。

記事末尾の公式 Release から OS とアーキテクチャに合う v2.5.8 を入手し、プロジェクトが案内する通常の方法で更新します。設定とエクスポート済みのバックアップは残してください。当サイトの既存のクライアント用バックアップと、開発元の最新版は別の記録です。当サイトの古いバックアップ版を、今回の修正版の確認に使うことはできません。

同じグループに複数のプロバイダーから完全に同名のノードが残っている場合、画面でクリックできても、二つ目の出口ノードへ個別に切り替えられる証拠にはなりません。v2.5.8 の選択処理でも、送信するのはグループ名とノード名です。証拠が足りなければ未確認として記録し、繰り返した遅延テストや既存の長時間接続から切り替え成功を推測しないでください。

更新後もプロバイダーが空だったり、ダウンロードや解析のエラーが出たりする場合は、最初のエラーを残して取得元を調べます。メンバーと選択が正しいのに新しいリクエストが失敗する場合は、ノードの接続性、ルール、テスト対象を確認してください。すべての失敗をクライアント側の対応付けが原因だと考え続けないでください。

更新で必要なノードを選べるようになった場合は、さらに名前を変える必要はありません。同じグループ内の二つの同名出口ノードを区別する必要がある場合に限り、自分で管理するローカル設定のコピーで、該当する各プロバイダーに異なる override.additional-prefix を設定できます。例えば A- と B- です。これは Mihomo が公式に対応する出所別の接頭辞であり、リモートのサブスクリプションサービス自体を変更する操作ではありません。

additional-prefix は、そのプロバイダーの既存の override に追加し、他のフィールドを残してください。設定に明記された proxies の参照、名前のフィルター、スクリプト、保存済みの選択が旧名を指している場合があるため、併せて確認する必要があります。override 全体を直接置き換えたり、A- と B- をどのサブスクリプションでも使える固定値と考えたりしないでください。

通常のインポート機能で、別の名前を付けたローカルのコピーを追加し、元の Profile を残します。構文、ノード、ルール、必要なカスタマイズを先に確認し、短時間だけ切り替えて新しい名前と実際の出口ノードを検証してください。実行中の設定やスクリプトへの影響を判断できない場合は改名を止め、機密情報を伏せた証拠を残して開発元へ報告します。

失敗した場合は、動作していた元の Profile に戻し、今回実際に変更したアプリ設定も元に戻します。コピーに付けた接頭辞は他のサブスクリプションに自動で移行されません。サブスクリプション更新後の実行中の設定も再確認してください。一度テストに成功しても、今後ずっと動作する保証にはなりません。

設定が破損して復元が必要な場合は、まず現在のデータを残します。次にバックアップの記録一覧から更新前にエクスポートしたファイルをインポートし、該当の記録を選んでバックアップを復元してください。インポートは記録を追加するだけで、自動適用されません。復元後はサブスクリプション、ルール、プロキシモード、実際のリクエストを再確認します。

アプリのバージョンを戻す前に、バックアップの互換性と公式のセキュリティ告知を確認してください。issue にある v2.5.2 へ戻すというユーザーの提案を、そのまま実行しないでください。特に Windows サービスについては、該当する告知に影響を受けるバージョンと修正済みビルドが明記されています。新しいバージョンで作成したバックアップを旧版が読み込めるとも限りません。動作を確認済みの設定の復元を優先してください。

使える設定がない場合は通常の操作でプロキシによる通信処理を停止し、通常のネットワークを確認します。プロキシ経由が必須の業務は利用を控えてください。試行錯誤のために全データを消去したり、セキュリティソフトを無効にしたりせず、別の配布元のインストールファイルで公式の更新手順を迂回しないでください。

異常が続く場合は、クライアントの正確なバージョン、OS、機密情報を伏せたプロバイダーとグループの範囲、同名ノードの関係、ノード個別とグループのテスト、新しい接続の経路、終了と再起動後の結果を開発元へ報告します。一貫した仮名を使って構造を残し、サブスクリプションの認証情報、個人用アドレス、secret を伏せてください。観察した違いを説明し、未検証の出口ノードの選択を修正成功と記載しないでください。