Clashのサブスクリプションリンク形式とは:Base64・YAMLと各クライアントの変換方法

サブスクリプションリンクとは:定期取得されるリモートノード一覧

サブスクリプションリンクは、ごく普通のHTTPSアドレスです。クライアントは一定間隔でこのアドレスにGETリクエストを送り、サーバーがテキストを返し、クライアントがそれを解析してローカルのノード一覧を更新します。仕組みとしてはRSSリーダーがフィードを取得する動作と本質的に同じで、アドレス自体は経路にすぎず、返ってくる内容の形式こそが使える/使えないを左右する要です。

まず押さえておきたい3つの前提があります。

サブスクリプションリンクはプロトコルではありません。通信の経路そのものを決めるものではなく、定期的に更新されるノード一覧を取得するためのアドレスにすぎません。
リンク内のtokenはアカウント認証情報と同等です。一般的なサブスクリプションアドレスは https://example.com/api/v1/client/subscribe?token=xxxxxxxx のような形式で、この文字列が身分証明そのものです。第三者に渡ると契約中の通信量を勝手に使われてしまうため、漏えいが疑われたら、まずサービス提供元の管理画面でサブスクリプションリンクを再発行しましょう。
同じアドレスでも複数の形式を返す場合があります。サーバー側がリクエストヘッダーのUser-AgentやURLパラメータからクライアントの種類を判別し、Base64形式のリストとClash YAMLを使い分けて返す実装は珍しくありません。これが「1本のリンクで複数クライアントに対応」できる仕組みの正体です。

Base64形式のサブスクリプション:ノード共有リンクの一覧

Base64形式のサブスクリプションは、V2Ray系のツールが広めた汎用的な交換形式です。サーバーはBase64エンコードされた1つの長いテキストを返し、デコードすると1行ごとに1つのノード共有リンクが並びます。例:

ss://[email protected]:8388#HK-01
vmess://eyJ2IjoiMiIsInBzIjoiSEstMDIifQ==
trojan://p%[email protected]:443?sni=cdn.example.com#HK-03

各行には接続に必要な情報がすべて含まれています。プロトコル名、アドレス、ポート、認証情報、トランスポート層やTLSのパラメータ、そして#以降に表示名が入ります。よく使われる接頭辞の意味は次の通りです。

ss:// —— Shadowsocks。SIP002規格に準拠し、@より前の部分はmethod:passwordをBase64化したものです。
vmess:// —— VMess。全体が1つのJSONオブジェクトをBase64化したものです。
vless:// —— VLESS。パラメータはクエリ文字列で指定されます。
trojan:// —— Trojan。パスワードはuserinfo部分に格納されます。
hysteria2://(またはhy2://)、tuic:// —— QUICベースのプロトコルで、mihomoなど新しめのコアでのみ対応しています。

この形式はクライアントを問わず汎用的に使え、ノード単位で独立しているため1件だけ共有することもできます。ただし、振り分けルールやポリシーグループの情報は含まれないため、インポート後はクライアント側でルールを補う必要があります。もう1つ注意したいのがssr://(ShadowsocksR)で、これはClashやmihomoの対応プロトコルには含まれていません。SSRノードが混在するサブスクリプションをインポートすると該当ノードは無条件に無視されるので、ノード数が合わない場合はまずこれを確認してください。

Clash YAML:ノード・ポリシーグループ・ルールが一体化した形式

Clashのネイティブなサブスクリプション形式は、YAML形式の完全な設定ファイルで、少なくとも次の3つのトップレベル項目を含みます。

mixed-port: 7890
allow-lan: false
mode: rule
proxies:
  - name: "HK-01"
    type: ss
    server: 203.0.113.10
    port: 8388
    cipher: aes-256-gcm
    password: "password"
proxy-groups:
  - name: "自動選択"
    type: url-test
    proxies: ["HK-01"]
    url: http://www.gstatic.com/generate_204
    interval: 300
rules:
  - GEOIP,CN,DIRECT
  - MATCH,自動選択

proxies:ノードの一覧。項目はBase64共有リンクとほぼ1対1で対応しており、書式がYAMLに変わっただけです。
proxy-groups:ポリシーグループ。手動選択のselect、自動速度測定のurl-test、負荷分散のload-balance、フェイルオーバーのfallbackなどが代表的なタイプです。
rules:振り分けルール。ドメイン、IPレンジ、GEOIPなどの条件に応じて、直接接続・プロキシ経由・拒否のいずれかに通信を振り分けます。

YAML形式のサブスクリプションを取得すれば、ノード・グループ・ルールがそろった、そのまま使える完全な設定を手に入れたことになります。その代わり形式がClash系に固定されるため、他系統のクライアントでは読み込めません。コアの違いにも注意が必要です。mihomo(Clash Meta)はvless、hysteria2、tuic、wireguardなどの新しいノード形式に対応していますが、開発が終了した旧Clashコアでは未知のノード形式に対して解析エラーになったり、そのノードだけスキップされたりします。

各クライアントが直接インポートできるサブスクリプション形式一覧

以下は、本サイトで紹介しているクライアントがコアの種類別に直接インポートできるサブスクリプション形式をまとめた表です。

クライアント	コア	直接インポートできるサブスクリプション形式
Clash Verge Rev	mihomo	Clash YAML、Base64共有リンク
Clash Plus	mihomo	Clash YAML、Base64共有リンク
FlClash	mihomo	Clash YAML、Base64共有リンク
ClashX Meta	mihomo	Clash YAML、Base64共有リンク
Clash for Android	Clash(開発終了)	Clash YAML
Clash for Windows	Clash Premium(開発終了)	Clash YAML
Surfboard	Surge互換	Surge形式の設定

