ClashのサブスクリプションURLをインポートする方法：URL・ローカルYAML・対応形式の違い

インポート前に確認：サブスクリプションURL・設定ファイル・ノードURIの違い

Clashのサブスクリプションを正しくインポートできるかどうかは、URLが「.yaml」で終わるかではなく、取得した内容が使用中のコアの設定要件を満たしているかで決まります。アクセストークン付きのHTTPS URLから完全な設定を取得できる場合もあれば、「config.yaml」という名前のダウンロードリンクからログイン画面やエラーメッセージが返る場合もあります。

デスクトップクライアントはサブスクリプションの保存・更新のダウンロード・設定の切り替えを行い、Clashやmihomoのコアは設定の解析、接続の確立、ルールの適用を担います。画面に「ダウンロード成功」と表示されても、クライアントが応答を受け取ったことを示すだけで、コアがすべての項目を受け入れたとは限りません。

サブスクリプションURL：コンテンツを取得するためのリモートアドレスです。完全なClash YAMLの場合も、別形式のノードリストの場合もあります。
完全な設定ファイル：通常はproxiesまたはproxy-providersに加え、proxy-groupsやrulesなどの設定を含みます。
ノードURI：ss://、vmess://、trojan://などで始まる個別の接続情報です。通常、ルーティングルールは含まれません。

方法1：URLからリモートサブスクリプションをインポート

継続して利用するなら、リモートサブスクリプションがおすすめです。URLをクライアントに保存しておけば、ノードやルールを再取得できます。一方、ローカルファイルはその時点のコピーにすぎません。サービス側に「Clash」「Clash Meta」「mihomo」の選択肢がある場合は、使用中のクライアントがどのコアを使っているか確認し、対応するURLをコピーしてください。

サブスクリプション画面でダウンロードして有効化

以下では、Clash Verge Revでよく使われる画面表示を例に説明します。バージョンによって「サブスクリプション」が「設定」と表示されることがあります。項目名ではなく機能で判断し、ノード選択画面にインポート欄を探さないようにしてください。

クライアントを開き、左側の「サブスクリプション」画面に移動します。画面上部のURL入力欄に、HTTPSアドレスを省略せず貼り付けてください。
URLの前後に空白や改行、チャットアプリが付けた句読点がないか確認してから、「インポート」をクリックします。URLの末尾を「.yaml」に変更する必要はありません。
サブスクリプションのカードが作成されるまで待ちます。エラーが表示された場合は、ダウンロードまたは解析のメッセージを確認してください。同じURLを何度も追加しないようにしましょう。
該当するサブスクリプションカードをクリックし、現在の設定として選択します。クライアントによっては、この操作を「使用」または「有効化」と表示します。
「プロキシ」画面を開き、プロキシグループが表示されていることを確認してから、使用するノードを選択します。インポートが完了しても、システムプロキシが有効になるわけではありません。

サービスのページにある「ワンクリックインポート」は、独自のURLスキームでクライアントを起動する仕組みの場合があります。利用するには、OSに該当スキームのハンドラーが登録されている必要があります。クリックしても反応しない場合は、サブスクリプションURLを手動でコピーしてください。OSからの起動に失敗したのか、サブスクリプションをダウンロードできないのかを切り分けやすくなります。

更新オプションは項目ごとに確認

サブスクリプションカードのメニューから「編集」またはサブスクリプション設定を開き、更新間隔とダウンロード時のプロキシ設定を確認します。自動更新はクライアントの機能であり、トップレベルのrulesでは制御されません。画面の単位が分の場合、360は6時間です。秒の場合は21600を入力します。これは設定例であり、すべてのクライアントの初期値ではありません。

初回インポート時は、まだ利用できるプロキシがないため、サブスクリプションのダウンロードにプロキシを必須にすると依存関係が循環することがあります。直接接続では取得できず、利用可能な出口がすでにあると確認できた場合に限り、更新時のプロキシ設定を試してください。トップレベルのリモートサブスクリプションの更新間隔と、proxy-providers内のintervalは別の設定です。後者はコアがプロバイダーから取得する間隔で、単位は秒です。

方法2：ローカルYAML設定ファイルをインポート

サービス側から設定ファイルが直接提供されている場合、オフライン用にバックアップしたい場合、リモートからのダウンロード失敗を調べる場合は、ローカルインポートが便利です。ファイル選択画面から読み込むと、クライアントが設定のコピーを管理するのが一般的です。その後、元のダウンロードファイルを編集しても、実行中の設定には反映されないことがあります。

