ClashサブスクリプションURLの取り込み方法：設定形式の判別・更新・よくあるエラー

サブスクリプションを追加する前にURLとクライアントの状態を確認

ClashのサブスクリプションURLは通常、アクセス認証情報を含むHTTPSアドレスです。クライアントがこのアドレスにリクエストを送ると、サーバーはClash設定ファイルやノード一覧、またはリクエスト内容に応じて変換した設定を返します。インポートはURLをソフトウェアに保存するだけの操作ではありません。クライアントはネットワーク通信、レスポンスの読み取り、テキスト形式の判別、プロキシ項目の解析を行い、その結果をClash Meta（mihomo）カーネルに渡して読み込ませます。そのため、ブラウザで開けるURLが現在のクライアントで認識できるとは限りません。

操作を始める前に、使用するサブスクリプションURLが有効か確認してください。コピー時にチャットアプリが付けた省略記号、改行、URLの前後の空白を含めないでください。疑問符より前だけをコピーするのも避けます。サブスクリプションによっては、認証情報がパスやクエリパラメータに含まれており、1文字欠けただけでログインページやエラーページ、空のレスポンスが返ることがあります。サブスクリプションURLは設定へアクセスするための認証情報に相当するため、スクリーンショットやログ共有ページ、公開リポジトリに載せないでください。

Clash Verge Revとmihomoカーネルが正常に起動できることも確認します。クライアント自体がカーネルの起動失敗、ポートの競合、設定ディレクトリへの書き込み不可の状態では、ダウンロードに成功しても設定を適用できない場合があります。まずクライアントの設定画面または稼働状況を開き、カーネルが動作中であることを確認してからリモート設定を追加してください。

Clashのサブスクリプション形式を見分ける方法

Clash Verge Revへ直接インポートするのに最も適しているのは、構造が整ったClash YAML設定です。通常はポート、動作モード、DNS、プロキシノード、プロキシグループ、ルールなどの項目が含まれます。サービスによって項目数は異なりますが、一般的な構成は次のとおりです。

mixed-port: 7890
mode: rule
proxies:
  - name: Example-HK
    type: ss
    server: edge.example.net
    port: 443
    cipher: aes-128-gcm
    password: sample-password
proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Example-HK
      - DIRECT
rules:
  - MATCH,Proxy

上記はYAMLの構造を示すための例です。実際の設定に含まれるノード種別、認証項目、通信パラメータは、サーバー側で正しく生成されている必要があります。YAMLはインデントに依存し、階層は通常スペースで表します。Tab、誤ったインデント、閉じていない引用符などが混入すると、解析に失敗することがあります。

完全なClash設定

完全な設定には通常、proxies、proxy-groups、rulesがそろっており、インポート後すぐに選択可能なプロキシグループを構成できます。新しい設定にはrule-providers、proxy-providers、dns、tun、snifferなどが含まれる場合もあります。mihomoはClash Metaの拡張項目に幅広く対応していますが、設定は使用するバージョンの項目定義に準拠していなければなりません。

Base64エンコードされたノード一覧

別のタイプのサブスクリプションでは、Base64でエンコードされたURI一覧が返されます。デコードすると、複数行のss://、trojan://、vmess://、vless://アドレスが表示されることがあります。これは汎用ノードサブスクリプションであり、完全なClash設定とは限りません。通常はプロキシグループ、ルール、DNS設定が不足しているため、直接インポートできるかはクライアントのバージョン、サブスクリプション変換機能、サーバーの返却方式によって決まります。インポート後に形式が無効と表示された場合は、同じ汎用URLを繰り返し送るのではなく、サブスクリプションサービスの形式選択でClashまたはClash Metaを選んでください。

単一ノードURIとWebページの内容

単一のプロトコルURIは1つの接続ノードだけを表し、完全なサブスクリプションではありません。クライアントによっては専用の追加画面から単一ノードを登録できますが、リモート設定の追加画面では通常、保存や更新が可能な設定内容が求められます。URLを開いたときにアカウントページ、認証コード画面、ログインページ、JSON形式のエラーオブジェクト、HTML文書が表示される場合、返された内容はClash YAMLではありません。よくある原因は、URLのコピー間違い、認証期限切れ、ログインの要求、途中ページへのリダイレクトです。

Proxy Providerによるリモートノードセット

proxy-providersは、Clash設定におけるリモートノードプロバイダーの仕組みです。メイン設定からリモートYAMLノードセットを参照し、指定した間隔で更新できます。Clash Verge Revの設定画面にリモートサブスクリプション全体を追加する操作とは、階層が異なります。前者は実行中のカーネルがメイン設定に従ってノードセットを取得し、後者はクライアントが設定ファイル全体を管理します。切り分ける際は、エラーがクライアントによる設定ダウンロードで発生したのか、カーネルが読み込んだ後のprovider更新で発生したのかを確認してください。

Clash Verge RevにサブスクリプションURLを追加する

バージョンによって画面の文言は多少異なりますが、操作場所は通常「サブスクリプション」または「設定」ページに集約されています。追加後すぐにネットワーク障害をノードのせいにせず、設定が選択されているか、カーネルの再読み込みが成功したか、プロキシの入口が有効になっているかを先に確認してください。

