サブスクリプション管理 読了時間 約9分

Clash サブスクリプション形式の解説:YAML 設定、Base64 リンクと汎用サブスクリプションの相互変換方法

取得したサブスクリプションリンクをクライアントが認識できない?まず Clash YAML、Base64 ノードリスト、各プロトコル専用形式の違いを整理し、サブスクリプション変換の仕組み、よく使うパラメータ、プライバシー上の注意点を紹介します。

よく見る3種類のサブスクリプション形式の本質的な違い

サブスクリプションリンクをブラウザに貼って開いてみると、返ってくる内容の形態は決して一様ではありません。トラブルシューティングの出発点の多くは、返ってきたのがそもそもどの形式なのかを見極めずに、いきなり「クライアントが認識するはず」と思い込んでいることにあります。現在流通しているサブスクリプションの内容は大きく3種類に分けられ、それぞれ処理の仕方がまったく異なります。

  • Clash YAML 設定:レスポンス自体が完全な YAML ドキュメントであり、proxies、proxy-groups、rules などのフィールドを含み、Clash / Clash Meta / mihomo コアに直接解析されて有効になります。変換手順は一切不要です。
  • Base64 ノードリスト:レスポンスが一続きの Base64 文字列で、デコードすると vmess://、ss://、trojan:// などのプロトコル接頭辞で始まる複数行のノードリンクになります。この形式は V2Ray/V2RayN 系エコシステムで多く見られ、Clash コアはレスポンス全体をそのまま認識できないため、まずデコードしてから1件ずつ proxies エントリに変換する必要があります。
  • プロトコル専用共有リンクの生テキスト集合:Base64 でラップせずに、ノードリンクを1行ずつそのまま返す形式で、個人運営の小規模パネルによく見られます。処理方法は Base64 リストとほぼ同様ですが、デコードの手順が不要な点だけが異なります。

判定方法はシンプルです。ブラウザや curl でサブスクリプションリンクを開き、返ってきた内容の最初の行を見ます。port:、mixed-port:、proxies: のような YAML のキーと値であれば Clash ネイティブ設定です。改行のない、英数字とイコール終端で構成された長い文字列であれば、Base64 である可能性が高いです。各行がプロトコル名+:// で始まっていれば、生テキストのノードリストです。

ヒント:多くのパネルは複数形式のサブスクリプションアドレスを同時に提供しており、違いは通常 URL パラメータやパスの末尾だけです(例:?clash=1 や /clash)。認識できないサブスクリプションに遭遇したら、まずパネル側の管理画面に Clash 専用リンクが用意されていないか確認するのが、手動変換より手間が省けることが多いです。

Clash YAML 設定の主要フィールド

Clash コアが直接利用できるサブスクリプションは、大まかに以下のような骨格を持ちます。

port: 7890
socks-port: 7891
mode: rule
log-level: info

proxies:
  - name: "hk-01"
    type: ss
    server: example.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"

proxy-groups:
  - name: "auto"
    type: url-test
    proxies:
      - hk-01
    url: "http://www.gstatic.com/generate_204"
    interval: 300

rules:
  - DOMAIN-SUFFIX,google.com,auto
  - GEOIP,CN,DIRECT
  - MATCH,auto

このうち proxies はノード自体の接続パラメータを記述し、proxy-groups はノードを策略グループ(自動速度測定、手動選択、負荷分散など)にまとめ、rules はどの条件のトラフィックをどの策略グループに振り分けるかを決めます。この3つはいずれも欠かせません。もしサブスクリプションが返す YAML に proxies しかなく後の2つがない場合、多くのクライアントは自動でデフォルトの策略グループとルールを補いますが、具体的な挙動はクライアントによって異なるため、インポート後に設定ビューアで確認することをおすすめします。

Clash Meta(mihomo)コアを使用している場合は、proxies に tfo、smux、reality-opts などの拡張フィールドが含まれることもあります。これらは無印 Clash が認識しない新しいプロトコルパラメータであり、無印コアにインポートするとエラーになったり該当ノードがスキップされたりします。これは「コアを切り替えるべきか」を判断する直接的なサインでもあります。

Base64 ノードリストのデコードと変換の仕組み

