Clashのサブスクリプション形式を解説｜YAML設定・Base64リンク・SIP008の変換方法

まずサブスクリプションの応答内容を確認し、変換が必要か判断する

「サブスクリプションURL」とは、クライアントが指定したアドレスからデータを取得する仕組みを指します。取得できる内容が必ずClashの設定とは限りません。同じHTTPSアドレスでも、完全なYAML、Base64でエンコードされたノード一覧、SIP008 JSON、あるいはログインページが返される場合があります。インポートに失敗したら、拡張子を変えて試すより先に、応答本文を確認しましょう。

次の3つは区別が必要です。サブスクリプションURLはデータ取得先、YAML・JSON・Base64はデータの構造やエンコード方式、Shadowsocks・Trojan・VLESSなどはノードが使用するプロキシプロトコルです。Base64をデコードしても、Shadowsocksノードが別のプロトコルに変わるわけではなく、ルールによる振り分けが自動生成されることもありません。

内容の種類	見分けるポイント	Clashへのインポート方法
完全なYAML設定	一般的な項目は `proxies:`、`proxy-groups:`、`rules:`	対象カーネルとの互換性を確認して設定としてインポート
ノードのみのYAML	主に `proxies:` を含み、ポリシーグループやルールがない	ノードソースとして使うか、設定の不足部分を補う
Base64形式のノードサブスクリプション	エンコードされたテキスト。デコードすると、複数行の `ss://` などのリンクが見つかることが多い	ノードを解析してYAML設定を生成
SIP008 JSON	一般的な項目は `version` と `servers`	Shadowsocksサーバーの各項目をノードに変換
HTMLまたは不正なJSON	ログイン要求、アクセス拒否、利用枠に関するエラー	まずサブスクリプションへのアクセスを復旧する。変換では解決できない

ClashのYAML設定：ノード・ポリシーグループ・ルールの関係

Clash系カーネルでは、実行設定をYAMLで記述します。ノードはリモートサーバーへの接続を担い、ポリシーグループは複数のノードを手動選択・自動遅延測定・自動切り替えなどの入口としてまとめます。ルールは接続先に順番に照合され、通信を指定したポリシーに振り分けます。待ち受けポート、DNS、TUNはローカルネットワークの接続設定です。

完全な設定はノード一覧とは異なる

proxies にノードがあっても、通信で使われるとは限りません。最終ルールが MATCH,DIRECT のままなら、先行ルールに一致しない通信は直接接続されます。存在しないポリシーグループをルールが参照していると、設定を読み込めない場合があります。サブスクリプション変換ではノード名とポリシー参照の両方を処理する必要があり、テキストをいくつか連結するだけでは不十分です。

以下は設定構造を理解するための直結サンプルで、リモートプロキシノードは含みません。待ち受けポートは 7890 で、接続を許可するのはローカルホストのみです。すべての通信を「出口選択」に渡しますが、グループ内にあるのは DIRECT だけです。リモートノードの接続確認には使えません。

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

proxies: []

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

rules:
  - MATCH,出口選択

YAMLの構文とカーネルの対応状況は別々に確認する

インデントにはスペースを使い、Tabは使いません。同じ階層のインデント幅をそろえます。以下の例では半角スペース2つです。
ノード名、パスワード、特殊記号を含む文字列は、別の型として解釈されないよう引用符で囲むのがおすすめです。
YAMLを解析できても、確認できるのは構文が正しいことだけです。プロトコルの種類、トランスポート設定、ポリシーグループのオプションが対象カーネルに対応しているかも確認してください。
従来のClashとClash Meta（現mihomo）では、対応範囲が異なります。VLESSやHysteria2などのノードを使う場合は、対象カーネルのドキュメントを確認してください。クライアント名だけでは互換性を判断できません。

Base64形式のサブスクリプション：デコードで復元できるのはテキストだけ

一般的なBase64形式のサブスクリプションでは、複数の共有リンクを1行ずつ並べたテキスト全体をエンコードします。デコードすると、ss://、trojan://、vmess://、vless:// などが見つかることがあります。各リンクはそれぞれ異なる項目ルールを持つため、変換ツールは1件ずつ判別する必要があります。

外側と内側の2段階でエンコードされている場合もあります。外側はサブスクリプション一覧のBase64、内側は個々の共有リンクに含まれるエンコードデータです。たとえば、一部のShadowsocksリンクでは認証情報がエンコードされ、一般的なVMess共有リンクではJSONがBase64で格納されています。外側だけをデコードしても、ノード情報をすべて読めるとは限りません。

ローカル環境でサブスクリプションの内容を確認する

サブスクリプションの応答を subscription.txt に保存すれば、ローカル環境でデコードできます。以下のコマンドは、一般的な標準Base64テキストを対象としています。出力ファイルにはノードの認証情報が含まれるため、個人用ディレクトリに保存し、公開リポジトリにはアップロードしないでください。

# Linux：GNU coreutils
base64 --decode subscription.txt > nodes.txt

# macOS
base64 -D -i subscription.txt -o nodes.txt

