ClashのサブスクリプションURLをインポートする方法：URL・YAML設定・主な形式の解説

Clashクライアントに設定を追加するとき、最も混同しやすいのはボタンの場所ではなく、手元のデータがどの形式に当たるかです。サブスクリプションURL、ローカルYAML設定、単一ノードの共有リンク、プロキシプロバイダー用ファイルはいずれもサーバー情報を含む場合がありますが、用途、インポート画面、更新方法はそれぞれ異なります。単一ノードのリンクをサブスクリプション欄に貼り付けたり、WebページのURLをYAMLとして保存したりすると、「形式が正しくありません」「設定の解析に失敗しました」「プロキシグループが見つかりません」といったエラーが表示されがちです。

グラフィカルなクライアントによってメニュー名には多少の違いがあり、一般的な入口には「設定」「サブスクリプション」「Profiles」「設定ファイル」などがあります。最終的には、どの画面でもデータをClash互換コアに渡して解析します。データの種類を理解していれば、画面構成が変わってもURLを貼り付けるのか、ローカルファイルを選ぶのか、それとも先に完全な設定へ変換するのかを判断できます。

サブスクリプションURL・ノードリンク・YAMLファイルの違い

サブスクリプションURL：リモートサービスが設定内容を返すURL

サブスクリプションURLは通常、https://で始まるアドレスです。クライアントはこのURLを保存した後、ネットワークへリクエストを送り、サーバーから返された内容をリモート設定として保存します。その後「サブスクリプションを更新」を実行すると、同じURLへ再度アクセスし、ノードの変更、プロキシグループの調整、ルールの更新を取得します。

URLそのものは設定本文ではありません。インポートできるかどうかを決めるのは、HTTPレスポンスの内容です。一見正常なサブスクリプションURLでも、完全なClash YAML、ノードだけを含むエンコード済みテキスト、ログインページ、エラーページ、JSONなどが返ることがあります。ブラウザーでURLを開けるからといって、Clashコアが解析できるとは限りません。

https://example.com/api/client/subscribe?token=example-token

サブスクリプションのパラメーターは、アカウントの識別やクライアント形式の選択に使われることがあります。コピーする際はクエリパラメーターを含む完全なURLを保持し、疑問符以降を欠落させないでください。サービスページに「Clash」「Clash Meta」「Mihomo」専用の入口がある場合は、汎用URLで互換性を推測せず、現在のコアに合う形式を優先します。

単一ノードの共有リンク：1つのプロキシノードだけを記述

単一ノードのリンクは通常、ss://、trojan://、vmess://、vless://のようにプロトコル名で始まります。サーバー、ポート、認証パラメーター、通信設定など1つのノードを記述しますが、Clashの動作に必要な完全なプロキシグループ、ルール、デフォルトの出口までは含まれないのが一般的です。

一部のクライアントには「クリップボードからノードをインポート」する機能があり、共有リンクをノード項目へ変換できます。一方、完全な設定だけを受け付けるクライアントもあります。この場合、単一ノードのリンクをサブスクリプションURL欄に貼り付けても成功しません。その欄はリモートのHTTP URLへアクセスすることを想定しているためです。ノードへ変換できたとしても、proxiesに追加し、proxy-groupsとrulesから参照する必要があります。

ローカルYAML：コアが直接読み込める設定ファイル

YAMLファイルは通常、.yamlまたは.ymlで終わり、ポート、動作モード、ノード、プロキシグループ、ルール、DNS、TUN設定などを含みます。完全な設定は「ローカル設定をインポート」または「設定ファイルを開く」から読み込めます。リモートサブスクリプションとは異なり、ローカルファイルは元のURLから自動更新されません。ファイルを編集した後は、通常、再読み込みするかクライアント内で更新する必要があります。

最小構成の例を以下に示します。実際のノードパラメーターは信頼できる提供元から取得してください。この例は各セクションの関係を説明するためのものです。

mode: rule

proxies:
  - name: Example
    type: ss
    server: 192.0.2.10
    port: 443
    cipher: aes-128-gcm
    password: example-password

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Example
      - DIRECT

rules:
  - MATCH,PROXY