サブスクリプションURL全体をコピーする。
サブスクリプションサービスの設定ページから、ClashまたはClash Meta用のURLをコピーします。複数の形式がある場合は、mihomoと互換性のある設定を優先してください。QRコード画像のURLやWeb共有ページのURLをサブスクリプションURLとして使用しないでください。
設定管理ページを開く。
Clash Verge Revの設定またはサブスクリプション画面を開き、新規作成、URLからインポート、リモート設定などの入口を探します。リモートサブスクリプションはURL入力欄を使い、ローカルに保存済みのYAMLファイルはローカルファイルのインポートを使います。両者では更新方法が異なります。
URLを貼り付けて送信する。
アドレスが通常のプロトコル、一般的にはhttps://で始まっていることを確認します。送信後はクライアントによるダウンロードと解析が完了するまで待ちます。通信が遅いときに同じ項目を何度も作成すると、どの設定を使用しているのか判断しにくくなるため避けてください。
名前と更新日時を確認する。
追加に成功すると、設定一覧に新しいリモート設定が表示されます。分かりやすい名前、更新日時、利用可能な状態が表示されているか確認してください。名前がランダムな文字列だけの場合は識別しやすい名前に変更できますが、リモートURL自体は変更しないでください。
設定を選択して有効にする。
設定を一覧に追加しただけでは、現在の設定になっているとは限りません。新しい項目を選択し、カーネルの読み込みが完了するまで待ってから、プロキシ画面でプロキシグループを確認します。設定に多数のルールセットが含まれる場合、初回読み込み時にrule providerファイルのダウンロードも必要になることがあります。
プロキシグループを選択してプロキシの入口を有効にする。
プロキシ画面で主要なプロキシグループのノードを選択し、用途に応じてシステムプロキシまたはTUNモードを有効にします。システムプロキシはOSのプロキシ設定に従うアプリに主に影響します。TUNモードは仮想ネットワークインターフェースを通じてより多くの通信を引き受けるため、追加のシステム権限が必要になる場合があります。

サブスクリプションの更新、自動更新、ローカル変更

リモートサブスクリプションの利点は、元のURLへ再度リクエストしてノード、プロキシグループ、ルールの最新版を取得できることです。手動更新は通常、設定項目の更新ボタンから実行します。自動更新はクライアントまたは設定で指定した間隔に従って行われます。更新に成功すると、クライアントは新しい内容を保存し、カーネルの再読み込みを通知します。

更新前に、現在のネットワークからサブスクリプションサーバーへアクセスできることを確認してください。既存のプロキシノードが使えなくなり、サブスクリプションURLへのアクセスにもプロキシが必要な場合、「接続しないと更新できないが、更新しないと接続できない」という循環に陥ることがあります。その場合は、一時的にシステムプロキシを無効にして直接更新する、まだ使える古いノードへ切り替える、または提供元が信頼できることを確認したうえでブラウザからURLへアクセスできるかテストしてください。

リモート設定を直接編集すると、変更が上書きされることがあります。ダウンロードしたYAMLにルールを追加したり、DNSやプロキシグループを変更したりしても、次回のリモート更新でサーバー側の内容に置き換えられる可能性があります。長期的に保持したいローカル変更には、クライアントが対応するオーバーライド、設定のマージ、スクリプト機能を使い、適用順序を明確にしてください。ローカル設定としてコピーすれば変更は保持できますが、コピーした設定はリモートサブスクリプションの更新を自動的には引き継ぎません。

更新後にノード名が変わると、ローカルのオーバーライドにも影響する場合があります。カスタムルールが特定のプロキシグループ名を指定しているのに、サーバー側でそのグループ名が変更または削除されると、カーネルは指定先が存在しないと報告します。安定したオーバーライドでは、長期間維持されるプロキシグループをできるだけ参照し、大幅な更新後には必ずログを確認してください。

更新成功はノードの利用可能性を保証しない

サブスクリプションの更新が成功したことは、設定内容を取得して解析できたことを示すだけです。ノードへの接続は、サーバーの状態、名前解決、通信パラメータ、システム時刻、現在のネットワーク環境にも左右されます。設定一覧に「更新成功」と表示されていても、プロキシグループの速度テストがすべてタイムアウトする場合は、サブスクリプションを削除して再追加するのではなく、ノード接続のログを確認してください。

よくあるインポートエラーと確認の順番

URLが無効、または404・403が返される

404は通常、パスが存在しないことを示します。URLが途中で切れている、サブスクリプションがリセットされた、古いURLをコピーしたなどの可能性があります。403はサーバーが現在のリクエストを拒否したことを示し、認証期限切れ、アクセス制限、リクエスト条件の不一致などがよくある原因です。まずサブスクリプション管理画面から、対応する形式のURLを改めてコピーしてください。token、ファイル拡張子、クエリパラメータを推測で書き換えるのは避けます。これらは認証や形式の選択に関わっていることが多いためです。

レスポンスの内容が空

