選び方の参考 読了目安 12分

Clashのサブスクリプション形式を解説：base64・YAML・汎用形式の違いと変換方法

Clash YAML、base64共有リンク、汎用サブスクリプションの構造上の違い、各クライアントの互換性、変換時に注意したい設定項目の欠落について解説します。

エンコード・リンク・設定ファイルをまず区別する

「Clashのサブスクリプション」は単一の形式ではありません。サーバーから返される内容は、Clash YAML一式の場合もあれば、複数の共有リンクを並べたテキストにbase64エンコードを施したものの場合もあります。どれもURLからインポートできますが、クライアントがレスポンスを受け取った後の解析経路は異なります。

最も混同されやすいのがbase64です。これはバイト列を印字可能な文字へ変換するエンコード方式にすぎず、ノードの項目や対応プロトコルを定義するものではありません。ss://、trojan://、vmess://などのリンクを1行ずつ並べ、テキスト全体をbase64エンコードしたものが、一般に「base64サブスクリプション」と呼ばれます。デコード後に意味を持つのは、個々の共有リンクです。

Clash YAMLは階層構造を持つ設定ファイルです。ノードだけでなく、プロキシグループ、ルール、DNS、待受ポート、ルールプロバイダー、TUN設定まで含められます。汎用サブスクリプションは通常ノードの受け渡しに特化し、グループ構成や通信の振り分けはクライアント側のテンプレートや変換ツールで補います。