Base64 形式のサブスクリプションは、本質的には「多数の共有リンクを1本のテキストにまとめて、クライアントが一括で取得・更新できるようにしたもの」であり、暗号化ではなく単なるエンコードです。デコード後の一般的なノードリンクは、次のような構造になります。

ss://[email protected]:443#hk-01
vmess://eyJ2IjoiMiIsInBzIjoiaGstMDIiLCJhZGQiOiJleGFtcGxlLmNvbSIsInBvcnQiOiI0NDMi...}
trojan://[email protected]:443?sni=example.com#hk-03

1件ずつ変換する際の考え方は決まっています。

  1. まず URL パラメータからプロトコル種別(ss / vmess / trojan / hysteria2 など)を切り分けます。
  2. ユーザー情報部分(通常これも Base64 エンコードされており、例えば ss:// のユーザー情報部分)を再度デコードして、暗号化方式とパスワードを取得します。
  3. サーバーアドレス、ポート、トランスポート層パラメータ(ws、grpc、TLS 関連フィールド)を、Clash YAML の proxies エントリに対応するフィールド名にマッピングします。
  4. ノード名(# の後ろの部分、通常 URL エンコードされている)をデコードして読める名前に戻します。

手動でこれを行うのは1件だけなら問題ありませんが、サブスクリプションには通常数十〜数百のノードが含まれるため、1件ずつ手作業で変換するのは現実的ではありません。実際の運用ではほぼすべてサブスクリプション変換サービスを使った一括変換に依存しています。次節で具体的に説明します。

サブスクリプション相互変換の2つの一般的な方法

Base64/生テキストのサブスクリプションを Clash が認識できる YAML に変換する一般的な方法は2種類あり、それぞれにトレードオフがあります。

方法1:クライアント内蔵の変換機能

一部のアンドロイドクライアントは「新規設定作成」や「サブスクリプションのインポート」の段階で形式検出ロジックを内蔵しています。リンクを貼り付けると、クライアントはまず Clash YAML として解析を試み、失敗すれば自動的に Base64 としてデコードし、1件ずつ変換してローカル設定を生成します。この方法はサードパーティサービスに依存せず、データはすべて端末内で処理されるため、プライバシーの観点では最もクリーンな方法です。ただし変換能力はクライアント自体のプロトコルフィールド対応度に依存するため、比較的新しいトランスポート層パラメータ(一部の hysteria2 の難読化パラメータなど)には変換が不完全になったり、該当ノードが直接破棄されたりすることがあります。

方法2:サブスクリプション変換サービスの中継

もう一つの方法は、元のサブスクリプションリンクを変換サービスに渡し、サーバー側でデコードと形式の書き換えを完了させ、生成された Clash YAML リンクをクライアントに登録するというものです。この種のサービスは通常カスタムパラメータをサポートしており、よく使われるものは以下の通りです。

  • target:変換先の形式。clash または clashr を指定します。
  • url:元のサブスクリプションアドレス。複数のサブスクリプションを | で区切ればまとめて処理できます。
  • config:リモートルールテンプレートのアドレス。生成される proxy-groups と rules の構造を決定します。未指定の場合は変換サービスのデフォルトテンプレートが使われます。
  • emoji / udp / tfo:真偽値パラメータで、ノード名の前に国旗の絵文字を付けるか、UDP フォワーディングや TCP Fast Open フラグを強制的に有効にするかを制御します。

この方法の利点は変換能力が高く、テンプレートを再利用できることで、複数のサブスクリプション元の命名規則を統一したり、重複を統合したりする場面に適しています。代償として、元のサブスクリプションリンク(アカウントの識別情報を含む)がサードパーティのサーバーを経由することになり、プライバシー上の露出面が生じます。利用する際は、そのサービスがログポリシーを公開しているかどうかに注意し、より慎重を期すなら、オープンソースの変換サービスを自前で構築して、中継部分を自分の管理下に置くのが望ましいです。

注意:サブスクリプションリンクには通常ユーザー固有の識別子(トークンやユーザー名・パスワード)が含まれています。サードパーティの変換サービスを経由するということは、アカウントの認証情報をそのサービスに晒すのと同じことになります。変換サービスの背景がよくわからない場合は、クライアント内蔵の変換機能やローカルにデプロイした変換ツールを優先し、サブスクリプションの原文を管理下にない第三者に渡さないようにしましょう。

変換後によく起こる不具合と対処方法

サブスクリプション変換が成功してインポートできたとしても、ノードが必ず正常に接続できるとは限りません。以下のケースは実際の運用でよく発生します。

ノード数が一致しない

変換後のノード数が元のサブスクリプションより少ない場合、多くは変換サービスやクライアントが特定のプロトコルフィールドに対応していないためにそのノードがスキップされたことが原因であり、エラーで処理が中断されるわけではありません。確認方法は、まず元の Base64 をデコードしたノードの総数を確認し、生成された YAML の proxies エントリ数と比較することです。実際に数が減っている場合は、欠落したノードのプロトコル種別が比較的マイナーなもの(一部の実験的なトランスポート層の組み合わせなど)かどうかを確認してください。変換テンプレートを変えるか、その種のプロトコルに対応した最新版のコアに更新することで解決することが多いです。

策略グループに新しいノードが表示されない

リモートルールテンプレート(config パラメータで指定したテンプレート)を使用している場合、策略グループのノード絞り込み条件はノード名のキーワードマッチで固定されています。新しいノード名がテンプレート内のキーワード規則(例えば「HK|SG|JP」で始まるノードのみを絞り込むテンプレート)に合致しない場合、自動的に対応する策略グループには振り分けられません。この場合はテンプレート内の絞り込み正規表現を確認するか、思い切ってリモートテンプレートを外し、変換サービスにデフォルトの「全ノードを1つの自動速度測定グループにまとめる」ポリシーを使わせるのがよいでしょう。

変換後に TLS/SNI パラメータが失われる

一部のプロトコル(特に Trojan や VMess の WebSocket+TLS の組み合わせ)は SNI と skip-cert-verify フィールドに敏感です。変換サービスが元のリンクの sni や allowInsecure パラメータを正しく解析できていない場合、生成されたノードは接続タイムアウトやハンドシェイク失敗になります。この場合は、生成された YAML を手動で開き、元の共有リンクのパラメータと照合して、servername と skip-cert-verify フィールドを補完・修正することをおすすめします。

更新周期の設定不備によるサブスクリプションの期限切れ

変換で生成されたサブスクリプションリンクは、本質的には「リアルタイムのプロキシリクエスト」であり、クライアントがサブスクリプションを更新するたびに、変換サービスは元のサブスクリプションを再取得して再変換します。元のサブスクリプション自体に更新頻度の制限(数時間に1回など)が設けられている場合、クライアントの更新が頻繁すぎると、元のパネルに異常なリクエストと判定されて応答を拒否され、結果として変換サービスが空のノードリストを返すことになります。クライアント側のサブスクリプション更新間隔は6〜12時間程度に設定し、手動での頻繁な更新操作は避けることをおすすめします。

形式と変換方法を選ぶ際の実用的なアドバイス

  • サービス提供者が Clash 専用のサブスクリプションリンクを直接用意している場合は、それを優先的に使用し、変換手順をすべて省いてエラーの発生確率を減らしましょう。
  • Base64/生テキストのサブスクリプションしかない場合は、まずクライアント内蔵の変換機能を試し、変換に失敗したりノードの欠落が明らかな場合にのみサードパーティの変換サービスを検討しましょう。
  • サードパーティの変換サービスを利用する場合は、可能な限りオープンソースで自前デプロイ可能なプロジェクトを選び、元のサブスクリプション認証情報を自分が管理するサーバー上で処理するようにしましょう。
  • 変換完了後は、まず url-test 策略グループで一括速度測定を行い、ノード数と遅延が正常であることを確認してから、日常使いのルールモードに切り替えましょう。
  • ルールテンプレートとノードの命名規則はできるだけ安定させ、サービス提供者がノード名の形式を変更したことで策略グループのマッチングが無効になる事態を減らしましょう。

サブスクリプション形式の変換は単なる形式変換の些細な問題に見えますが、その裏にはノード情報が複数の関係者の間をどう流れていくかという経路の問題があります。各段階でデータが誰のサーバーを経由し、どのような形で露出しているのかを把握することは、単に「リンクが使えるようになった」ことよりも、時間をかけて確認する価値があります。

クライアントをダウンロード