proxiesは接続可能なノードを定義し、proxy-groupsはユーザーが選択できる出口を決め、rulesはトラフィックを対応するポリシーへ振り分けます。proxiesだけがあり、利用可能なルールやプロキシグループがない場合、構文チェックは通っても、意図した振り分けはできないことがあります。

ClashクライアントにサブスクリプションURLをインポートする手順

クライアントが使用しているコアを確認する。
オリジナルのClash、Clash Meta、mihomoは基本設定について幅広い互換性がありますが、拡張プロトコル、ルール形式、DNSフィールド、TUNオプションは完全には一致しません。現在主流のクライアントはmihomoコアを採用していることが多いため、インポート時はサービス側が提供するClash Metaまたはmihomo形式を選択してください。
サブスクリプションURLを完全な形でコピーする。
サブスクリプション管理画面のコピー機能を使い、URLの前後にスペース、改行、説明文が混ざっていないか確認します。画面上で省略表示された一部だけをコピーしたり、ブラウザーのアドレスバーにあるログインページのURLをサブスクリプションURLとして使ったりしないでください。
設定またはサブスクリプション画面を開く。
「新しいサブスクリプション」「URLからインポート」「Download Remote Profile」などの入口を探します。設定には判別しやすい名前を付け、URLをリモートアドレス欄へ入力します。画面にファイル選択欄もある場合、YAMLファイルはファイルインポートから読み込み、URL欄には入れないでください。
ダウンロードを実行し、状態を確認する。
クライアントがリモートURLへアクセスし、レスポンスを解析します。成功すると通常、設定名、更新日時、ノード数、ファイルサイズなどを確認できます。設定カードが作成されても内容が空の場合は、すぐにシステムプロキシを有効にせず、更新ログを確認してください。
現在の設定に指定し、ポリシーを選択する。
インポートに成功しただけでは、設定が有効になったとは限りません。設定を選択し、プロキシ画面でプロキシグループの出口を指定する必要があります。ルールモードではrulesに従ってトラフィックが振り分けられ、グローバルモードでは通常、ほとんどのトラフィックが指定したグローバルポリシーへ送られます。
最後にシステムプロキシまたはTUNを有効にする。
システムプロキシは、OSのプロキシ設定に従うアプリに適しています。TUNモードは仮想ネットワークインターフェースを通じて、より広い範囲のトラフィックを処理しますが、システム権限が必要になることがあります。初回設定ではまず通常のシステムプロキシで動作を確認し、対象アプリの範囲に応じてTUNを有効にしてください。

Clash YAMLの主なセクションと形式上の注意点

YAMLはインデントで階層を表すため、通常はスペースを使い、タブを混在させないでください。コロンの後にはスペースを入れ、リスト項目はハイフンで始めます。特殊文字を含む値は引用符で囲めます。エディターが半角記号を自動的に置き換えることでも、解析に失敗する場合があります。

ノード名とプロキシグループ名を一致させる

プロキシグループは、名前を使ってノードや他のプロキシグループを参照します。ノード名を「東京 01」から「東京メイン」に変更した場合、古い名前を参照している箇所もすべて変更してください。そうしないと、コアがプロキシの不存在を報告したり、設定読み込み時にプロキシグループの作成を拒否したりすることがあります。

proxy-groups:
  - name: AUTO
    type: url-test
    proxies:
      - Tokyo-01
      - Singapore-01
    url: https://www.gstatic.com/generate_204
    interval: 300

selectグループはユーザーが手動で選択し、url-testグループはテスト結果に基づいて利用可能なノードを選び、fallbackは順番に利用可能なノードへ切り替えることを重視します。対応状況はコアのバージョンとクライアントの実装によって異なります。測定先、間隔、許容差も自動選択の結果に影響するため、1回の遅延値だけで長期的な品質を判断しないでください。

ルールは上から順に照合される

Clashのルールは通常、上から下へ確認され、マッチすると後続のルールは処理されません。完全一致のドメイン、ドメインサフィックス、IPネットワーク、ルールセットは、設定の目的に合う位置へ配置し、フォールバック用のルールは通常末尾に置きます。たとえばDOMAIN-SUFFIX,example.com,DIRECTは指定したドメインサフィックスを直接接続ポリシーへ渡し、MATCH,PROXYはそれまでにマッチしなかったトラフィックを受け取ります。

