Clashのサブスクリプション形式を比較：YAML設定・Base64ノードリンクと変換方法

まず内容を確認：サブスクリプションURLと形式は別物

Clashのサブスクリプションをインポートできないときは、変換を試す前にサーバーから何が返ってきたか確認しましょう。https://で始まるサブスクリプションURLは取得先を示すだけで、返される内容は完全なYAML、ノード一覧をBase64エンコードしたテキスト、ログインページ、エラーメッセージなどさまざまです。ファイル名がclash.yamlでも有効な設定とは限らず、クライアントに「サブスクリプション」と表示されていても、あらゆるノード形式を読み込めるわけではありません。

この記事は、mihomoカーネルを使うClashクライアントを主な対象としています。mihomoは、Clash Metaの後継プロジェクトで使われている名称です。従来のClashカーネルや各種GUIクライアントでは、対応プロトコルやインポート方法が異なる場合があります。「カーネルがそのノードを利用できるか」と「画面から共有リンクを読み込めるか」は別々に確認し、クライアント名だけで判断しないようにしましょう。

Clash YAML：ノードとルーティング設定を1つのファイルにまとめる

YAMLは構造化テキストであり、ノードのプロトコルではありません。proxiesでノードを定義し、proxy-groupsでノードをプロキシグループにまとめ、rulesで通信をどのポリシーに振り分けるかを指定します。完全な設定では、mixed-port、dns、tunなども設定できます。ノードリンクからYAMLを生成する場合、これらの設定は変換テンプレートまたはローカル設定で追加する必要があります。

完全な設定例：Shadowsocksノード1つの場合

以下は設定全体の構成例であり、そのまま接続に使えるサブスクリプションではありません。proxy.example.comは説明用のドメインで、パスワードもサンプル値です。実際に使うには、サービス提供元から指定されたアドレス、ポート、暗号化方式、パスワードに置き換えてください。TUNは有効化されておらず、専用のDNS設定もありません。

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

proxies:
  - name: SSの例
    type: ss
    server: proxy.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "password"
    udp: true

proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - SSの例
      - DIRECT

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,手動選択

• 7890はローカルのHTTP/SOCKS混合プロキシポート、8388はリモートノードのポートです。互いに置き換えることはできません。
• SSの例は、ノード定義とプロキシグループからの参照で完全に同じ名前にする必要があります。空白も含めて一致させてください。
• MATCHは最後に適用するフォールバックルールなので、個別ルールの後に置きます。ここでは順序だけを示しており、中国本土と海外を分ける完全なルールセットではありません。
• インデントにはスペースを使い、Tabは使わないでください。特殊文字がYAMLの構文として解釈されないよう、パスワードは引用符で囲むのがおすすめです。

ノード一覧だけの場合はproxy-providersを検討

ルールを長期的に自分で管理する場合は、メイン設定を固定し、ノードプロバイダーだけを更新する方法があります。サブスクリプションを更新するたびに、ローカルルールへ影響が及ぶのを抑えられます。以下は既存のメイン設定に追加する設定例です。ローカルファイル./providers/nodes.yamlには、トップレベルのproxies:とノード一覧を記述してください。

proxy-providers:
  ローカルノード:
    type: file
    path: ./providers/nodes.yaml

proxy-groups:
  - name: サブスクリプション選択
    type: select
    use:
      - ローカルノード

ファイルパスはカーネルの実行ディレクトリやクライアントの管理方法によって異なり、ダウンロードフォルダーとは限りません。また、メイン設定のルールでサブスクリプション選択を参照する必要があります。ノードだけを含むファイルを、ルーティングルールまで設定済みの完全な設定として扱わないでください。

Base64サブスクリプション：エンコードであり、暗号化ではない

一般的な汎用サブスクリプションでは、複数行の共有リンクをまとめてから、テキスト全体をBase64エンコードします。デコードして得られるのはノードリンクの一覧であり、自動的にClash YAMLが生成されるわけではありません。サービスによってはリンクを平文で返すこともあるため、すべてのサブスクリプションを機械的にデコードせず、まず内容を確認しましょう。

デコード後に表示される内容

以下は説明用の共有リンク2件です。サンプルドメインとサンプルパスワードを使っているため、接続には使用できません。1つ目のユーザー情報をデコードするとaes-128-gcm:passwordになります。2つ目のsniは、TLSで使用するサーバー名を指定しています。

ss://[email protected]:8388#SS-demo
trojan://[email protected]:443?sni=proxy.example.com#Trojan-demo