空のレスポンスは、サーバーの一時的な障害、アカウント状態の変化、ノード一覧がまだ生成されていないこと、ネットワーク中継機器による接続の早期切断などが原因で発生します。URLを漏えいさせないよう注意しながら、発生時刻、HTTPステータス、クライアントログを記録し、サブスクリプションサービスの管理画面でプランと契約状態を確認してください。ブラウザでダウンロードしたファイルが0バイトなら、問題は通常クライアントの解析前に発生しています。

YAMLの解析に失敗したと表示される

このエラーでは、ログに示された行番号と項目名を確認します。よくある原因は、インデントの不一致、コロンの後のスペース不足、閉じていない引用符、リスト階層の誤り、サーバーが現在のカーネルで認識できない項目を生成していることです。サブスクリプションサーバーが自動生成した内容なら、リモートファイルを1行ずつ修正するのではなく、Clash Meta形式を選び直して更新してください。

Base64テキストまたはURIの一覧がダウンロードされる

サーバーが汎用サブスクリプションを返していることを示します。まずサブスクリプション管理画面にクライアント種別や設定形式の選択肢があるか確認し、Clash、Clash Meta、mihomoに対応するURLを生成してください。サービスによっては、リクエストのUser-Agentに応じて異なる形式を返します。そのため、ブラウザで表示される内容とクライアントのリクエスト結果が異なる場合があります。この場合はクライアントログと実際に保存された設定を基準に判断します。

設定は解析できるが、カーネルの読み込みに失敗する

YAMLの解析は最初の段階にすぎません。カーネルはプロキシグループの参照、ルールの送信先、providerのパス、待受ポート、機能項目も検証します。たとえば、存在しないプロキシグループをルールが参照している、2つの受信設定が同じポートを使っている、providerファイルの形式が正しくない、といった場合に読み込みが失敗します。ログを開き、後から連続して出る再読み込み失敗ではなく、最初に現れた明確なエラーを特定してください。

証明書エラーまたは接続タイムアウト

証明書エラーは、システム時刻のずれ、証明書チェーンの異常、ドメインが誤ったアドレスへ解決されること、ネットワーク中継機器の干渉などが原因で発生します。まずシステムの日付、時刻、タイムゾーンを調整し、同じネットワークからのアクセス状況を確認してください。接続タイムアウトでは、DNS問い合わせ、TCP接続確立、TLSハンドシェイクのどの段階で時間切れになったかを切り分けます。発生段階によって対処方法も異なります。

更新後にプロキシグループが空になる

設定を読み込めるのにプロキシグループにノードがない場合、ノードproviderの更新失敗、フィルター式による全ノードの除外、サーバーが返したノード名とプロキシグループの参照先の不一致などが考えられます。proxy-providersの状態と更新ログを確認し、グループ内で静的なproxiesを使っているのか、動的なuse参照を使っているのかを確認してください。

インポート後の接続確認

設定の読み込みに成功したら、まずプロキシ画面でプロキシグループが空でないことを確認し、主要な選択グループにノードを1つ指定します。遅延テストを1回実行してもよいですが、結果が示すのはテスト先がその時点で応答できたかどうかだけで、すべてのWebサイトやプロトコルが利用できるとは限りません。続いてシステムプロキシを有効にし、システムプロキシ設定に従うブラウザで通常のWebページへアクセスします。ログに対象ドメインとルールのマッチ結果が出るか確認してください。

ログには、どのルールに一致したか、どのプロキシグループへ割り当てられたか、最終的にどのノードを使用したかが記録されるはずです。接続がDIRECTへ送られているなら直接接続です。REJECTに一致した場合は設定によって通信が遮断されています。プロキシグループに入った後で接続に失敗する場合は、ノードのハンドシェイクやDNS関連のエラーを確認します。ページが開くかどうかだけを見るより、問題を特定しやすくなります。

システムプロキシは正常なのに一部のアプリで通信が発生しない場合、アプリがシステムプロキシを無視している、独自のネットワークスタックを使用している、UDPを直接送信している可能性があります。その場合はTUNモードの有効化を検討します。有効にした後はOSの案内に従って権限を付与し、仮想ネットワークアダプター、ルーティングテーブル、DNSの引き継ぎ状態を確認してください。TUNはサブスクリプション形式を修復する機能ではありません。設定自体を解析できない、またはノードパラメータが誤っている場合、通信の引き受け方式を変えても解決しません。

最後に、設定を明確に管理する習慣を作りましょう。リモートサブスクリプションには識別しやすい名前を付け、定期的に更新し、重要な変更はオーバーライドで管理します。サブスクリプションURLを変更したら、無効な項目を削除して古い設定を誤って選ばないようにしてください。障害が発生したときは、「ダウンロードレスポンス、形式解析、カーネル読み込み、通信の引き受け、ノード接続」の順に確認します。この順番なら、似たように見える症状を具体的な工程へ切り分けられ、インポートのやり直しや設定の無闇な切り替えを減らせます。

Clash Vergeのインストールを続ける

ダウンロードページでOSとアーキテクチャを選ぶか、ガイドに従ってクライアントのインストール、サブスクリプションの追加、プロキシ設定を行ってください。

ダウンロードページへガイドを見る