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

URLの末尾ではなく、まず配信される内容を確認

サブスクリプションURLは、クライアントがデータを取得するためのアドレスです。URL自体が設定形式を示すわけではありません。https://で始まる同じURLでも、Clashでそのまま読み込めるYAMLが返る場合もあれば、Base64の長いテキストが返る場合もあります。ログイン画面やエラーメッセージが表示されることもあります。クライアントへのインポートに失敗したら、サブスクリプション名を何度も変更するより、「URLにアクセスできない」のか「返された内容がインポート先の形式に対応していない」のかを先に切り分けましょう。

よく見かけるのは、完全なYAML設定、エンコードされたノードリスト、ss://などの単一ノード共有リンクの3種類です。それぞれ提供できる情報の範囲が異なるため、「どれにもノードが含まれている」というだけで同じ設定形式とはいえません。特にプロキシグループとルールは重要です。ノードリストが示すのは接続可能なプロキシで、完全な設定には通信をどのプロキシへ振り分けるかも記述されています。

完全なYAML設定：ノードだけでなく通信経路も設定

Clashの設定ファイルには、.yamlまたは.ymlの拡張子がよく使われます。ファイル内のproxiesはノード、proxy-groupsは手動選択や自動テストなどを行うプロキシグループ、rulesはルールモードでの振り分け先を定義します。mixed-portなどの項目では、ローカルの待ち受けポートを設定します。YAMLではインデントで階層を表すため、リスト項目のハイフンや各項目の階層が解析結果に影響します。

以下は構造を示す最小限の例です。127.0.0.1:1080は、ローカル環境ですでに稼働しているSOCKS5上流サーバーを表します。該当するサービスがなければ、この例だけでは外部に接続できません。7890はこの設定例で使うローカルの混合ポートであり、すべてのクライアントで固定されているわけではありません。

mixed-port: 7890
mode: rule

proxies:
  - name: ローカルデモ
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - ローカルデモ
      - DIRECT

rules:
  - MATCH,手動選択

ルールモードでは、例のMATCHが他のルールに一致しなかった接続を「手動選択」グループに振り分けます。グループ内でDIRECTを選ぶと、その接続はプロキシを経由せずに通信します。実際の設定を読み込んだら、ノード一覧に表示されるかだけでなく、クライアントに表示されるプロキシグループとルールの数も確認してください。設定でproxy-providersを使う場合は、プロバイダーのURLから更新できることに加え、使用中のクライアントとそのコアが設定内の項目に対応しているかも確認しましょう。

「YAML」はファイルの記述形式を示すだけで、実行可能な完全設定であることを保証しません。たとえばproxies:だけを含むYAMLのノード一覧は、プロキシプロバイダーから参照する用途には使えても、単独では通信を振り分けられない場合があります。反対に、DNS、ルール、プロキシグループを含む完全な設定なら、ファイル名に.yamlが付いていなくても、クライアントがYAMLとして読み込み、内容に問題がなければ使えることがあります。

Base64ノードリスト：まずデコードしてプロトコルを確認

Base64はテキストのエンコード方式であり、プロキシプロトコルではありません。一般的なBase64形式のサブスクリプションでは、複数の共有リンクを1行ずつ並べたテキスト全体をエンコードしています。デコード後は各行のプロトコル接頭辞とパラメーターを確認してください。エンコードされた長い文字列をそのままconfig.yamlに貼り付けても読み込めません。また、エンコード文字列をproxies:の下に置いても、YAMLのノード設定には自動変換されません。

この形式のリストには通常、サーバー、ポート、認証パラメーター、ノード名が含まれますが、Clashのproxy-groups、rules、ローカルのmixed-port設定は含まれません。クライアントに専用の「ノードサブスクリプション」機能があれば、リストをノードとして解析し、既存設定に追加できることがあります。「設定をインポート」する機能しかない場合は、対応するClash設定を用意するか、ローカルで形式を変換してプロキシグループとルールを補う必要があります。機能名は使用中のクライアントの画面で確認してください。

• 先頭がproxies:の場合：YAMLとして、インデント、項目、使用するコアとの互換性を確認します。
• エンコードされた長い文字列の場合：まずBase64テキストかどうかを確かめ、デコード後の各行を確認します。URLのファイル名だけで判断しないでください。
• デコード後にss://などのリンクが複数行に並ぶ場合：これはノードリストであり、そのまま使える通信ルール付き設定ではありません。
• HTMLやログイン案内が返る場合：サブスクリプションへのアクセス、ログイン状態、URLの有効期限を確認してください。拡張子を変えても返される内容は変わりません。

紛らわしいケースとして、単一の共有リンク内に一部のパラメーターがエンコードされていることがあります。それでも表しているのは1つのノードだけで、Base64文字が含まれているからといって「Base64形式のサブスクリプション」とは限りません。最初に、複数行のエンコード済みリストなのか、プロトコル接頭辞の付いた1件の共有リンクなのか、全体の形式を確認しましょう。

単一ノードのリンク：接続情報を共有できても、完全なサブスクリプションの代わりにはならない

ss://、vmess://、trojan://などの接頭辞は、プロトコルごとの共有リンクを示します。通常、1つのリンクが表すのは1つのノードです。クリップボードからリンクを認識してインポートできるクライアントでも、そのノードをどのプロキシグループに入れるか、どのドメインを直接接続にするか、DNSをどう設定するかまでは判断できません。ノードを手動追加した後は、使用中の設定でプロキシグループから参照されているか確認してください。