形式 代表的な冒頭・構造 表現できる内容 主な用途
Clash YAML proxies:、proxy-groups: ノード、プロキシグループ、ルール、DNS、TUNなど Clashまたはmihomoの設定として直接利用
プレーンテキストの共有リンク ss://、trojan:// 単一ノードの接続パラメータ クライアント間でノードをコピー
base64サブスクリプション 連続する英数字とエンコード記号 通常はエンコードされた複数の共有リンク 1つのサブスクリプションURLでノード群を配布
プロバイダー独自のJSON { またはクライアント固有の項目 サーバー側と対象アプリに依存 特定クライアントやAPIとの連携

Clash YAMLが単なるノード一覧ではない理由

そのまま動作するClash YAMLには通常、少なくともproxies、proxy-groups、rulesの3要素が含まれます。最初の項目にノード情報を保存し、次の項目で手動選択・自動速度測定・フェイルオーバーなどの方式を定義し、最後の項目で接続先のプロキシグループを決めます。

mixed-port: 7890
allow-lan: false
mode: rule

proxies:
  - name: HK-Trojan-01
    type: trojan
    server: edge.example.net
    port: 443
    password: example-password
    sni: cdn.example.net

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - HK-Trojan-01
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

この設定では混合プロキシポートを7890に設定し、PROXYという手動選択グループを作成しています。実際のサブスクリプションには、rule-providers、proxy-providers、dns、sniffer、tun、永続キャッシュ設定などが含まれることもあります。これらは単一の共有リンクでは表現できません。

完全な設定ファイルとプロキシプロバイダーは別物

mihomoの設定では、proxy-providersを使ってリモートのノード群を参照できます。メイン設定にはDNS、ルール、プロキシグループを残し、リモートURLからはノードだけを更新します。「ローカルの振り分けロジック」と「リモートのノード提供元」を分けて管理するのに適した構成です。

proxy-providers:
  airport-a:
    type: http
    url: https://sub.example.net/token
    path: ./providers/airport-a.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

このリモートコンテンツは通常provider YAMLで、トップレベルがproxies:だけの場合もあります。カーネルを単独で起動できる完全な設定ファイルではありません。providerファイルを完全なProfileだけ受け付けるクライアントへ直接インポートすると、ポート、プロキシグループ、ルールなどが不足し、設定検証エラーになることがあります。

YAMLはインデントとデータ型に敏感

  • インデントにはスペースを使い、Tab文字を混在させないでください。
  • ポート443は通常数値で、パスワード、名前、サーバーアドレスは通常文字列です。
  • 名前にコロン、シャープ記号、前後の空白が含まれる場合は、引用符で囲むことをおすすめします。
  • trueと文字列"true"は意味が異なるため、自由に入れ替えられません。
  • 同名ノードをプロキシグループに入れると判別しにくくなるため、変換前に名前を重複しないよう整理してください。

base64サブスクリプションと汎用共有リンクの構成

汎用サブスクリプションでは、1行に1つのURIを記述するのが一般的です。各プロトコルがURI内のサーバー、ポート、認証情報、拡張パラメータを定義します。たとえばShadowsocksはss://、Trojanはtrojan://、VMessはvmess://、VLESSはvless://が一般的です。mihomoはさらに多くのプロトコルに対応しますが、旧Clashカーネルと各種GUIクライアントで対応範囲は異なります。

ss://[email protected]:8388#SS-01
trojan://[email protected]:443?sni=cdn.example.net#Trojan-01
vless://[email protected]:443?type=ws&security=tls&host=cdn.example.net#VLESS-01

リンク末尾のフラグメントは通常ノード名に使われ、クエリパラメータにはTLS、SNI、WebSocketパス、Host、伝送方式、フィンガープリントなどが保存される場合があります。パラメータ名やデフォルト値の扱いは実装によって異なります。クライアントがURIのプレフィックスを認識できても、すべての拡張項目を完全に解釈できるとは限りません。

base64デコード後に別のエンコード層がある場合も

サブスクリプション全体をデコードした後、VMessリンクの内部にさらにbase64エンコードされたJSONが含まれていることがあります。Shadowsocksのユーザー情報にも複数のURI表現があります。調査時は、まず本文をデコードし、次に行単位でプロトコルを判別し、最後に対応するパーサーへ渡してください。全体を繰り返し直接デコードすると、元のリンクを壊すおそれがあります。

  1. サブスクリプションのレスポンスを取得し、元のテキストをコピーして保存する。
  2. 冒頭にproxies:、プロトコルURI、JSON構造のいずれかがすでに現れていないか確認する。
  3. 内容が実際にbase64文字列の特徴に合う場合だけ、デコードを試す。
  4. デコード後は改行で分割し、空行を除いてから各行のプロトコルを判別する。
  5. ノード数、名前、ポート、TLSパラメータが完全に保持されているか確認する。

クライアントの互換性はカーネルとインポート経路で決まる

同じサブスクリプションでも2つのクライアントで動作が異なる場合、URLが無効なのではなく、カーネルのプロトコル対応、クライアントの前処理、インポート経路が異なることが主な原因です。Clash for Windows 0.20.39はすでにメンテナンスを終了しており、Profiles画面は主にClash設定を対象としています。mihomo系クライアントはより広いプロトコル項目を解析できることが多い一方、GUIが汎用サブスクリプションを直接受け付けるかは、クライアント独自のサブスクリプション機能に左右されます。

完全なYAMLをインポートする手順

Clash for Windows 0.20.39を例にすると、一般的な手順は「Profiles」→上部にサブスクリプションURLを入力→「Download」です。インポート後は設定カードが表示されることを確認し、「Proxies」に切り替えてプロキシグループとノードを確認します。ノードだけが表示され、期待したルールがない場合、サーバーが完全なYAMLではなく、クライアント用テンプレートで処理されたノード群を返している可能性があります。

mihomoカーネルを採用した2.x系GUIクライアントでは、「サブスクリプション」→「新規作成」→「URL」という入口が一般的です。名称はクライアントによって異なりますが、確認手順は共通しています。更新ログでHTTP 200が返っているか、設定検証に通るか、プロキシグループ数が想定どおりか、カーネルが正常に再読み込みされたかを確認してください。

ポート番号はサブスクリプションノードそのものに含まれない

7890、7891、9090はClash設定でよく見かけますが、役割は異なります。7890はHTTPとSOCKSの混合入口、7891は一部の旧設定でSOCKS、9090は外部制御インターフェースに使われることが一般的です。汎用共有リンクが示すのはリモートプロキシノードであり、ローカルクライアントの待受ポートを決めるものではありません。

そのため、汎用サブスクリプションをYAMLへ変換する際、変換ツールはmixed-port、プロキシグループ、ルールを追加することがよくあります。ノードが完全に同じでも、テンプレートが異なれば、2回の変換結果は異なる振り分け動作になる可能性があります。

形式変換で実際に行われていること

いわゆる「サブスクリプション変換」には通常、入力形式の判定、ノードの解析、項目のマッピング、出力テンプレートの適用という4つの工程が含まれます。入力は完全なYAML、provider YAML、base64化されたリンク集合、プレーンテキストのURIなどで、出力はClash YAML、mihomo YAML、または別のクライアントが読み込めるサブスクリプションテキストになります。

汎用サブスクリプションをClash YAMLへ変換

この変換が最も一般的です。変換ツールは各共有リンクを解析してproxies項目に変換し、テンプレートに従ってプロキシグループとルールを作成します。最低限、次の項目を確認してください。

  • プロトコル、サーバーアドレス、ポート、認証情報。
  • TLSが有効か、SNIまたはservernameが保持されているか。
  • WebSocket、gRPCなどの伝送方式とパスパラメータ。
  • UDPの有効化、証明書検証をスキップする設定、クライアントフィンガープリント。
  • ノード名が正しくエンコードされ、重複時に自動で接尾辞が付くか。
  • 生成先が旧Clash構文か、mihomo拡張構文か。

Clash YAMLを汎用サブスクリプションへ変換

逆方向の変換では、設定レイヤーの情報が必ず失われます。共有リンクで引き継げるのはノードの接続パラメータであり、proxy-groups、rules、rule-providers、DNS、TUN、スニッフィング、待受ポートは引き継げません。別のクライアントに再インポートした後、ノード数が同じでも、2つの設定が同等だとは判断できません。

完全なYAMLをprovider YAMLへ変換

通常はproxiesだけを抽出し、proxy-providersから参照するファイルを出力します。元の設定にある振り分けルールとプロキシグループが、メイン設定へ自動的に移ることはありません。メイン設定ではuse:を使ってproviderを指定のプロキシグループへ追加する必要があります。そうしないと、ノードがダウンロード済みでも画面上で選択肢として表示されないことがあります。

proxy-groups:
  - name: AUTO
    type: url-test
    use:
      - airport-a
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

項目の欠落が起きやすい6つのポイント

1. プロトコル拡張項目に対応する移行先がない

入力形式には、クライアントフィンガープリント、Reality公開鍵、短いID、ECH、輻輳制御、特定の伝送パラメータなどが含まれることがあります。一方、出力形式に同等の項目がなければ、変換ツールは無視するか、対象クライアントが認識しない拡張キーとして書き込む可能性があります。多くの場合、すぐにエラーが出るのではなく、ノードは表示されるものの接続がタイムアウトします。

2. ルールとプロキシグループがテンプレートで上書きされる

完全なYAMLを変換する際、ツールが先にノードを抽出してからテンプレートを適用すると、元のDIRECT、REJECT、フェイルオーバーグループ、ルール順序が置き換わります。Clashのルールは上から順に照合されるため、順序が変わるだけで結果も変わります。たとえばGEOIP,CN,DIRECTを特定ドメインのプロキシルールより前に置くと、対象の接続が先に直接接続される可能性があります。

3. ノード名がフィルタリング条件になる

多くのテンプレートでは、名前に含まれる「香港」「日本」「低倍率」などの語を正規表現で判定し、プロキシグループを作成します。変換後に旗の絵文字、空白、地域略称などが変わると、抽出結果が30ノードから0ノードになることもあります。移行の前後では、サブスクリプション全体の件数だけでなく、各プロキシグループの実際のメンバーも比較してください。

4. 真偽値とデフォルト値が変わる

元のリンクにあるパラメータが省略されている場合、クライアントによってデフォルト値が異なることがあります。たとえばUDP、TLS検証、SNIの推測、伝送時のHostはデフォルト動作に左右されます。変換ツールが値を明示的に書き込むと、かえって元のクライアントとは異なる接続動作になる場合があります。

5. DNSとTUNは旧設定に残ったまま

ノードの移行に成功しても、システムのプロキシ経路まで移行できたとは限りません。Fake-IPアドレスプール、DNSアップストリーム、ドメインスニッフィング、ルーティング除外、TUNの自動ルートはすべてローカル設定です。汎用サブスクリプションにはこれらの項目は含まれません。クライアントを切り替えた後は、「設定」→「システムプロキシ」、「設定」→「TUNモード」、DNS設定を改めて確認し、旧クライアントの状態をそのまま基準にしないでください。

6. サブスクリプションの更新方式が異なる

完全なYAMLは固定ノードを直接含められます。providerには独立したintervalとキャッシュパスがあり、GUIクライアントが独自の更新時刻を管理することもあります。例のinterval: 3600は3600秒ごとに取得することを示し、ヘルスチェックのinterval: 600は600秒ごとにテストすることを示します。両者は別の処理です。

検証しながら進められる移行手順

形式変換で最も安全なのは、「ワンクリックでインポートしてすぐ通信を切り替える」方法ではありません。旧設定を残し、段階的に照合してください。次の手順は、汎用サブスクリプションからmihomo YAMLへ移行する場合にも、2つのClash GUIクライアント間で設定を移す場合にも使えます。

  1. 基準値を記録する。元のクライアントのノード総数、よく使うプロキシグループ、システムプロキシポート、DNSモード、TUNの状態を記録します。
  2. 入力形式を判定する。返されたものが完全なYAML、provider YAML、プレーンテキストURI、base64テキストのどれかを確認します。
  3. 移行先を選ぶ。対象カーネルが旧Clashかmihomoかを明確にし、対象カーネルが対応しない項目を生成しないようにします。
  4. まずノードを変換する。サーバー、ポート、プロトコル、TLS、SNI、伝送層、名前を照合し、ルールの上書きは後回しにします。
  5. 次にテンプレートを適用する。プロキシグループ、ルール、DNS、待受ポートを追加し、参照名が一致しているか確認します。
  6. 設定を検証する。クライアントを再読み込みする前に解析エラーを確認し、YAMLのインデント、重複キー、存在しないプロキシグループを重点的に確認します。
  7. 少ない通信量で検証する。まずTUNを無効にしてシステムプロキシだけを有効にします。ブラウザの通信経路を確認してから、DNSとTUNをテストします。
  8. 実際の動作を比較する。直接接続するドメイン、プロキシ経由のドメイン、拒否対象のドメイン、UDP通信をそれぞれテストし、ルールの適用結果が想定どおりか確認します。

変換後にノードは正常表示されるのにすべてタイムアウトする場合は、まず1つのノードを抽出して元のリンクと照合し、ポート、SNI、TLS、伝送経路を確認します。一部のサイトだけが不安定なら、ルール順序とDNSを重点的に確認します。システムアプリがプロキシを経由しない場合は、サブスクリプション形式をさらに変更するのではなく、システムプロキシまたはTUNを確認してください。

形式は用途に合わせて選ぶ

  • 振り分け設定を完全に再現したい：対象カーネルと互換性のある完全なYAMLを優先し、ルール、プロキシグループ、DNSを保持します。
  • クライアント間でノードだけ移したい：汎用共有リンクまたはbase64サブスクリプションを使い、振り分けは移行先のクライアントに任せます。
  • ローカルルールを長期運用したい：メイン設定を固定し、ノードはproxy-providersでリモート更新します。
  • mihomoの拡張プロトコルを使いたい：変換先としてmihomoを明示的に選び、旧Clashの項目構成へ戻らないようにします。
  • 入力形式が不明：まずレスポンス本文を確認し、デコードや変換の要否を判断します。複数の変換ツールを連続して適用しないでください。

要するに、base64はテキストの伝送を担い、共有リンクは単一ノードを表し、Clash YAMLはプロキシ動作全体を管理します。変換で項目を移せても、移行先の形式で表現できない情報を自動的に保持することはできません。移行前にこの3つの層を区別しておけば、「ノードのインポートは成功したのに使えない」、ルールが消える、DNSの動作が急に変わるといった問題を大幅に減らせます。

クライアントをインストールしてサブスクリプションを確認

対応するプラットフォームを選び、チュートリアルに沿ってサブスクリプションをインポートし、プロキシグループ、システムプロキシ、DNSを確認します。

ダウンロードページへ チュートリアルを見る
Clashをダウンロード