1. サブスクリプションのテキストをローカルで読み込み、まずYAMLまたは平文の共有リンクかどうかを確認します。
2. Base64形式だと確認できてからデコードします。URLセーフな文字セットを使う形式や末尾のパディングを省略する形式もあるため、インポーターでこれらの違いを処理できる必要があります。
3. 各行のプロトコルを判別し、サーバー、認証情報、トランスポート方式などのパラメーターをYAMLノードに対応付けます。
4. プロキシグループとルールを追加し、対象カーネルがすべてのフィールドに対応していることを確認してから、クライアントにインポートします。

デコードに失敗する原因がHTMLページの取得である場合もあります。ログインページへリダイレクトされたり、サーバーからアクセス制限の案内が返されたりするケースです。その場合は、サブスクリプションの期限、レスポンスのステータス、返された内容を確認してください。デコードを重ねても、拡張子を変えても、サーバー側の認証問題は解決しません。

ss・vmess・trojan：変換時に保持すべきフィールド

共有リンクには完全に統一された標準形式があるわけではありません。同じプロトコルでもリンクの書き方が異なる場合があり、変換ツールによってクエリパラメーターへの対応状況も違います。変換の成功とは、構文エラーのないYAMLが出力されることだけでなく、接続に必要な意味が保たれていることです。

Shadowsocks：2種類のエンコードを混同しない

一般的なSIP002リンクでは、@より前のユーザー情報がエンコードされています。旧形式の共有リンクでは、より長い範囲がエンコードされている場合があります。汎用サブスクリプションでは、リンク全体がさらにBase64で包まれていることもあります。「サブスクリプション全体のエンコード」と「個別リンク内のエンコード」を区別してください。リンクにプラグインパラメーターが含まれている場合、アドレスとパスワードだけをコピーすると、接続に必要なトランスポート設定が失われることがあります。

VMess：JSONをデコードした後もフィールドの対応付けが必要

一般的なvmess://リンクには、Base64エンコードされたJSONが含まれています。addは通常サーバー、idはUUID、aidはalterId、netはトランスポート方式に対応します。現在のVMess AEAD設定では通常alterId: 0を使いますが、過去の設定を何でもこの値に変更してよいわけではありません。

元のノードがWebSocketを使う場合は、ws-opts.pathとws-opts.headers.Hostを確認してください。TLSのサーバー名とWebSocketのHostは用途が異なります。値がたまたま同じでも、ひとつにまとめてはいけません。gRPCを使う場合は、grpc-opts.grpc-service-nameも確認しましょう。ノード名の見栄えより、この値を変換ツールが保持できるかどうかが重要です。

Trojan：URIパラメーターを正しくデコード

パスワードや注記に特殊文字が含まれる場合、共有リンクではパーセントエンコードされていることがあります。インポーターはURIの規則に従って解析する必要があり、コロンやシャープ記号でテキスト全体を単純に分割してはいけません。変換後は、パスワード、SNI、ALPNが保持されているか確認しましょう。証明書エラーが発生した場合は、まずシステム時刻とサーバー名を確認してください。skip-cert-verify: trueを安易な解決策として使わないでください。

形式間の変換：ノードは出力できても、ルールは元に戻せるとは限らない

「Base64サブスクリプションをClashに変換」する場合、通常はノードを抽出して設定テンプレートに当てはめます。「Clashを汎用サブスクリプションに変換」する場合は、通常、共有リンクで表現できるノードだけを出力します。どちらも完全に元へ戻せる変換ではありません。プロキシグループ、ルールの順序、DNS、TUNの設定、一部のカーネル固有パラメーターには、汎用共有リンクに対応するフィールドがないことがほとんどです。

変換方法を選ぶ順番

1. まずはネイティブ形式：サービス提供元のサブスクリプション管理ページで、対象カーネルに対応するClash/mihomo形式を選び、余計な変換工程を省きます。
2. ノードが少ない場合は手動入力：プロトコルの各フィールドを確認しながら入力します。1～数個のノードに適しており、TLSやトランスポートの設定も確認しやすくなります。
3. 複数ノードならローカル変換：変換ツールが入力プロトコルと対象カーネルに対応していることを確認し、変換後にノード数、フィールド、警告をチェックします。
4. オンライン変換では認証情報に注意：サービスの運営元とデータの取り扱い方法を確認してください。トークンを含むサブスクリプションURLを、公開ドキュメントや公開設定リポジトリに載せないでください。