設定ファイルを、たとえばWindowsの「ダウンロード」フォルダーなど、分かりやすい場所に保存します。拡張子が「.yaml」または「.yml」であることを確認してください。拡張子が非表示のため「.yaml.txt」になっているケースにも注意が必要です。
クライアントの「サブスクリプション」または「設定」画面を開き、「ローカルファイルをインポート」を選びます。ドラッグ＆ドロップに対応するバージョンでは、ファイルを画面に直接ドラッグすることもできます。
ファイルを選択して保存し、その設定を有効にします。解析エラーが出た場合は、テキストエディターでエラーが示す行とその前の行を確認してください。
プロキシグループとログを開き、読み込み結果を確認します。クライアントの外にあるファイルを編集した場合は、再インポートするか、クライアントが提供する明示的な再読み込み機能を使ってください。

YAMLの構文が正しくても、プロキシ接続に適した設定とは限らない

構造を理解するための最小限の例を示します。直接接続のみを含み、プロキシノードはありません。サービスのサブスクリプションの代わりにはなりません。mixed-port: 7890は、この例で明示的に指定したHTTPとSOCKS共用ポートであり、すべてのクライアントの初期値ではありません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手動選択

YAMLのインデントにはスペースを使い、Tabは使わないでください。リスト項目は-で始め、キーと値の間には正しいコロンとスペースが必要です。一般的なYAMLパーサーで構文が有効でも、存在しないポリシー名、未対応のプロトコル項目、認証情報の不足などが原因で、コアが読み込みを拒否することがあります。

方法3：クリップボードから設定またはノード情報をインポート

クリップボードからのインポートは、完全な設定テキストを入手済みの場合や、クライアントが個別のノードURIの解析に対応している場合に便利です。対応状況はクライアントによって異なります。「サブスクリプションURLを貼り付け」と「クリップボードからノードを解析」は別の機能です。どちらもコピー＆ペーストを使うからといって、同じ入口だと考えないでください。

YAML設定全体：クライアントが「ローカル設定を新規作成」または設定エディターに対応している場合は、ローカル設定を作成し、内容を貼り付けて保存してから有効にします。
個別のノードURI：メニューに「クリップボードからインポート」があり、対象プロトコルに対応している場合のみ使用してください。インポート後は、どの設定のどのプロキシグループに追加されたかも確認します。
複数行のノードリスト：クライアントに一括解析機能が必要です。対応していない場合は、互換性のある設定形式に変換してください。ノードリストをサブスクリプションURLの入力欄に直接貼り付けてはいけません。

使用中のバージョンにテキストインポート機能がない場合は、完全なYAMLをUTF-8形式のローカルファイルとして保存し、ローカルファイルの手順でインポートしてください。YAMLを1行にまとめたり、インデントを手作業で削除したりしないでください。個別のノードを認識できても、クライアントが意図したDNS、ルール、プロキシグループを自動生成するとは限りません。

サブスクリプション形式の違い：Clash YAML・Base64・プロバイダーファイル

「サブスクリプション」は取得・更新方法を指す言葉で、特定のファイル形式を意味するものではありません。互換性を判断する際は、内容の構造、プロトコルの種類、コアの対応範囲を確認してください。拡張子やWebページ上のボタン名は、あくまで判断材料です。

コンテンツの種類	よくある特徴	インポート前の確認
Clashの完全なYAML設定	ノードまたはプロバイダーに加え、プロキシグループやルールなどの設定項目を含む	通常は設定としてインポートできますが、コアが対応する項目とプロトコルの確認が必要です
Base64形式のノードリスト	外側はエンコードされたテキストで、デコードすると複数行のノードURIが含まれていることが多い	通常、完全なClash設定としては直接読み込めません。クライアントでの解析または変換が必要です
個別のノードURI	ss、vmess、trojanなどのプロトコル名で始まる	クライアントのプロトコルインポート機能に依存し、完全なルール構成は含まれません
プロキシプロバイダー用YAML	トップレベルに`proxies:`があり、主にノードリストを含む	通常は`proxy-providers`から参照します。完全な設定として直接使うものではありません
他クライアント用の設定	JSON形式、または別の項目構造である可能性がある	拡張子を変えても互換性は得られません。変換ツールが元の形式に対応しているか確認してください

Base64はエンコード方式であり、プロトコルの互換性を補うものではない

Base64をデコードして復元できるのは、エンコードされたテキストだけです。ノードURIがClashのYAML項目に自動変換されたり、ルール、DNS、プロキシグループが補われたりすることはありません。ノードURIの一部だけにBase64が使われる場合もあります。長い文字列が含まれているだけで、応答全体がBase64形式のサブスクリプションだと判断しないでください。

