サブスクリプション 読了時間：約10分

Clashのサブスクリプション形式を解説：Base64ノードリスト・YAML設定・共有リンクの違い

サブスクリプションでよく使われる形式や、mihomoが直接読み込める形式、変換が必要なケースを解説。変換環境を構築する際の注意点やグループ設定も紹介します。

サブスクリプションURLと取得データは別物：入口と中身を見分ける

ClashのサブスクリプションURLは、通常HTTPSリンクです。これは設定を取得するための入口であり、返される内容が必ずClashやmihomoの設定要件を満たすとは限りません。同じサービスが汎用ノードリスト、Clash設定、ほかのクライアント向け形式をそれぞれ提供していることもあります。また、リクエストのパラメーターやクライアントのUser-Agentに応じて、返す内容を変えるサービスもあります。

形式を判断するときは、URLの拡張子だけでなく、クライアントがダウンロードしたレスポンス本文を確認してください。.yamlで終わらないURLでも完全なYAMLが返る場合があります。一方、拡張子が付いていても、ログイン期限切れでHTMLページが返ることがあります。HTTPステータスコードが200でも、サーバーから応答があったことを示すだけで、設定が有効とは限りません。

よく使われる3つの形式：共有リンク、Base64リスト、YAML

形式 見分け方 一般的な内容 Clashでの取り扱い
ノード共有リンク ss://、vmess://、vless://、trojan://などで始まる 単一ノードのプロトコル、アドレス、認証情報、一部の通信パラメーター 対応プロトコルを扱えるクライアントのインポート機能か、変換ツールで解析
Base64ノードリスト 本文は長いエンコード文字列で、デコードすると1行ごとの共有リンクになることが多い 複数のノード。Clashのグループやルールは通常含まれない まずデコードしてノードを解析し、用途に合った設定またはプロバイダーファイルを生成
完全なClash YAML設定 トップレベルにproxies、proxy-groups、rulesなどのフィールドがある ノード、プロキシグループ、ルーティングルール、必要に応じてDNSなどの設定 フィールドとプロトコルが現在のコアに対応していれば、設定として読み込み可能
プロキシプロバイダー用YAML 主な内容はトップレベルのproxiesリスト メイン設定から参照するノードの一覧 メイン設定のproxy-providersから読み込み、プロキシグループで参照

共有リンクだけではプロキシルールまで設定されない

共有リンクにはノードの情報を記述できますが、通常「どのドメインを直接接続するか」「どのプロキシグループで最終判定するか」までは含まれません。たとえば、TLS、SNI、WebSocketパスはノードの接続パラメーターです。一方、DOMAIN-SUFFIX、GEOIP、MATCHはClashのルーティング設定です。役割の異なる情報なので、ノードリンクから完全なルールを自動生成することはできません。

プロトコルによってリンクのエンコード方式も異なります。vmess://はJSONをエンコードした形式が一般的です。ss://には過去から複数の表記方法があります。vless://では、クエリパラメーターに通信設定を含めることがよくあります。すべてのリンクを同じBase64形式として分解すると、フィールドの見落としや誤読につながります。

Base64はエンコード方式であり、暗号化ではない

「Base64サブスクリプション」は、複数行のノードリンクをまとめてエンコードして返す形式が一般的です。デコードで元のテキストに戻せますが、プロキシグループが追加されたり、未対応プロトコルが対応済みになったりするわけではありません。URLセーフ文字が使われたり、末尾のパディングが省略されたりする場合もあるため、「末尾がイコールで終わるか」だけでBase64かどうかを判断しないでください。

ノードのパスワードやサブスクリプションの認証情報が、エンコードされた内容にそのまま含まれている場合があります。サブスクリプションの原文、デコード結果、QRコード全体を公開すると、同じアクセス情報が漏れるおそれがあります。トラブル調査にはローカルのテキストツールを使い、スクリーンショットを共有する前に認証情報を隠してください。

mihomoが直接読み込める形式と、変換が必要なケース

mihomoは、Clash Metaの後継プロジェクトで使われている名称です。設定ファイルとして読み込む場合、最も明確な入力形式はmihomoの設定構造に準拠したYAMLです。完全な設定には、利用可能な出口とルーティング処理が必要です。プロキシプロバイダーファイルはメイン設定のproxy-providersから参照するもので、YAML形式だからといって完全な設定として扱えるわけではありません。

  • サービスがClash Metaまたはmihomo用の設定を提供している場合：その形式を優先し、利用中のクライアントコアがサブスクリプション内の各プロトコルやフィールドに対応しているか確認してください。
  • サービスがBase64または1行ずつのURIしか提供していない場合：まずGUIクライアントがその形式のインポートに対応しているか確認します。非対応の場合は、信頼できる変換ツールで目的の形式に変換してください。
  • プロキシプロバイダーを利用する場合：現在のmihomoバージョンが対応するプロバイダー形式を基準にしてください。ほかのペイロード形式への対応状況はバージョンによって異なる場合があります。トップレベルにproxiesを置くYAMLなら、ノードのフィールドを確認しやすくなります。
  • unsupported proxy typeが表示される場合：実際に動作しているコア、ノードの種類、クライアントのリリースノートを確認してください。ファイルの変換に成功しても、実行中のコアがそのプロトコルに対応しているとは限りません。

