購読と設定 読了まで約12分

Clashのサブスク形式を比較：Clash YAML・Base64ノードリンク・sing-box設定の相互変換

Clash YAML、Base64形式のノードリンク、sing-box設定の違いと対応クライアントを解説。ローカル変換時の注意点や安全な取り扱いも紹介します。

内容を見分けてから、適切な方法で読み込む

サブスクリプションURLはコンテンツの取得先を示すもので、形式名ではありません。同じURLでも、リクエストのパラメーターやクライアントのUser-Agentによって返される内容が異なることがあります。ファイル名が.yamlで終わっていても、レスポンスがClash設定とは限りません。読み込みに失敗したら、拡張子を何度も変えるのではなく、まず実際のレスポンスをローカルで確認しましょう。

次の3つを区別する必要があります。Base64はエンコード方式、ss://などのURIはノードの記述形式、Clash YAMLとsing-box JSONはそれぞれのコアが使う設定構造です。デコードしてノード一覧を取り出せても、ルール、DNS、待ち受けポートを含む完全な設定が生成されたことにはなりません。

形式ローカルでの見分け方主な内容
Clashの完全なYAML設定トップレベルにproxies、proxy-groups、rulesがよく使われますノード、グループ、ルール。DNSやTUNの設定を含む場合もあります
Clashのノードプロバイダー用YAML通常はトップレベルのproxies:リストが中心ですproxy-providersから参照するノードの一覧
ノードURIの一覧複数行のss://、vmess://、trojan://などノード接続用のパラメーター。通常、完全なルーティングポリシーは含みません
Base64形式のサブスクリプション英数字やエンコード記号が連続しているように見えます。デコードしてから判別しますノードURIの一覧が一般的ですが、実際の形式はデコード結果で確認してください
sing-box JSONトップレベルにinbounds、outbounds、routeがよく使われますインバウンド、アウトバウンド、ルーティングと必要に応じたDNS設定

Clash YAML：完全な設定とノードプロバイダー

YAMLを解析できても、プロキシとしてそのまま動作するとは限りません

YAMLはデータを表現する形式です。mihomoはフィールドの型、ノードのパラメーター、参照関係も検証します。インデントにはスペースを使い、Tabは使わないでください。ポートはフィールドの指定に従って数値で設定します。特殊文字を含む名前、パスワード、URLは引用符で囲むと、#がコメントとして扱われたり、コロンで構造が変わったりするのを防げます。

以下は構造を理解するための、プロキシノードを含まない直結設定例です。ローカルの127.0.0.1:7890で待ち受け、ルールモードを有効にし、「出口選択」というグループに接続します。グループ内はDIRECTのみのため、実行しても通信は直接接続されます。この例だけでは、クライアントのシステムプロキシやTUNは有効になりません。

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

proxies: []

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

rules:
  - MATCH,出口選択

プロバイダーファイルはメイン設定から参照する

ノードプロバイダーが提供するのは、通常proxiesの一覧だけです。メイン設定ではproxy-providersで提供元、更新間隔、ヘルスチェックを定義し、プロキシグループのuseからプロバイダー名を参照します。プロバイダーファイルを完全な設定として読み込むと、「ノードは表示されるのに、想定したプロキシグループがない」といった状態になることがあります。

  • 参照関係を確認：ルールで指定したグループ名が存在すること、グループ内のノード名やプロバイダー名が実際の名前と一致することを確認します。
  • 名前の重複を確認：ノード名が重複すると、選択や参照が曖昧になります。変換時に名前を変更した場合は、関連する参照先も合わせて更新してください。
  • コアを確認：Clash互換設定でも、すべての旧版Clashコアで使えるとは限りません。一部のプロトコルや拡張フィールドにはmihomoが必要です。実際に利用できる機能は、クライアントが使用するコアによって異なります。

Base64：デコードしてもプロトコル変換にはならない

Base64はサブスクリプションの認証情報を隠すものではなく、フィールドを自動補完するものでもありません。一般的なサブスクリプションでは、複数のノードURIを改行でつないだ文字列全体をエンコードしています。URI自体にBase64の断片が含まれる場合もあります。外側のデータをデコードできたら、まず各行のプロトコルを確認してください。「読める文字列」になるまで何度もデコードする必要はありません。

Python 3で外側のデータをローカル確認する

取得したエンコード済みの本文をsubscription.txtとして保存し、以下のスクリプトをdecode_subscription.pyとして保存して、python3 decode_subscription.pyを実行します。一般的な標準形式とURLセーフ形式の文字セットに対応し、末尾のパディングも補います。デコードのみを行い、ノードへの接続、設定の変換、ノード情報の端末への出力は行いません。

from pathlib import Path
import base64
import binascii

source = Path("subscription.txt").read_text(encoding="utf-8-sig")
compact = "".join(source.split())

if not compact:
    raise SystemExit("入力が空です")

compact += "=" * (-len(compact) % 4)