Clashとmihomoでは対応範囲が完全には一致しない

mihomoはClash Metaの機能を引き継ぎ、さらに拡張しています。mihomo向けに生成された設定には、旧バージョンのClashが対応していないプロトコルやパラメーターが含まれることがあります。サービス側に複数の出力形式がある場合は、使用中のクライアントのコアに合わせて選んでください。コアが対応していないノードは、設定内のプロトコル名だけを変更しても使えるようにはなりません。

形式が合わない場合：まずネイティブ形式を選び、必要なら変換

まずサービス側に目的の形式があるか確認し、次にクライアントのコアを確認します。変換は最後の手段です。変換ツールで変更できるのは設定の表現方法であり、リモートサーバーが提供するプロトコル機能を変えたり、元データにない認証情報を復元したりすることはできません。

ネイティブ形式のサブスクリプションを優先：サービス側で使用中のコアに対応するClashまたはmihomo形式を選び、URLを省略せずコピーし直します。
元の内容を確認：ノードURI、Base64形式のリスト、完全なYAML、プロバイダーファイルを区別してください。WebページのHTMLをサブスクリプションとして変換ツールに渡さないでください。
信頼できる環境で変換：サービス側が提供する変換機能を使うか、自分で管理するローカル環境で変換ツールを実行してください。リモート変換サービスにサブスクリプションのトークンやノードの認証情報を渡す可能性があります。
出力形式とテンプレートを確認：完全な設定を出力するのか、ノードプロバイダーを出力するのかを確認し、生成されたプロキシグループ名、ルールの出口、DNS設定も確認します。
インポート後に順番に検証：まず設定が読み込めること、次にノードとプロキシグループが揃っていること、最後に実際に接続できることを確認します。変換ページに成功と表示されただけで判断しないでください。

変換後の設定では、元の形式に固有の項目が失われたり、テンプレートのルールで元のルールが置き換えられたりすることがあります。特にUDP、TLS、トランスポート層、証明書関連のパラメーターが保持されているか確認してください。証明書エラーが発生した場合は、端末の日時、サーバー名、サービス側の案内を確認します。証明書検証の無効化を一般的な変換手順にしないでください。

インポートエラーと動作確認：ダウンロード・解析・ルーティングの順に切り分ける

ダウンロードの失敗と取得内容の問題を分けて確認

HTTP 401または403：サブスクリプションのトークンが失効していないか、URLを完全にコピーできているか、サービス側にアクセス制限がないか確認します。ローカルのプロキシポートを何度も変更するだけでは解決しません。
リクエストがタイムアウトする：ネットワーク接続、サブスクリプションのドメイン名解決、更新時のプロキシ設定を確認します。ブラウザーでサービスのトップページを開けても、サブスクリプションのAPIに接続できるとは限りません。
応答の先頭がHTML：ログイン画面、認証画面、エラーページを取得している可能性があります。HTTP 200でもこうした内容が返ることがあるため、ステータスコードだけでなく実際の応答内容を確認してください。
プロキシまたはポリシーが見つからない：proxy-groupsで参照している名前と、ルール末尾の出口名が実在するか確認してください。大文字・小文字や空白も一致させる必要があります。
未対応のプロキシ形式または項目：実際に使用しているコアと、サブスクリプションの出力形式を確認します。画面テーマの変更やファイル名の変更では、コアの互換性問題は解決しません。

設定を有効にした後は、アプリの通信がクライアントを経由しているか確認

クライアントで現在の設定名が正しいことと、誤ってダイレクト接続モードに切り替えておらず、ルールモードになっていることを確認します。
使用するプロキシグループを開き、利用可能なノードを選びます。遅延テストの成功はテスト要求に応答があったことを示すだけで、すべてのWebサイトやプロトコルが使えるとは限りません。
システムプロキシ設定に従うデスクトップアプリでは、クライアントの「システムプロキシ」を有効にします。プロキシを手動設定する場合は、実際の待ち受けアドレスとポートを確認してください。mixed-port: 7890の場合、ローカルでは127.0.0.1:7890を使用できます。
ブラウザーから新しいリクエストを送信し、「接続」または「ログ」を確認して、接続先ドメイン、適用されたルール、最終的な出口を調べます。必要に応じて既存の接続を閉じてから再試行してください。

システムプロキシに従わないアプリでは、TUNモードで通信を取り込む必要がある場合があります。ただし、これはインポート後のルーティング設定です。TUNの動作はサービス権限、ルーティング、DNS設定にも左右されます。サブスクリプション形式の誤りは修正できず、ノードのない設定にノードを追加することもありません。