TUNを形式の互換性を切り替える機能と考えないでください。TUNモードは仮想ネットワークインターフェースで通信を取り込みますが、サブスクリプションの解析は設定の読み込み時に行われます。YAMLの解析エラー、未対応のノードフィールド、プロキシグループの参照漏れは、TUNを有効にしても解決しません。

完全なYAML設定とノードプロバイダー：ファイルごとの役割

以下は、構造を理解するためのmihomo設定例です。直接接続のみを設定しており、リモートのプロキシノードやアカウント情報は必要ありません。7890はこの例で使う混合プロキシポートです。すでに他のアプリが使用している場合は空いているポートに変更し、そのポートを使うアプリ側の設定も合わせて変更してください。

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

proxies: []

proxy-groups:
  - name: 出口選択
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,出口選択

proxiesには明示的に定義したノードを保存し、proxy-groupsで選択可能な出口をまとめ、rulesで接続をどの出口に渡すかを決めます。ルール内の出口選択は、プロキシグループ名と一致させる必要があります。ノード一覧だけでは、想定したプロキシグループやルーティングルールがないため、完全な設定と同じ動作にはなりません。

プロバイダーファイルはメイン設定から参照する

ノードを更新しても独自のルールを残したい場合は、ノード一覧をメイン設定から分離できます。以下は./providers/nodes.yamlを参照するローカルファイルプロバイダーの例です。メイン設定のほかの部分と組み合わせて使う必要があり、既存ファイルを置き換える完全な設定としては使えません。

proxy-providers:
  サブスクリプションノード:
    type: file
    path: ./providers/nodes.yaml

proxy-groups:
  - name: ノード選択
    type: select
    use:
      - サブスクリプションノード
    proxies:
      - DIRECT

rules:
  - MATCH,ノード選択

このローカルファイルでは、YAMLのトップレベルにproxiesリストを置き、その中に現在のコアが対応するノード定義を記述します。相対パスはコアの作業ディレクトリを基準に解決されるため、ファイルマネージャーで設定ファイルを確認できる場所と一致するとは限りません。GUIクライアントが独自のデータディレクトリを管理することもあるので、実行ログやクライアントの設定ディレクトリを開くメニューで確認してください。

useが参照するのはプロバイダー名であり、個々のノード名ではありません。ノード一覧を入れ替えてもプロバイダー名を維持すれば、メイン設定のプロキシグループやルールをノード名ごとに修正する必要はありません。HTTPプロバイダーを使う場合は、リモートURL、キャッシュパス、更新間隔も設定し、そのプロバイダーの入力形式に適したサブスクリプションか確認してください。

サブスクリプション変換で確認すべきプロトコル設定とプロキシグループ

変換ツールは通常、ノードデータを解析し、その結果を出力先の設定に組み込みます。後者の処理で、ツール既定のDNS、ルール、プロキシグループ、ポートが追加されることがあります。そのため、ノード数が同じだけでは変換が正しいとは言えません。生成された設定が実際にどう動くかも確認してください。

  1. 出力先の形式を確認する。完全な設定とノードプロバイダーの出力を区別してください。proxy-providersから読み込む場合は、プロバイダーに適した形式を選び、メイン設定全体をノードファイルとして使わないでください。
  2. 接続に必要なパラメーターを確認する。サーバーアドレス、ポート、認証情報、TLSの有効化、SNI、通信方式、WebSocketパス、Hostを一つずつ確認してください。REALITYを使うノードでは、対応する公開鍵やshort-idなどのパラメーターも保持する必要があります。
  3. 名前の参照関係を確認する。ルールの宛先、プロキシグループのメンバー、プロバイダー名が正しく対応している必要があります。ノード名を変更したら、そのノードを静的に指定しているプロキシグループも更新してください。プロキシグループ名を変更した場合は、ルールの宛先も合わせて変更します。
  4. フィルター結果を確認する。ノード名が変わると、正規表現フィルターですべてのノードが除外されることがあります。まずプロバイダー内の実際のノード数を確認し、次にプロキシグループが想定どおりのメンバーを選んでいるか確認してください。
  5. 全体設定を確認する。変換テンプレートがdns、tun、allow-lan、コントロールインターフェースを変更していないか確認してください。proxiesの項目だけを確認して終わりにしないでください。