try:
    raw = base64.b64decode(compact, altchars=b"-_", validate=True)
    text = raw.decode("utf-8")
except (ValueError, binascii.Error, UnicodeDecodeError):
    raise SystemExit("UTF-8のBase64テキストとしてデコードできません。元のレスポンスを確認してください")

with Path("decoded.txt").open("x", encoding="utf-8") as output:
    output.write(text)

print("decoded.txt に書き込みました。内容の形式をローカルで確認してください")

排他的な書き込みモードを使うのは、既存のdecoded.txtを上書きしないためです。ファイルがすでにある場合は、残しておく必要があるか先に確認してください。デコード後のファイルにも機密情報が含まれるため、公開リポジトリにアップロードしたり、グループチャットに投稿したりしないでください。

URIの内部もプロトコルに従って解析する

  • ss://には複数の記述形式があり、ユーザー情報がBase64エンコードされている場合や、プラグインのパラメーターが付いている場合もあります。最初のコロンや@だけを基準に分割しないでください。
  • vmess://はエンコードされたJSON形式が一般的ですが、各フィールドの検証が必要です。汎用的なノード文字列として扱うことはできません。
  • trojan://やvless://などのリンクでは、クエリパラメーターにTLS、トランスポート層、パスの情報が含まれることがよくあります。URLのパーセントデコードも、フィールドの境界に従って行ってください。
  • フラグメント内の表示名は、通常、接続パラメーターではありません。ノード名を変更すると識別しやすくなりますが、誤ったサーバーアドレスや認証情報は修正されません。

sing-box JSONとClash YAMLの変換で注意する点

どちらもプロキシ接続を記述できますが、設定モデルは異なります。Clashはノード、プロキシグループ、順序付きルールで通信先を構成するのが一般的です。一方、sing-boxはtagを持つアウトバウンドとルーティング参照で通信を構成します。proxiesをoutboundsに名前変更するだけでは、有効なsing-box設定にはなりません。

以下はsing-boxの直結設定例です。HTTPとSOCKSが127.0.0.1:7890を共有し、最終的にdirect-outへルーティングされます。フィールドを比較するための独立した例であり、上記のmihomoの例とは同じ待ち受けアドレスとポートを同時に使用できません。

{
  "inbounds": [
    {
      "type": "mixed",
      "tag": "mixed-in",
      "listen": "127.0.0.1",
      "listen_port": 7890
    }
  ],
  "outbounds": [
    {
      "type": "direct",
      "tag": "direct-out"
    }
  ],
  "route": {
    "final": "direct-out"
  }
}
変換項目対応が必要な違い
ノード接続プロトコル、アドレス、ポート、認証、TLS、トランスポート層の各パラメーターを個別に対応付ける
プロキシの選択Clashのプロキシグループとsing-boxのセレクター系アウトバウンドでは、構造や選択肢が完全には一致しません
ルーティングルールルールの構文、アクション、ルールセットの形式が異なるため、そのままコピーできません
DNSサーバー定義、名前解決ルート、Fake-IP、ブートストラップ用名前解決を個別に再構成する
通信の制御システムプロキシはクライアントまたはOSで設定します。TUNには権限、ルーティング、プラットフォームごとの差異も関係します

設定と一緒にバージョンも記録する

sing-boxのDNSやルーティング関連フィールドは、バージョンによって変更されています。たとえば1.12.0では新しいDNSサーバー設定形式が導入されました。あるクライアントで読み込めた旧設定が、コアの更新後も使えるとは限りません。変換前に、変換元と変換先のコア、変換ツールのバージョンを記録し、変換先のバージョンに対応したドキュメントに従って設定を作成してください。アプリの画面に表示されたバージョン番号だけを記録するのは避けましょう。

クライアントの対応形式：インポーターとコアを区別する

「クライアントがある形式に対応」とは、内蔵のインポート・変換機能を指す場合があり、基盤のコアがその形式を直接読み込めるという意味ではありません。mihomoをコアとするクライアントは、一般にClash YAMLを中心に動作します。ノードリンクを設定にまとめられるクライアントもありますが、Base64形式の本文全体を受け付けるか、ルールやDNS設定を保持するかは、インポート方法によって異なります。sing-boxコアは主に独自のJSON設定を読み込みますが、GUIクライアントが別途サブスクリプション管理機能を実装している場合もあります。

  1. まず読み込み方法を確認：「URLから設定を読み込む」「単一ノードを追加」「ノードプロバイダーを読み込む」「ローカルファイルを読み込む」を区別してください。単一ノードの追加では、完全なルール構成は通常自動生成されません。
  2. 次にインポート結果を確認：ノード数、プロトコルの種類、プロキシグループ名をチェックします。元ファイルに12個のノードがあり、結果が9個の場合は、そのまま有効にせず、読み込まれなかった3個のノードを先に確認してください。
  3. 最後に実際に有効な設定を確認：サブスクリプションのキャッシュ、ユーザーによる上書き設定、クライアントが生成した設定は、別々のファイルである場合があります。画面上の変更が次回更新後も保持されるか、個別に確認してください。

