Clashのサブスクリプション形式ガイド：YAML・Base64共有リンク・sing-box JSONの相互変換

まず受け取ったサブスクリプションの種類を見分ける

結論から言うと、ClashやMihomoでは通常YAML設定を使い、sing-boxではJSON設定を使います。一見すると文字化けのようなサブスクリプション内容は、Base64でエンコードされた共有リンクの集合であることが多いものです。3形式には共通する情報もありますが、拡張子を変えるだけでは相互変換できません。

サブスクリプションリンクは内容を取得するためのアドレスであり、内容の形式そのものではありません。サーバーは、https://で始まる同じアドレスでも、クライアントのパラメータに応じてClash YAML、汎用共有リンク、sing-box JSONを返せます。判別するときはURLの拡張子だけでなく、レスポンス本文を確認してください。

冒頭の数文字で素早く判別する

表示された内容	可能性の高い形式	次の手順
`proxies:`、`proxy-groups:`	ClashまたはMihomoのYAML	対応クライアントへ直接インポートし、設定項目を確認する
`dm1lc3M6Ly8`、英数字とイコールが連続している	Base64エンコードされたテキスト	デコードしてから、複数行の共有リンクか確認する
`ss://`、`trojan://`、`vless://`	1件または複数件のURI共有リンク	変換ツールで目的の設定形式を生成する
`{"log":`、`"outbounds"`	sing-box JSON	sing-boxで検証し、Clashへ直接インポートしない
WebページのHTML、ログイン案内、またはエラー説明	サブスクリプションの取得に失敗	アドレス、有効期限、リクエストパラメータを確認する

まずテキストとして読み取り、直接ダブルクリックして実行しない

ブラウザの開発者ツールにある「ネットワーク」パネルでレスポンスを確認するか、内容をプレーンテキストとして保存します。コマンドラインでは curl を使い、出力ファイル名を指定すると、長い内容で端末が埋め尽くされるのを防げます。

curl -L --max-time 20 "https://sub.example.net/api/demo-token" -o subscription.txt
head -n 8 subscription.txt

-L はリダイレクトを追跡し、--max-time 20 はリクエスト全体を20秒以内に制限します。ファイルの1行目に <!doctype html> が現れた場合、取得したのはサブスクリプション設定ではなくWebページです。ログイン、アドレスの失効、ゲートウェイによる遮断などを先に確認してください。

YAML・Base64・sing-box JSONの構造の違い

形式変換の難しさは構文ではなく、設定モデルにあります。ノードのアドレス、ポート、認証情報は比較的対応付けやすい一方、プロキシグループ、ルールセット、DNSの動作、TUNルーティング、スクリプト拡張は特定のコアにしか存在しない場合があります。変換ツールは構造を書き換えられても、各ルールの本来の意図まで自動的に理解できるわけではありません。

ClashとMihomoのYAML

YAML設定には通常、ノード、プロキシグループ、ルールをまとめて記述します。MihomoはClash設定エコシステムを受け継ぐオープンソースのプロキシコアで、多くのプロトコルや拡張項目に対応しています。最小構成の例は次のとおりです。

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

proxies:
  - name: HK-01
    type: ss
    server: edge.example.net
    port: 8388
    cipher: aes-128-gcm
    password: demo-pass

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

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - MATCH,PROXY

mixed-port: 7890 は、HTTPリクエストとSOCKSリクエストで7890番ポートを共有することを示します。proxy-groups はクライアントで選択できるプロキシポリシーを定義し、rules は上から順にトラフィックへ適用されます。ノード一覧だけでプロキシグループやルールがない場合、自動補完できるクライアントもあれば、設定を利用できないと警告するクライアントもあります。

Base64でまとめられた共有リンク

Base64はプロキシプロトコルでも、完全な設定形式でもありません。バイト列を転送しやすいテキストへエンコードする仕組みです。一般的なサブスクリプションでは、複数行の ss://、trojan://、vmess://、vless:// リンクを連結し、全体をBase64で一度エンコードします。

ss://[email protected]:8388#HK-01
trojan://[email protected]:443?security=tls#SG-01

この形式の内容には通常、ノードのパラメータと表示名だけが含まれ、Clashの完全なルールは含まれません。YAMLへ変換するとき、変換ツールはテンプレートに従って proxy-groups、rules、DNS設定を補います。そのため、同じノードでもテンプレートが違えば最終的な動作は大きく異なります。

sing-box JSON

sing-boxでは、インバウンド、アウトバウンド、ルーティング、DNSをJSONで記述します。sing-box 1.12の設定構造を例にすると、ノードは通常 outbounds 配列に配置され、セレクターもアウトバウンドオブジェクトの一種です。