自前の変換サービスを公開する際のアクセス制御

元のサブスクリプションURLを変換サービスに渡すと、そのサービスはサブスクリプションの内容を読み取れるようになります。自分で運用する場合はアクセス元を制限し、認証を設定してください。また、完全なリクエストURLを公開アクセスログに記録しないようにします。任意のURLを送信して取得できる仕様にする場合は、ループバックアドレス、プライベートネットワークのアドレス、クラウド環境のメタデータアドレスへのアクセスも制限してください。変換APIが内部ネットワークへのアクセス手段として悪用されるおそれがあります。

サブスクリプションURLを別のURLに埋め込む場合は、URLエンコードにも注意が必要です。元のURLに&、?、パーセント記号が含まれていると、変換APIのクエリ文字列にそのまま連結した際、1つのサブスクリプションが複数のパラメーターに分割されることがあります。ツールが用意するフォームか、適切なURL構築方法を使い、リンク全体を数文字の手作業による置換で処理しないでください。

インポートできないときの確認手順：レスポンス本文から設定検証まで

手順1：ウェブページが返されていないか確認する

クライアントのサブスクリプション更新ログを確認してください。ログインページ、CAPTCHAページ、アクセス拒否のメッセージ、HTMLタグが見つかった場合は、まずサブスクリプションの認証とサービスの応答を解決します。401や403の場合は、認証情報やアクセス制限を確認してください。429の場合は、サービスの案内に従ってリクエスト頻度を下げ、更新ボタンを連続で押さないようにします。

手順2：構造と文字を確認する

YAMLのインデントにはスペースを使い、Tabは使わないでください。リスト項目のハイフン、フィールドの後の半角コロン、正しい階層構造が重要です。コロンやシャープ記号を含むノード名は、構造やコメントと誤認されないよう引用符で囲めます。エラー行を単純に削除して直そうとしないでください。次のルールが削除した項目を参照している可能性があります。

手順3：実際に動作しているコアで検証する

mihomoを単独で実行する場合は、設定テスト用の引数を使ってファイルを検証できます。次のコマンドは、現在のディレクトリにconfig.yamlがあり、mihomoがコマンド検索パスに登録されていることを前提としています。

mihomo -t -f ./config.yaml

テストでは設定の解析エラーや一部の参照漏れを検出できますが、リモートノードが利用可能かどうかまでは確認できません。テストに通った後は、クライアントで選択中のプロキシを確認し、接続ログを見て実際に通信してください。GUIクライアントが設定に上書きを適用することもあるため、サブスクリプションをダウンロードする前のテンプレートだけでなく、最終的に有効な設定を確認します。

更新後にルールが消える場合：ノード更新とローカル設定を分ける

完全なサブスクリプション設定は、更新時に再生成されることがよくあります。ダウンロードしたファイルのrulesを直接編集すると、次回の更新でリモートの内容に上書きされる可能性があります。変更を維持するには、クライアントの上書き・マージ機能を使うのが基本です。独自のメイン設定を管理し、リモートサブスクリプションはノードの提供だけに使う方法もあります。

  • インポート後すぐ使いたい場合：サービスが明示的に提供するmihomoまたはClash Meta用の完全な設定を選び、プロキシグループとルールが目的に合っているか確認してください。
  • ローカルのルーティング設定を維持したい場合：独自のルールとプロキシグループを残したままプロバイダー経由でノードを更新するか、クライアントが対応する永続的な上書き機能を使ってください。
  • DNSやTUNを変更したい場合：最終的に有効な設定で該当フィールドを確認し、クライアント側で別途管理されていないか確かめてください。互いに上書きし合う二重の設定は避けましょう。
  • クライアントを移行する場合：サブスクリプションのURLとローカルの上書き設定を両方バックアップしてください。サブスクリプションURLだけをコピーしても、通常はローカルルール、画面上のノード選択、システムプロキシ設定は引き継がれません。

確認の順番を決めておくと、形式、インポート方法、コアの対応状況、参照関係、接続の順に切り分けられます。形式はデータを表し、プロキシグループとルールは通信を振り分け、システムプロキシとTUNは通信をコアへ渡します。各レイヤーを分けて考えることで、サブスクリプションを変換すべきか、設定を調整すべきか、ネットワーク接続を調べるべきか判断しやすくなります。

設定項目について詳しく知りたい場合は高度な設定をご覧ください。ノード、プロキシグループ、ルールの違いがわからない場合は、まず用語解説をご確認ください。サブスクリプションの元URLはアクセスを制限した場所に保管し、診断資料にはトラブルに関係するフィールドだけを残してください。

Clash をダウンロード