規則はシンプルです。mihomoコアのクライアントは両方の形式に対応しており、Base64形式のサブスクリプションをインポートする際は、内部で各共有リンクをproxies項目として解析し、デフォルトのポリシーグループとルールを自動的に付与します。一方、旧Clashコアが読めるのはYAMLのみで、SurfboardはSurgeの設定体系を使うため、Clashのサブスクリプションは事前に変換が必要です。つまり、サブスクリプションがBase64形式しか提供されていない場合は、mihomoコアのクライアントを選べば変換の手間を省けます。

形式を相互変換する3つの方法

方法1:サブスクリプションコンバーター(オンラインまたは自前運用)

サブスクリプションコンバーターは中間サービスの一種です。元のサブスクリプションアドレスを渡すとノード一覧を取得し、指定した出力形式に再構成して返してくれます。変換後のアドレスは一般的に次のような形になります。

https://sub.example.com/sub?target=clash&url=元のサブスクリプションURLをエンコードしたもの&config=ルールテンプレート

targetパラメータで出力形式(clash、surge、quanxなど)を指定し、configパラメータで追加のルールテンプレートを指定します。コンバーターを使えば、形式の非対応問題とBase64形式にルールが含まれない問題の両方を同時に解決できます。

公開されている変換サービスを使う際の認証情報リスク

サブスクリプションアドレスを第三者のコンバーターに渡すことは、tokenを平文でそのサーバーに渡すのと同じ意味を持ちます。相手はあなたの全ノード情報と使用量を把握できてしまいます。重要な契約を使っている場合は、自前でコンバーターのバックエンド(オープンソースのsubconverterはセルフホスト可能)を運用するか、直接インポート対応のmihomo系クライアントを使って中間サービスを介さない方法をおすすめします。

方法2:クライアント内蔵の解析機能を使う

Clash Verge Rev、Clash Plus、FlClashなどmihomo系クライアントでは、新規サブスクリプション追加時にBase64形式のアドレスをそのまま貼り付けるだけで済みます。コアが内容を自動判別して変換まで完了するため、外部ツールは一切不要です。現時点で最も手間がかからない方法であり、初めての方にはこの方式をおすすめします。

方法3:手動でデコード・書き換えする

トラブルの調査や一部のノードだけ扱いたい場合は、手動処理が有効です。Base64形式のサブスクリプションのデコードはコマンド1行で済みます。

curl -s "サブスクリプションアドレス" | base64 -d

デコード後、各行のノードリンクを確認し、プロトコル接頭辞がコアの対応リストに含まれているかチェックします。YAML形式に変換したい場合は、前節のproxies項目の書式に沿って1件ずつ書き写せば十分です。ノード数が少ないなら、コンバーターを構築するより手動で処理する方が早いこともあります。

インポート失敗時の切り分け手順

サブスクリプションのインポートでエラーが出たり、ノードが0件になったりした場合は、次の順序で確認していくと原因を特定しやすいです(該当率が高い順)。

まずブラウザでサブスクリプションアドレスを直接開いてみます。テキストが返ってくればリンク自体は有効です。401/403が返る場合はtokenの失効、404が返る場合はパスの変更が原因なので、いずれもサービス提供元の管理画面で再取得が必要です。
返ってきた内容の形式を確認します。ブラウザ上で空白のない長い暗号文のような文字列が見えたらBase64、proxiesやrulesといったキーが見えたらYAMLです。クライアントの対応形式と一致しない場合は変換が必要です。
ノードのプロトコルがコアに対応しているか確認します。ssr://を含むサブスクリプションはClash系ではそのノードが無視されます。hysteria2やtuicを含むものはmihomoコアでしか認識できません。
ローカルのネットワーク環境を確認します。サブスクリプションアドレス自体がブロックされている場合、取得するにはまず別の有効なプロキシが必要です。クライアントの「システムプロキシ経由でサブスクリプションを更新」といった設定を有効にするか、まず手動で1つノードを追加して急場をつなぐ方法もあります。
YAMLの文法を確認します。手動編集した設定でよくあるミスは、インデントの誤り、全角コロンの混入、未エスケープの特殊文字などです。クライアントのログにエラー行番号が表示されることが多いので、そこから当たりましょう。

サブスクリプションリンクの安全管理と日常メンテナンス

サブスクリプションアドレスはパスワードと同等に扱いましょう。グループチャットで共有したり、スクリーンショットで外部に流したり、出所不明のオンライン変換サイトに入力したりしないでください。
漏えいした場合は即座に再発行します。サービス提供元の管理画面には通常「サブスクリプションリンクを再発行」ボタンが用意されており、再発行すると旧アドレスは即時無効になります。各クライアントに登録しているサブスクリプションアドレスも忘れずに更新してください。
更新間隔を短くしすぎる必要はありません。ノード一覧の変化はそれほど頻繁ではないため、クライアントのデフォルトである24時間や12時間で十分です。頻繁な取得はサーバーへの負荷を増やすだけで、提供元によってはアクセス制限がかかる場合もあります。
複数クライアントで1本のサブスクリプションを共有する場合は形式に注意してください。mihomo系クライアントと旧コアのクライアントを併用する場合、サーバーがClash YAMLを出力できることが前提となります。それができない場合、旧コア側は別途変換用アドレスを用意する必要があります。

判断の流れをまとめると、まずサブスクリプションアドレスを取得したら返ってきた内容の形式を確認し、Base64形式ならmihomo系クライアントで直接インポートするかコンバーターを使い、Clash YAMLならClash系クライアント全般で問題なく利用でき、Surge系クライアントの場合は別途変換が必要です。形式の問題が解決したら、残るは通常の振り分けルールやポリシーグループの調整だけです。この部分は本サイトの設定ガイドを参照しながら1つずつ設定していけます。