{
  "log": {
    "level": "info"
  },
  "outbounds": [
    {
      "type": "shadowsocks",
      "tag": "hk-01",
      "server": "edge.example.net",
      "server_port": 8388,
      "method": "aes-128-gcm",
      "password": "demo-pass"
    },
    {
      "type": "selector",
      "tag": "proxy",
      "outbounds": [
        "hk-01"
      ]
    }
  ],
  "route": {
    "rules": [
      {
        "action": "route",
        "domain_suffix": [
          "example.org"
        ],
        "outbound": "proxy"
      }
    ],
    "final": "proxy"
  }
}

Clashの proxy-groups とsing-boxの selector、urltest は近い形で対応付けられますが、項目名と実行モデルは異なります。Clashの MATCH は通常、sing-boxのルーティングにおける最終アウトバウンドに相当し、同名ルールへ単純にコピーするものではありません。

Base64をデコードしてから変換先を決める

長い文字列を見ただけで、すぐ変換ツールへ渡してはいけません。まずローカルでデコードし、先頭数行を確認してください。内容が完全かどうかを確かめられるほか、エラーページ、圧縮データ、二重エンコードされた内容をノードサブスクリプションと誤認するのを防げます。

Windows PowerShellでデコードする

$raw = (Get-Content .\subscription.txt -Raw).Trim()
$bytes = [Convert]::FromBase64String($raw)
[Text.Encoding]::UTF8.GetString($bytes) |
  Set-Content .\decoded.txt -Encoding utf8
Get-Content .\decoded.txt -TotalCount 8

FromBase64String で形式エラーが出る場合は、テキストに空白、HTMLタグ、URLセーフ形式の文字が混入していないか確認します。URLセーフBase64では、プラス記号とスラッシュの代わりにハイフンとアンダースコアを使い、末尾のイコールを省略することがあります。この形式に対応したツールで処理してください。

Linux・macOSでデコードする

# GNU/Linux
base64 -d subscription.txt > decoded.txt

# macOS
base64 -D subscription.txt > decoded.txt

sed -n '1,8p' decoded.txt

デコード後もBase64の文字列がまとまって残る場合、二重エンコードの可能性があります。ただし、VMessリンク内部のJSONエンコードの場合もあります。まず接頭辞を確認してください。サブスクリプション全体が二重エンコードされているなら続けてデコードできますが、vmess:// の後ろは単一ノードのデータなので、行全体の接頭辞を通常のBase64コマンドへ渡してはいけません。

オープンソースの変換ツールでClash YAMLを生成する

入力がURIリストまたはBase64サブスクリプションで、接続先クライアントがMihomoの場合は、Clash出力に対応したオープンソースのサブスクリプション変換ツールを利用できます。一般的な実装では /sub インターフェースが用意され、入力URL、出力形式、ルールテンプレートを受け取ってYAMLを返します。

変換前に3つのパラメータを確認する

出力形式：Clash、またはMihomoやClash Metaと明記された出力を選びます。旧版Clash向けの出力では、新しいプロトコル項目が削除される場合があります。
入力URL：必ずURLエンコードしてください。特にURL自体に ?、&、イコールが含まれる場合は注意が必要です。
ルールテンプレート：ノード変換とルール生成は別の処理です。初回テストではシンプルなテンプレートを使い、ノードへ接続できることを確認してからリモートルールセットを追加するのが安全です。

ローカルの変換サービスが 127.0.0.1:25500 で待ち受けているとします。入力URLをエンコードすれば、次の形式でClash出力をリクエストできます。

curl "http://127.0.0.1:25500/sub?target=clash&url=https%3A%2F%2Fsub.example.net%2Fapi%2Fdemo-token" \
  -o converted.yaml

target の名称はプロジェクトやブランチによって異なります。clash に対応するバージョンもあれば、拡張版でMihomoやsing-box向けの出力を提供している場合もあります。現在のビルドが対応する出力一覧を確認し、インターフェース名だけで判断しないでください。sing-box出力に対応していないツールなら、対応アダプターを備えた実装へ切り替えます。YAMLの拡張子を .json に変更するだけでは不十分です。

インポート前に構文を確認する

Mihomoではコマンドラインから設定を検証できます。実行ファイル名を mihomo、設定ファイルをカレントディレクトリの converted.yaml とした場合は次のように実行します。

mihomo -t -f ./converted.yaml

テストに合格しても、すべてのノードへ接続できるとは限りません。続いてクライアントを起動し、「サブスクリプション」または「設定」画面でファイルを読み込み、「プロキシ」画面でプロキシグループにノードが表示されることを確認します。最後に「設定」→「システムプロキシ」を開き、HTTPとSOCKSのポートが設定と一致しているか確認してください。たとえば、どちらも混合ポート7890を指定します。