エンコードが無効だと表示されたら、まずダウンロードした内容がHTMLではないか、URLセーフ文字を使っていないか、パディングが欠けていないか、余分なデータが付いていないかを確認してください。エラーをすべて「サブスクリプションの破損」と決めつける必要はありません。変換ツールによってはこうした形式に対応していますが、対応状況は実装によって異なります。

SIP008：Shadowsocksサーバー用のJSONサブスクリプション

SIP008はShadowsocksエコシステムにおけるサブスクリプション形式の取り決めであり、汎用プロキシプロトコルでもClash設定でもありません。JSONではサーバーの配列でノードを記述し、サーバーアドレス、ポート、暗号化方式、パスワードなどの項目を使用します。標準形式で複数のShadowsocksサーバーを記述できますが、Clashのポリシーグループや振り分けルールが付加されるわけではありません。

以下では、項目の関係を示すために予約済みの例示用ドメイン名を使用しています。パスワードも構造説明用であり、接続可能なサービスのものではありません。実際に変換する際は、サービス提供元の認証情報をそのまま保持してください。

{
  "version": 1,
  "servers": [
    {
      "id": "80a3cf64-dcec-4ca9-bd7b-b69b9763ca15",
      "remarks": "SS サンプルノード",
      "server": "edge.example.com",
      "server_port": 443,
      "password": "demo-password-not-for-use",
      "method": "aes-128-gcm"
    }
  ]
}

SIP008からClashへの項目マッピング

remarks は通常、Clashノードの name として使います。名前が重複する場合は重複を解消し、ポリシーグループ内の参照も合わせて変更してください。
server はサーバーアドレスとして保持し、server_port は port に対応させます。
method は cipher に対応させ、password は認証パスワードとして保持し、type: ss を設定します。
元データに plugin と plugin_opts が含まれる場合は、対象カーネルがプラグインとそのパラメーター形式に対応しているか確認してください。Clashの項目としてそのままコピーすることはできません。

サービスによっては、独自JSONや旧式の配列を返す場合があり、上記の構造に完全には準拠しません。変換ツールに「SIP008対応」と記載されていても、すべての形式に対応するとは限りません。「利用可能なノードがありません」と表示されたら、同じインポート操作を繰り返すのではなく、応答の最上位構造と必須項目を確認してください。

サブスクリプションの変換手順：元の応答から完全なYAML設定を作成

配信元が提供する対象形式を優先する

サブスクリプション管理画面にClashまたはmihomo専用の項目がある場合は、まずそちらを使ってください。中間の変換処理を減らし、サービス提供元が設定したノードパラメーターを保持しやすくなります。同じサブスクリプションURLでも、リクエストパラメーターやUser-Agentに応じて異なる形式が返されることがあります。そのため、ブラウザーで確認した内容とクライアントが取得する内容が一致するとは限りません。

変換が必要な場合は、次の5ステップで進める

対象カーネルを確認する。まずクライアントの「バージョン情報」やカーネル情報で、従来のClashとmihomoのどちらを使っているか確認します。画面上の操作手順はクライアントによって異なるため、実際の表示を確認し、クライアントの名称からカーネルを推測しないでください。
元の形式を判別する。応答の冒頭と構造を確認し、YAML、Base64、SIP008、エラーページを見分けます。比較用に元ファイルを残し、現在使用中の設定を直接上書きしないでください。
変換を実行する環境を選ぶ。信頼できるローカルツール、または自分で構築したサービスを優先してください。Webフォームだからといってローカル処理とは限りません。フォームからサブスクリプションURLがバックエンドに送信される場合、バックエンドが内容を取得できます。
出力テンプレートを選ぶ。出力が完全な設定なのか、ノードのみのproviderファイルなのか確認してください。ポリシーグループ、ルール、DNS設定が用途に合っているか確認し、別のカーネル向けテンプレートを安易に流用しないでください。
保存・検証・試運転を行う。出力をYAMLファイルとして別名保存し、対象カーネルでテストしてからクライアントにインポートします。古い設定を残しておき、接続と更新が正常に動作することを確認してから、普段使いの設定に切り替えてください。

変換ツールの「Clash」と「Clash Meta」向けの選択肢では、シリアライズできる内容が異なる場合があります。従来のClash向けを選ぶと、新しいプロトコルやトランスポート設定が失われることがあります。mihomo向けを選んでも、従来のカーネルが新しい項目を解釈できるようにはなりません。出力形式は実際に動作するカーネルに合わせてください。

インポート前に確認すること：項目の保持、設定テスト、実際の接続

「ファイルの生成に成功」しても「接続に成功」したとは限りません。確認は3段階で行います。まず構文と設定の参照関係、次にノードのハンドシェイク、最後にルールの一致と接続先サイトへのアクセスを確認します。これにより、解析エラー、認証エラー、振り分けエラーを切り分けられます。

対象カーネルで設定をテストする

mihomoのコマンドラインプログラムをインストールしている場合は、変換後の設定をテストできます。コマンド内の converted.yaml は、ローカルに保存した出力ファイル名です。カレントディレクトリ以外にある場合は、実際のファイルパスを指定してください。