• 入力にノードが12個あり、出力が9個しかない場合は、未対応プロトコル、同名ノードの処理、フィルター条件を先に確認しましょう。古い設定をすぐに上書きしないでください。
• すべてのノードを同じ名前にすると、プロキシグループ内の参照が混乱することがあります。名前を変更する場合は、グループ側の参照もあわせて確認してください。
• リモートのproxy-providersを使う設定では、エクスポート時にプロバイダー内のノードまで自動展開されるとは限りません。ツールが実際にどのデータを読み込んだか確認してください。
• 変換テンプレートを変更すると、ルールやプロキシグループも変わります。比較や復元ができるよう、変換前のローカルコピーを残しておきましょう。

「自分のルールを維持したまま、サービス提供元のノードだけ更新したい」場合は、ノードプロバイダーやクライアントのオーバーライド機能を検討してください。完全な設定を毎回往復変換する方法は避けましょう。リモート設定をクライアントから直接編集する場合も注意が必要です。変更内容が次回のサブスクリプション更新で上書きされることがあります。

インポートとトラブル対処：まず形式、次に接続を確認

Clash Verge Revの一般的な画面を例にすると、完全なリモート設定は「サブスクリプション」→「新規作成」でサブスクリプションURLを入力し、保存後に更新して設定を選択します。ローカルYAMLは同じ画面のファイルインポートから読み込めます。ボタンの表示はバージョンによって異なるため、実際の画面に従ってください。他のクライアントでは該当ページが「設定」や「Profiles」と表示される場合があります。個別ノードのインポート画面と完全な設定のインポート画面は使い分けましょう。

インポート後は4つの手順で確認

1. 設定が有効になっているか確認：サブスクリプションまたは設定画面で、現在選択されている設定を確認します。ダウンロードできただけでは、カーネルに読み込まれたとは限りません。
2. 読み込み結果を確認：「プロキシ」画面でプロキシグループとノードの数を確認し、使いたいノードを選択します。グループが空の場合は、ノード参照またはプロバイダーの読み込みに問題がある可能性があります。
3. ローカルの待ち受けポートを確認：設定画面で実際の混合ポートを確認します。この記事の例は127.0.0.1:7890です。実際のクライアントでは別のポートを使う場合があるため、そのまま置き換えないでください。
4. ログを確認：まずYAMLの解析エラー、存在しないプロキシ名、プロバイダーの読み込みエラーを解消し、その後で認証失敗、TLSエラー、接続タイムアウトに対処します。

よくある質問：拡張子の変更、QRコード、サブスクリプション更新

Base64テキストの拡張子を.yamlに変えれば、そのままインポートできますか？

ファイル名を変えるだけでは変換できません。拡張子を変更しても内容の構造はそのままです。まずデコードしてノードを解析し、対象カーネルに合ったYAMLを生成する必要があります。クライアントに汎用サブスクリプションの解析機能が組み込まれていれば、クライアント側で処理できます。ただし、これはクライアント独自の追加機能であり、YAMLパーサーが共有リンクをそのまま受け付けるわけではありません。

QRコードと共有リンクにはどんな関係がありますか？

QRコードには通常、共有リンクがテキストとして格納されていますが、サブスクリプションURLが格納されている場合もあります。読み取ったら、個別ノードのリンクかリモートサブスクリプションURLかを確認してから、適切なインポート画面を選びましょう。QRコードからもパスワードやトークンが漏れる可能性があります。公開する前に、テキストの認証情報と同じように扱ってください。

ローカルファイルに変換した後も、ノードは自動更新されますか？

一度生成したローカルYAMLは、元のサブスクリプションに変更があっても自動では検知しません。再変換してインポートするか、定期取得に対応したリモート設定またはHTTPノードプロバイダーを利用してください。自動更新を続けられるかどうかは、クライアントに保存された更新先URLとスケジュール方式によって決まり、ファイル内に「サブスクリプション」という文字があるかどうかは関係ありません。

最終的に保存する形式はどう選べばよいですか？

ノード、プロキシグループ、ルーティングをまとめて使うなら、完全なClash/mihomo YAMLを保存します。自分のルールを長期的に維持するなら、メイン設定を保存してノードプロバイダーを別に管理します。互換性のあるクライアント間でノードだけを移すなら、共有リンクまたは汎用サブスクリプションを使います。選ぶ基準は、どの情報を残したいかです。エンコードが複雑に見えるかどうかではありません。