プロトコル接頭辞から種類は判断できますが、互換性まで保証されるわけではありません。オリジナルのClashとClash Meta（mihomo）では、対応するプロトコルや設定項目が異なります。たとえばvless://リンクがあっても、オリジナルのClashでそのまま使えるとは限りません。mihomoを使う場合も、実際のコアのバージョン、プロトコルパラメーター、クライアントのインポート機能を確認しましょう。クライアントが「共有リンクを認識しない」問題と、コアが「変換後のノード項目に対応していない」問題は別の段階です。切り分けのため、それぞれのエラーを記録してください。

形式を変換する：項目を保ち、通信経路の設定を補う

変換は、.txtを.yamlに名前変更するだけではありません。ノードリストからClash設定に変換する場合、各共有リンクを対応するproxiesオブジェクトに変換する必要があります。その後、プロキシグループ名、ノードの所属先、rulesの設定を決めます。完全なYAML設定からノードリストを出力する場合は、情報を削る方向の変換です。プロキシグループ、ルール、DNS設定、ローカルポートは通常、単一ノードのリンクには引き継がれません。

変換前に確認する4つの項目

1. プロトコル項目：サーバー、ポート、認証方式に加え、プロトコルで必要となる通信方式やTLSのパラメーターを確認します。項目が1つ欠けただけでも、「ノードは表示されるのに接続できない」ことがあります。
2. ノード名：変換後に名前が重複していないか確認します。プロキシグループがノード名を参照する場合、重複や変更によって意図したノードが選ばれなくなることがあります。
3. グループとルール：変換後の設定にproxy-groupsとrulesが含まれているか確認します。proxiesしか生成されていない場合は、完全な設定ではなくノード一覧として扱ってください。
4. 使用するコア：実行するClashまたはmihomoに合わせて出力形式を選びます。変換ツールが項目を生成できても、使用中のコアで解析・利用できるとは限りません。

定期的に更新する場合は、「一度だけ変換したファイル」と「サブスクリプションに合わせて更新される設定」を区別しましょう。サブスクリプションの内容をローカルYAMLにコピーした場合、保存されるのはその時点のノード情報です。上流でノードや認証情報が変更されても、ローカルファイルは自動更新されません。クライアントのURL設定更新機能を使う場合は、更新後も必要なプロキシグループとルールが保たれているか確認してください。プロキシプロバイダーを使う場合は、更新結果と、それを参照するプロキシグループも確認しましょう。

変換結果は3段階で確認できます。まずYAMLをクライアントに読み込めるか、次にプロキシグループに想定したノードが表示されるか、最後にルールモードで実際の通信経路を確認します。読み込みに成功したということは、現在のクライアントで設定を解析できたというだけで、ノードのパラメーター、上流サービス、ルールの結果がすべて正しいとは限りません。テスト前に選択中のグループメンバーを記録し、テスト後に接続ログと照合すれば、DIRECTの選択間違いをサブスクリプションの障害と取り違えずに済みます。

インポートに失敗したら、内容・解析・接続の順に確認

第1段階：内容を取得できているか

クライアントの「設定」画面からURLをインポートするときは、URLが完全か、アカウントにアクセス権があるか、更新時にネットワークエラーが出ていないかを確認します。ブラウザーでページを開けても、クライアントのリクエストで同じ設定内容が返るとは限りません。ログインページ、リダイレクト先の案内、期限切れの通知はYAMLではありません。診断時は返された内容の冒頭を確認し、スクリーンショットにサブスクリプションURLのトークンが写らないようにしてください。

第2段階：想定した形式として解析できるか

YAMLエラーが表示されたら、インデントにタブが混ざっていないか、コロンの後にスペースがあるか、リスト項目が正しい階層にあるかを確認します。インポート後にノードだけが表示され、ルールやプロキシグループがない場合は、元の内容がノードリストではなかったか確認してください。未対応のプロトコルや項目のエラーが出たら、クライアントのバージョンとコア名を記録し、サブスクリプションの対象形式と照らし合わせます。ファイル名を何度も変更しても、コアとの互換性は解決しません。

第3段階：ノードと通信経路が機能しているか

ノードが表示されたら、まず現在のプロキシグループに追加されているか確認し、次にルールモードでの振り分け結果をチェックします。システムプロキシは通常、システムプロキシ設定を使うアプリの通信を処理します。それ以外の通信を処理するため、一部のクライアントにはTUNモードがありますが、TUNの権限、DNS、ルーティング設定は別の設定項目です。サブスクリプション形式を変換しても自動では補われません。ノードに接続できてもアプリの通信が想定したプロキシグループを通らない場合は、クライアントのモード、システムプロキシまたはTUNの状態、実際に適用されたルールをそれぞれ確認してください。

形式の選び方はシンプルです。読み込んですぐ通信ルールを使いたい場合は、使用するコアに合った完全なYAML設定を入手します。既存設定に複数のノードを追加するだけなら、クライアントが対応するノードリストやプロキシプロバダーの機能を使います。接続情報を1つだけ共有するなら、対応プロトコルの単一ノードリンクを使います。まず内容の種類を確認してからインポート方法を選び、最後にグループ、ルール、接続結果をチェックすれば、形式の問題とネットワークの問題を分けて対応できます。