クライアントを選び直す場合は、ダウンロードセンターでOS別の選択肢を確認してください。インポート方法と初回の通信制御については、サブスクリプションのインポートガイドをご覧ください。クライアント名だけで、すべてのClash拡張フィールドに対応していると判断しないでください。

ローカル変換と検証：5つの手順で問題を切り分ける

1. 元ファイルと変換先のバージョンを保存する

編集しない元ファイルを1つ残し、変換結果は別ファイルとして保存します。取得日時、コンテンツタイプ、変換先のコアのバージョンを記録してください。サブスクリプションURLにアクセストークンが含まれる場合は、記録には用途だけを記載し、完全なURLを共有ドキュメントに残さないでください。

2. 先にノードを変換し、その後にルールを移行する

まずサーバー、ポート、パスワードまたはUUID、暗号化方式、トランスポートパラメーターを確認し、その後でグループとルールを移行します。変換先のコアで表現できないプロトコルは、失敗したことを記録し、別のプロトコルに黙って置き換えないでください。ノード一覧しかない場合は、DNSとルーティングを別途設計します。存在しなかったルールが変換ツールによって復元されることはありません。

3. 変換先のコアで構文を検証する

以下のコマンドは、コアの実行ファイルが現在のターミナルのパスにあることを前提としています。mihomoの-tは設定を検証し、sing-boxのcheckは設定の有効性を確認します。Windowsでは、対応する.exeのファイル名を使用してください。検証に通っても、設定として受け入れられることを示すだけで、サーバーへの到達や認証の成功を保証するものではありません。

mihomo -t -f converted.yaml
sing-box check -c converted.json

4. 明示的なプロキシ設定でノードを確認する

システム設定の影響を減らすため、まずTUNを有効にせず、確認済みのローカルHTTPプロキシポートでテストできます。以下の例では、設定に7890ポートがあり、現在のプロキシグループでテスト対象のノードが選択されている必要があります。テスト先のサイトはリクエスト先であり、ノードのサーバーではありません。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

このコマンドが成功しても、そのリクエストがローカルプロキシの入口を経由して処理されたことしか確認できません。接続パネルやログで、最終的なアウトバウンドも確認してください。DIRECTに一致している場合、プロキシノードが正常に動作しているとは言えません。失敗した場合は、ポートが待ち受けていない、DNSに失敗した、TLSハンドシェイクに失敗した、接続先から認証を拒否された、の順に切り分けます。

5. その後でシステムプロキシとTUNを検証する

明示的なプロキシテストが正常に終わったら、システムプロキシを有効にしてブラウザーをテストします。システムプロキシに従わないアプリの通信を制御する必要がある場合に限り、次にTUNを試してください。TUNの権限、ルーティング、DNS制御に関する問題は、サブスクリプションのエンコードとは別の問題です。一度に変更するのは1つの層だけにして、問題がノード変換にあるのか通信制御にあるのかを判断できるようにします。

サブスクリプションの認証情報と変換結果を安全に保存する

サブスクリプションURLをオンライン変換サービスに渡すと、通常はそのサービスが元のサブスクリプションとノードの認証情報を取得できます。ブラウザーで変換ページを開いただけでは、処理がローカルで行われた証拠にはなりません。オフラインで処理する必要がある場合は、リモートサービスに依存しないことを確認したローカルツールを使い、ルールテンプレートやリモートプロバイダーなどの追加リソースが引き続きネットワーク接続を必要とするか確認してください。

  • ローカルインターフェースへの公開を制限：変換サービスを自分の端末だけで使う場合は、127.0.0.1で待ち受けるようにし、0.0.0.0や公開ポートで直接公開しないでください。
  • ファイルの読み取り権限を制限：LinuxまたはmacOSでは、chmod 600 subscription.txt decoded.txt converted.yamlを実行して既存ファイルへのアクセスを制限できます。Windowsでは、ファイルのセキュリティ権限を設定してください。
  • 情報を伏せてから問題を報告：エラー情報を共有する際は、プロトコル、フィールド名、エラー位置を残し、サブスクリプションのトークン、パスワード、UUID、公開に適さないサーバー情報を削除してください。
  • 漏えいした認証情報を変更：Base64のテキストも、平文の設定と同様に保護してください。サブスクリプションリンクが公開された場合は、投稿を削除するだけでなく、提供元の管理画面でリンクや関連する認証情報をリセットしてください。

変換の完了は「ファイルを開けること」だけでは判断できません。変換先のコアによる検証に通り、重要なフィールドが保持され、プロキシグループの参照関係が整い、実際の通信が想定どおりのアウトバウンドを通ることが必要です。提供元が変換先の形式を直接生成できる場合は、そちらを優先してください。形式の相互変換が必要な場合は、元ファイルを保管し、バージョンを記録したうえで段階的に検証すると、サブスクリプション更新後の再トラブルシューティングを減らせます。

Clash をダウンロード