ローカルで変換サービスを安全に運用する手順

サブスクリプションURLには通常、アクセス認証情報が含まれます。頻繁に変換するなら、オープンソースの変換プログラムを自分のPCまたは管理下のサーバーで実行し、入力URLが自分の端末とサブスクリプションサーバーの間だけを通るようにするのが適しています。セルフホストならバージョンやルールテンプレートも固定しやすく、同じサブスクリプションから日によって異なる結果が出るのを抑えられます。

ローカル実行時の基本設定

プロジェクトのリリース情報から、OSとCPUアーキテクチャに合ったビルドを取得します。例としてWindows x64、Linux amd64、macOS arm64などがあります。
プログラムと設定ファイルを専用ディレクトリに置き、初回起動時は 127.0.0.1 のみで待ち受けるようにします。パブリックネットワークのインターフェースへ直接バインドしないでください。
25500 などの待ち受けポートを確認し、ブラウザまたは curl でローカルインターフェースへアクセスします。
ルールテンプレートをローカルに保存し、変換プログラムのバージョン、テンプレートのバージョン、出力日時を記録します。
まず1つのノードでテストし、項目の対応付けが正しいことを確認してから完全なサブスクリプションを処理します。

変換サービスをLAN上のサーバーに置く必要がある場合は、入力元を制限し、リバースプロキシでアクセス制御を追加してください。変換インターフェースは通常、任意のサブスクリプションURLを送信できます。制限がなければ、サブスクリプション内容が漏れるだけでなく、サーバーから内部ネットワークのアドレスへリクエストを送られるおそれもあります。

入力と出力を固定してロールバックしやすくする

3つのファイルを保存することをおすすめします。元のレスポンス source.txt、変換後の converted.yaml または config.json、バージョンとパラメータを記録する conversion-notes.txt です。たとえば待ち受けポート25500、出力先 clash、テンプレートファイル名、変換日を記録します。次回ノード数に異常があったとき、入力の変更、テンプレートの変更、ツールの更新のどれが原因かをすぐ比較できます。

Clash YAMLからsing-box JSONへ変換するときの対応付け

YAMLからJSONへの変換は、単なる構文変換ではありません。汎用のYAML→JSON変換ツールはインデント構造を波括弧の構造へ変更できるだけで、Clashの proxies をsing-boxの outbounds に変換したり、プロキシグループやルーティングルールを理解したりはできません。2種類のプロキシ設定モデルを理解する変換ツールが必要です。

主な項目の対応関係

Clash / Mihomo	sing-box	変換時の注意点
`proxies[].name`	`outbounds[].tag`	tagは一意でなければならず、重複する場合は名前を変更する
`server`、`port`	`server`、`server_port`	ポート項目の名称が異なる
`proxy-groups` のselect	`selector` outbound	メンバー名を対応するtagへ変更する
`url-test`	`urltest` outbound	テスト用アドレス、間隔、許容差を改めて確認する
`rules`	`route.rules`	ルールの種類と最終アウトバウンドは機械的にコピーできない
`dns`	`dns` とルーティングの連携	リゾルバータグ、振り分け条件、キャッシュ動作が異なる
`tun`	`inbounds` 内のtun	インターフェースアドレス、自動ルート、厳格ルートを再設定する

プロトコル項目にも違いがあります。たとえばTLSのサーバー名、ALPN、Realityパラメータ、WebSocketパス、リクエストヘッダーは、2つの設定形式で入れ子になる位置が異なります。変換後にノードが表示されるのにハンドシェイクに失敗する場合は、ローカルポートを何度も変更するのではなく、まずこれらの項目を比較してください。

ルールを完全に対応付けられない場合の進め方

まず1つのノードだけを変換し、最終ルートをそのノードに設定してプロトコルパラメータを検証します。
手動選択用のセレクターを1つ追加し、ノードのtagとセレクターのメンバーが一致することを確認します。
LAN内とよく使う直接接続のルールを追加し、ローカルデバイスへのアクセスに影響がないことを確認します。
その後、ドメイン、IP、ルールセットを追加し、ログで実際に適用されたルールを確認します。
最後にTUNと複雑なDNS振り分けを有効にします。複数の変数を同時に切り分けるのは避けてください。

変換後に必ず確認したい10項目

変換が完了しても、使用中の設定をすぐに上書きしないでください。まず別名で保存し、項目ごとに確認します。以下の項目は「ファイルをインポートできるか」より重要です。