mihomo -t -f ./converted.yaml

設定テストでは外部のproviderやルールリソースを読み込むことがあり、実行環境によって結果が変わる場合もあります。テストに通っても、今回の検証で読み込みを妨げる問題が見つからなかったという意味にとどまります。サーバー認証の成功や、すべてのサイトへのアクセスを保証するものではありません。

失われやすいパラメーターを項目ごとに確認する

アドレスとポート：server と port が正しく設定されているか確認します。ポートが 443 でも、TLSが有効とは限りません。
認証情報：パスワード、UUID、暗号化方式など、プロトコルに必要な情報を確認します。エスケープ処理やURLデコードが正しいかにも注意してください。
TLSとトランスポート：SNI、証明書検証、ALPN、WebSocketのパスやHostなどを確認します。パラメーターの誤りを隠すために証明書検証を無効にしないでください。
ノードの参照：ポリシーグループが参照するノード名が存在することを確認します。ノード名を変更した場合は、参照先も合わせて修正してください。
ローカルの待ち受け：例にある 7890 はローカルプロキシのポートであり、リモートサーバーのポートではありません。すでに別のプロセスが使用している場合は、クライアントとアプリのプロキシ設定を合わせて変更してください。

インポート後はノードを1つ手動で選び、接続ログに表示される接続先、一致したルール、出口ポリシーを確認します。ログが DIRECT を示す場合は、まずルールが通信をプロキシグループに渡しているか確認してください。ノードに一致しているのにハンドシェイクが失敗する場合は、プロトコルパラメーターとサーバーへの接続性を調べます。

継続的な更新：完全な設定とproxy-providersを分けて管理する

一度だけ変換してローカルにYAMLとして保存すると、その時点の内容のスナップショットになります。サービス提供元がノードを追加したり、パスワードを変更したり、接続先を削除したりしても、ローカルファイルには自動で反映されません。新しい内容を取得するには、有効なリモート更新経路が設定されている必要があります。

一般的な方法は2つあります。クライアントでリモートの完全な設定を定期更新する方法と、メイン設定にポリシーグループやルールを保持し、proxy-providers でノードを更新する方法です。後者はローカルの振り分けロジックを固定したい場合に適していますが、provider、ポリシーグループの use 参照、更新間隔を正しく設定する必要があります。

任意のサブスクリプションURLをそのままproviderとして使わない

一般的なYAMLノードproviderでは、proxies: の下にノードを並べた内容が必要です。完全な設定、Base64リスト、SIP008 JSONは、確認せずに互換形式として扱うことはできません。mihomoのprovider対応状況はカーネルの実装によって異なるため、他の形式を使う場合はドキュメントとテスト結果を確認してください。

たとえば更新間隔を 3600 秒に設定すると、1時間ごとに更新を試みますが、毎回成功する保証はありません。URLの無効化、ネットワーク接続の問題、変換サービスの障害が起きた場合は、更新ログとローカルキャッシュを確認してください。タイマーが有効なだけでノードが最新だと判断しないでください。

よくある質問：インポートエラー、ノード不足、認証情報の保護

YAMLの解析に失敗した場合、まずどこを確認する？

まずファイルの冒頭を確認し、HTMLやJSONのエラー、デコード前のテキストになっていないか調べます。そのうえでエラー行を手がかりに、インデント、引用符、コロンを確認してください。HTTPリクエストが200を返してもログインページが含まれている場合があります。ステータスコードだけでは設定を取得できたか判断できません。

変換後にノード数が減った。正常なフィルタリング？

すぐに正常だとは判断できません。まず地域や名前による絞り込み条件を確認し、次に対象形式がすべてのプロトコルに対応しているかを調べます。その後、重複名の処理、プラグインパラメーター、解析失敗のログを確認してください。ノード数の減少は明示的な絞り込みの可能性もあれば、変換機能の不足による可能性もあります。元データと照合して原因を特定しましょう。

ノードの共有リンク1つだけでサブスクリプションとして使える？

共有リンク1つで記述されるのは通常1つのノードだけで、リモート更新の仕組みは含まれません。一部のクライアントでは単一ノードを追加できますが、完全な設定のインポートとは異なります。ルールで通信を振り分けるには、そのノードをポリシーグループとルールに追加する必要があります。

サブスクリプションURLを第三者に送ってしまった場合の対処法は？

サービス提供元の管理画面で元のサブスクリプショントークンを再発行または無効化し、クライアントに保存したURLを更新してください。公開された記録に機密情報が含まれていれば削除します。ローカルの変換ファイルを削除するだけでは、漏えいしたアクセス権を取り消せません。ノードのパスワードも変更すべきかは、サービス提供元の認証情報の仕組みに応じて判断してください。

実際の作業は4項目に整理できます。入力形式を確認する、カーネルに合った出力形式を選ぶ、最終的に適用される設定をテストする、サブスクリプションの認証情報を保護する。この4つを確実に行ってからルールテンプレートや更新方法を調整すれば、トラブルの原因を絞り込みやすくなります。