ルール内のポリシー名は、プロキシグループまたは組み込みポリシーに存在している必要があります。サブスクリプション変換サービスがプロキシグループ名を変更したのに、ルール側の参照を更新していない場合、設定のインポートに失敗することがあります。この場合はノード一覧だけでなく、proxy-groupsとrulesを同時に確認してください。

プロキシプロバイダーは完全なサブスクリプション設定ではない

proxy-providersはリモートファイルからノード群を読み込み、プロキシグループがuseで参照できるようにします。プロバイダー用ファイルは通常、ノードの集合だけを担い、設定全体のDNS、ルール、ポートは定義しません。providerのURLを完全な設定として直接インポートすると、クライアントから必須フィールドの不足を指摘されることがあります。

proxy-providers:
  remote-nodes:
    type: http
    url: https://example.com/provider.yaml
    path: ./providers/remote-nodes.yaml
    interval: 3600

proxy-groups:
  - name: PROXY
    type: select
    use:
      - remote-nodes

ここでいうリモートファイルは、メイン設定から参照されます。クライアントはまずメインYAMLを読み込み、そこに定義されたproviderに従ってノード群をダウンロードします。この2段階の更新は別々に動作します。メイン設定を更新しても、すべてのプロバイダーがすぐに更新されるとは限らず、個別のprovider更新機能があるかどうかによって挙動が変わります。

サブスクリプションのインポートに失敗したときの確認順序

手順1：リクエストで設定を取得できたか確認する

まず、クライアントのログでHTTPステータスとエラーの種類を確認します。401や403は、認証情報の期限切れ、アクセス権の変更、リクエストパラメーターの不足でよく発生します。404はパスが変更された可能性を示し、タイムアウトの場合は現在のネットワーク、DNS解決、システム時刻を確認します。レスポンスがHTMLなら、ログインページ、認証ページ、エラー説明ページへリダイレクトされた可能性が高いです。

一部のサブスクリプションURLはブラウザーのログイン状態に依存しますが、クライアントのリクエストにはブラウザーのセッションが自動的に引き継がれません。サービスのサブスクリプション管理画面から専用URLを取得し、ログインしないと開けない通常のWebページURLはコピーしないでください。

手順2：返されたデータ形式を確認する

完全なClash YAMLには、proxies、proxy-groups、rulesなどのフィールドが見られることが多いです。長いエンコード文字列だけが返る場合は、他のクライアント向けの形式かもしれません。プロトコルリンクが複数並んでいるだけなら、ノード集合に近い形式です。その場合はサービスページで出力形式を切り替えるか、クライアントが明確に対応している方法でインポートしてください。

ファイル拡張子だけでは、レスポンスの種類を確実に判断できません。URL末尾に.yamlがなくても、サーバーがYAMLを返す場合があります。逆に、YAMLと書かれたURLでも、認証に失敗してWebページが返ることがあります。実際のレスポンスとログを基準に判断してください。

手順3：YAMLの構文とフィールドのエラーを特定する

ログに行番号や列番号が示されている場合は、まずその周辺のインデント、コロン、引用符、リスト構造を確認します。原因がエラー表示行の前にあることもあります。たとえば前の行の引用符が閉じていない場合、解析器が異常を検出するのは次の行です。設定を変更する前に元のコピーを保存し、一度に大部分を削除するのではなく、項目ごとに調整すると原因を特定しやすくなります。

「フィールドに対応していません」というエラーは、コアの違いに関係することがよくあります。設定がmihomoの拡張ルール、新しいプロトコルフィールド、更新されたDNS構造を使用している一方、現在のクライアントのコアが古い可能性があります。互換性のあるクライアントへ更新する、対応するサブスクリプション形式を選ぶ、現在のコアのドキュメントに合わせてフィールドを調整する、といった方法で対処してください。認識できない設定項目を適当に削除して、そのまま実行するのは避けましょう。

手順4：設定同士が上書きしていないか確認する