ノード数：入力に36個のノードがあるなら、出力が3個だけになるのは不自然です。数が減った場合は、対象形式または変換ツールによってプロトコルが除外されていないか確認します。
ノード名：名前は一意でなければなりません。同名があると、プロキシグループがそのうち1つだけを参照することがあります。
サーバーとポート：server がサブスクリプションサーバーのアドレスになっていないことを確認し、443、8443、8388などの実際のポートも照合します。
認証情報：パスワード、UUID、キーとその大文字・小文字を確認します。URLデコードによってプラス記号が誤って空白として処理されていないかにも注意してください。
TLSパラメータ：サーバー名、証明書検証をスキップするかどうか、ALPN、Reality公開鍵などを確認します。
トランスポートパラメータ：WebSocketパスの先頭にあるスラッシュを保持し、gRPCのservice nameとHTTP Hostを取り違えないでください。
プロキシグループのメンバー：手動選択、自動速度テスト、フォールバックの各グループに有効なノードが存在し、グループ名だけが残っていないことを確認します。
ルールの順序：ルールは上から順に適用されます。LANへの直接接続は通常、最終フォールバックルールより前に置きます。
DNSの動作：待ち受けアドレス、上流サーバー、プロキシ経由の名前解決と直接接続時の名前解決の役割分担を確認し、名前解決ループを避けます。
ローカルポート：設定を7891へ変更した場合、Windows 11の「設定」→「ネットワークとインターネット」→「プロキシ」も同時に変更してください。以前の7890が自動的に追従することはありません。

最短経路で結果を検証する

まずTUNを無効にし、システムプロキシと手動ノード1つだけを有効にします。外部IP確認ページへアクセスし、その後コマンドラインから混合ポート経由でHTTPSアドレスへリクエストします。

curl -x http://127.0.0.1:7890 --connect-timeout 8 https://example.com/

正常なレスポンスが返ったら、ルールモード、自動速度テスト、TUNの順に試します。自動速度テストで80ミリ秒と表示されても、測定先への往復が速いだけで、すべてのWebサイトへ安定してアクセスできるとは限りません。実際の検証ではDNS、TLSハンドシェイク、ダウンロードの過程も確認してください。

よくある質問

YAMLの拡張子をJSONに変更すれば、sing-boxで読み込めますか？

できません。拡張子を変えても内部のデータモデルは変わりません。汎用ツールでYAMLの構文をJSONへ変換しても、内容はClashの proxies、proxy-groups、rules のままです。sing-boxがそれらをアウトバウンドやルーティングとして自動解釈することはありません。

Base64をデコードしたらノードしかありません。ルールはどこにありますか？

汎用URIサブスクリプションは主にノードパラメータを伝えるもので、通常はClashのプロキシグループや振り分けルールを含みません。YAMLを生成するときにルールテンプレートを選ぶか、変換後の設定でプロキシグループとルールを自分で管理する必要があります。

変換後のサブスクリプションは自動更新できますか？

インポート方法によります。ローカルへ書き出した静的ファイルは自動更新されません。クライアントに変換インターフェースのURLを保存している場合は、更新間隔に従って再リクエストできます。元のURLを保存し、変換サービスが長期的に利用できることも確認してください。

Mihomoの設定を旧版Clashでそのまま使えますか？

基本項目は互換性がある場合もありますが、Mihomo独自の拡張プロトコル、ルールセット、DNS、TUN項目は旧コアで認識されないことがあります。旧コアのクライアントを使う場合は対応する出力形式を選び、そのコア独自の設定検証コマンドで確認してください。

変換後、遅延がすべてタイムアウトになります。まず何を確認すべきですか？

まず速度テスト用アドレスへアクセスできるか確認し、次にプロキシグループへノードが実際に含まれているか確認します。手動接続も失敗する場合は、サーバー、ポート、TLSサーバー名、トランスポート経路を比較してください。手動接続が正常なら、速度テストURL、間隔、同時実行数の設定が原因であることが多いです。

形式の選び方

Mihomoクライアントが目的なら、サーバーが直接提供するClashまたはMihomo YAMLを優先します。sing-boxが目的なら、現在のsing-box設定構造向けに生成されたJSONを優先してください。入力側が目的の形式を提供していない場合に限り、変換レイヤーを追加します。

Base64 URIサブスクリプションは汎用的なノードソースとして便利ですが、完全なトラフィック振り分けを担うものではありません。長期運用では、ノード変換とルールテンプレートを分けて管理しましょう。ノードはサブスクリプションに合わせて更新し、ルールは選択した設定として自分で管理します。問題が起きたとき、ノードパラメータの変化なのか、ルーティングやDNS設定の変化なのかを切り分けやすくなります。

最後に、シンプルな原則を1つ。まず単一ノードを検証してからプロキシグループを追加し、まずシステムプロキシを検証してからTUNを有効にし、まず構文を確認してからネットワークを調べます。形式変換に関わる変数が少ないほど、原因を速く特定できます。