一部のクライアントでは、サブスクリプション設定、グローバル上書き、マージ設定、スクリプト処理が別の階層に分かれています。リモートYAML自体が正しくても、ローカルの上書き設定が重複したポート、誤ったプロキシグループ、古いDNSフィールドを追加すると、最終的な設定を起動できなくなることがあります。調査時は上書き機能を一時的に無効にし、元のサブスクリプションだけが読み込めることを確認してから、カスタム項目を1つずつ戻してください。

インポートには成功したのにインターネットへ接続できない場合は、「設定の解析問題」と「接続問題」を分けて考える必要があります。前者は通常、読み込み段階で明確なエラーが発生します。後者は、ノードのタイムアウト、ドメイン名の解決失敗、システムプロキシの未有効化、TUNルートの構築不良などとして現れます。ログがどの段階で発生しているかを先に確認すれば、同じサブスクリプションを何度も削除して再インポートする手間を避けられます。

サブスクリプション更新・設定保存・移行時の注意点

リモートサブスクリプションは、ノードやルールの変更を継続的に受け取るのに適しています。ただし、ローカルで直接編集した内容は次回更新時に上書きされることがあります。残しておきたいカスタムルールは、クライアントが提供する上書き、マージ設定、スクリプト処理の機能に入れるのがおすすめです。対応機能がない場合は、独立したローカルYAMLを管理し、ノードの取得元だけ手動で更新してください。

サブスクリプションURLにはアクセス認証情報が含まれていることが多いため、アカウントの鍵と同じように管理してください。スクリーンショット、ログ、質問内容を共有するときはクエリパラメーターを隠し、完全なURLを公開ページに掲載しないようにします。端末を変更する場合は、公開チャットの履歴でURLを渡すのではなく、新しい端末でサブスクリプションを再コピーしてください。

Clashクライアントから別のクライアントへ移行するときは、まず移行先が採用するコアと設定ディレクトリのルールを確認します。基本的なYAMLは再利用できることが多いものの、グラフィカルクライアントに保存されたサブスクリプション一覧、ポリシー選択、上書きスクリプト、TUN権限はクライアントの状態であり、YAMLに含まれるとは限りません。移行後は現在の設定を選び、プロキシグループを確認し、システムプロキシまたは仮想ネットワークインターフェースの権限を改めて付与してください。

サブスクリプションの更新間隔も短くしすぎないでください。ノード提供元とメイン設定には、通常、適切な更新間隔が定義されています。頻繁にリクエストしても実際の改善につながりにくく、リモート側のアクセス制限を受ける可能性があります。普段はサービスの推奨に従って更新し、ノード一覧に明らかな変化があったとき、設定の期限切れが表示されたとき、ルールを更新したいときに手動更新を実行しましょう。

すぐに判断：手元のデータはどこに入れるべきか

HTTPSで始まり、サブスクリプション管理画面から提供されたURL：「URLからインポート」または「リモート設定」の入口に入力します。
プロトコル名で始まる単一行のテキスト：クライアントのノードインポート機能を使うか、変換して完全なYAMLに記述します。
パソコンやスマートフォンに保存された.yaml、.ymlファイル：ローカルファイルのインポートを使い、オンラインサブスクリプション欄にファイルパスを入力しないでください。
ノード一覧だけを含むproviderファイル：メイン設定のproxy-providersから参照します。完全な動作設定の代わりにはできません。
開くとWebページ、ログイン画面、エラー説明が表示されるURL：返された内容はそのまま解析できるClash設定ではありません。専用のサブスクリプションURLを取得し直してください。
インポートできたのにプロキシ画面にプロキシグループがない場合：設定がノードだけになっていないか、プロキシグループが正しく参照しているか、現在の設定が有効になっているかを確認します。

Clashのサブスクリプションインポートで重要なのは、別のボタンを何度も試すことではなく、まず入力形式を見極め、クライアントのコアと設定内容が一致しているか確認することです。サブスクリプションURLはリモート更新を担い、YAMLは完全な動作構造を記述し、単一ノードリンクは1つの接続項目だけを提供し、proxy providerはメイン設定から管理されるノードの取得元です。「リクエスト結果、データ形式、YAML構造、コアの互換性、動作状態」の順に確認すれば、多くのインポート問題を正確に特定できます。