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

レスポンスの内容を確認してから、読み込み方法を選ぶ

ClashのサブスクリプションURLは設定を取得するためのアドレスで、YAMLやBase64はそのURLから返されるデータの形式です。ブラウザーで開けても、Clash Apple版にそのまま読み込めるとは限りません。まずはプロバイダーがClash用またはmihomo用と明記したURLを使い、汎用ノードサブスクリプションしかない場合に変換を検討してください。Appleシリコン搭載Macでarm64版クライアントを使っても、サブスクリプション形式の要件は変わりません。iPhoneやiPadでは、アプリが対応するプロトコルや設定項目も確認しましょう。

URLに.yamlが付いているかどうかではなく、レスポンス本文を確認してください。同じURLでも、クエリパラメーターやリクエストのUser-Agentによって返される内容が変わることがあります。ブラウザーに表示されるのがログインページで、クライアントが取得する設定ファイルとは異なる場合もあります。

YAML設定：ノード、プロキシグループ、ルールの役割

YAMLは構造化されたテキストで、ノードを並べるだけでは設定として完成しません。Clash系のコアでは、通常proxiesでプロキシノードを定義し、proxy-groupsで選択可能な接続先をまとめ、rulesで通信の振り分け先を決めます。外部ノード一覧はproxy-providersから読み込み、外部ルールセットはrule-providersで宣言してルールから参照します。

見やすい最小構成の例

以下は設定の階層を示す例です。通信はすべて直接接続され、リモートプロキシノードは含まれません。7890はこの例で指定した混合プロキシポートであり、すべてのクライアントの既定値ではありません。allow-lan: falseとループバックアドレスでの待ち受けにより、LAN内の端末からこのポートを利用できないようにしています。

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:
  - DOMAIN-SUFFIX,example.com,手動選択
  - MATCH,DIRECT

• proxies：ノードの種類、サーバーアドレス、ポート、認証情報、TLSなどを設定します。使用できる項目はコアによって異なります。
• proxy-groups：接続先を選ぶためのグループを設定します。ルールで参照するグループ名は実在する必要があります。ノード名やグループ名を変更した場合は、参照先も合わせて修正してください。
• rules：通常は上から順に評価され、最初に一致したルールのポリシーが適用されます。末尾のMATCHは、ほかのルールに一致しない通信の受け皿です。
• dnsとtun：それぞれ名前解決と仮想ネットワークインターフェースの動作を設定します。すべてのサブスクリプションに必要な項目ではなく、「設定を完全にする」ためだけに追加すべきではありません。

YAMLのインデントにはスペースを使い、タブは使わないでください。ノード名に#が含まれる場合や、コロンの後にスペースが続く場合などは、文字列を適切に引用符で囲みます。YAMLパーサーで読み込めても、それは構文として解釈できたというだけです。プロキシの種類やフィールドの値、ポリシーの参照先は、さらにコアで検証する必要があります。

Base64サブスクリプション：エンコードは設定でも暗号化でもない

一般的な汎用サブスクリプションでは、複数のノードURIを改行で連結し、そのテキスト全体をBase64でエンコードします。デコードすると、Shadowsocks、VMess、Trojanなどのノード情報が得られることがあります。ただし、配布元によって形式は異なります。URI一覧をそのまま返すもの、URLセーフなBase64を使うもの、末尾のパディングを省略するものもあります。「英数字が長く続いている」という見た目だけで判断しないでください。

macOSで保存済みの内容をローカル確認する

1. 確認する元のレスポンスをテキストファイルとして保存し、nodes.b64という名前を付けます。ログインページをサブスクリプション本文として保存しないでください。
2. 「Finder」でファイルの保存先を開き、「ターミナル」でそのディレクトリに移動します。共有フォルダー内ではないことを確認してください。
3. 標準的なBase64形式の内容には、次のコマンドを実行して別ファイルに結果を保存します。元のレスポンスを上書きしないようにしてください。

base64 -D < nodes.b64 > nodes.txt

これはmacOS標準のbase64で使うデコード用オプションです。コマンドがエラーになった場合、出力ファイルに一部の内容しか書き込まれていない可能性があるため、そのまま読み込みに使わないでください。まず、元ファイルがすでにプレーンテキストのURIではないか、URLセーフ文字を使っていないか、末尾のパディングが省略されていないかを確認します。対応が必要な場合は、その形式を明示的に扱えるローカルツールを使い、文字をむやみに削除しないでください。

デコードに成功しても、ノードが有効とは限りません。Base64に機密性はなく、デコードしたnodes.txtにパスワード、UUID、サーバー情報が含まれていることがあります。確認後は元ファイルとデコード後のファイルを適切に管理し、クラウドストレージで共有したり、問い合わせフォームに添付したりしないでください。

サブスクリプション変換の流れと主なパラメーター

変換ツールは通常、元のサブスクリプションを取得し、ノードを解析して、絞り込みや名前変更を行い、出力先のプロトコル項目に対応付け、テンプレートを適用して設定を出力します。コアをアップグレードするツールではないため、古いコアに新しいプロトコルを追加することはできません。また、ノード一覧から、プロバイダーが提供していないルールを復元することもできません。

出力形式を選ぶ前に、対象のコアを確認する

1. クライアントのコアを確認します。アプリの「このアプリについて」またはコア情報画面で、コア名とバージョンを確認してください。アプリのバージョンとコアのバージョンは別の情報です。macOSやiOSに対応しているというだけでは判断できません。
2. まずネイティブのサブスクリプションを使います。プロバイダーがClash用とmihomo用のURLを用意している場合は、対象のコアに合うものを選ぶと、途中で変換する必要が減ります。
3. 変換が必要な場合は、信頼できる環境を選びます。できるだけ自分の端末上、または自分で管理するサーバーで実行してください。サードパーティの変換サービスは元のサブスクリプションやノードの認証情報を読み取れる場合があります。HTTPSで保護されるのは通信中のデータです。
4. 出力の範囲を確認します。「完全な設定」か「プロキシ一覧のみ」かを確認し、設定の読み込み機能とプロキシプロバイダー機能のどちらを使うか決めてください。
5. 元の設定を残してテストします。使用中のファイルを直接上書きせず、新しい設定として追加してください。ノード数、プロキシグループ、末尾のルール、接続ログを確認してから切り替えます。

一般的なsubconverterのインターフェースを例に

以下はよく使われるパラメーターの説明で、すべての変換サービスに共通する規格ではありません。選択できる値は、利用するサービスのドキュメントとバージョンで確認してください。特に、すべてのサービスがmihomoという出力先に対応しているとは限りません。

元のURLに&が含まれる場合、そのまま変換リクエストのurl=の後ろに連結すると、続く内容が変換ツール自身のパラメーターとして誤って解釈されることがあります。信頼できるツールで適切に一度だけパラメーターエンコードし、手作業で連結したり、二重にエンコードしたりしないでください。変換用URL自体に元のトークンが含まれることもあるため、同様に機密情報として扱いましょう。

変換後にルールが消えた場合：出力、テンプレート、上書き順を確認

「ノードには接続できるが、すべてのサイトが同じ接続先になる」からといって、必ずしもルールが削除されたとは限りません。ノード一覧しか出力されていない、設定が有効化されていない、モードが全般になっている、元のルールがテンプレートで置き換えられている、といった可能性があります。ノードを何度も変更するより、次の項目を分けて確認しましょう。

手順1：変換結果を確認する

• トップレベルにrules:とproxy-groups:があるか検索します。proxies:しかない場合は、まずリストのみを出力する設定になっていないか確認してください。
• ルールでRULE-SETを使っている場合は、対応するrule-providersの名前が存在するか、リモートリソースのダウンロードに成功したか確認します。
• ルールが参照するポリシー名とプロキシグループ名が完全に一致しているか確認します。スペース、大文字・小文字、名前変更後の文字列も確認してください。
• フォールバックルールの位置を確認します。MATCH,DIRECTが早い段階にあると、その後のルールは適用されません。

手順2：変換テンプレートが元のルールを置き換えていないか確認する

完全なYAMLを変換しても、出力されるルールが元の設定と同じとは限りません。ノードだけを抽出し、独自のテンプレートで設定を再構成する変換処理もあります。変換前後のテキストを別々に保存し、rules、proxy-groups、dns、プロバイダーの宣言を比較してください。配布元が利用可能な完全設定を提供している場合は、直接読み込むほうが元の設定内容を保ちやすいことがあります。

手順3：クライアントで実際に使われている設定を確認する

読み込んだ設定が選択されていること、動作モードが「グローバル」や「直接接続」ではなくルールモードになっていることを確認します。次に、クライアントのオーバーライド、マージ、スクリプト、拡張設定機能を確認してください。サブスクリプションの取得後に、こうしたローカル設定が内容を再度書き換えることがあります。キャッシュ内のサブスクリプションファイルだけを編集しても、次回更新時に上書きされる可能性があります。長期的に保持する変更は、クライアントが明示的にサポートする永続オーバーライド機能に設定してください。

最後に接続ログを開き、特定のドメインについて、適用されたルールと最終的な接続先を確認します。サイトに表示される地域、ノードの遅延時間、ページが開けるかどうかだけでは、ルールが有効になった証拠になりません。ログ上では正しいルールが適用されているのにアクセスできない場合は、DNS、ノードへの接続性、接続先サービスの制限を確認してください。

Mac・iPhone・iPadで読み込み後に確認する項目

Apple製デバイス間で同じサブスクリプションを使えても、すべてのクライアントが同じ設定項目に対応しているとは限りません。特にmihomo独自のプロトコル拡張、ルール、DNSオプションは、ファイルの拡張子がYAMLというだけでは互換性を判断できません。

1. 読み込み形式を確認します。完全な設定はリモート設定の読み込み機能を使い、プロキシ一覧はアプリが対応するノードまたはプロキシプロバイダーの読み込み機能を使います。メニュー名はクライアントによって異なります。ルールセットのURLをノードサブスクリプションとして登録しないでください。
2. 設定の取得元を確認します。サブスクリプションURLがコピー時に途中で切れていないか、不要な日本語の句読点が付いていないか、アクセストークンの期限が切れていないか確認してください。HTTP 401や403が返る場合は、YAMLを変更する前に認証の問題を解決します。
3. 待ち受けポートを確認します。この例では127.0.0.1:7890を使っていますが、実際のアプリでは別のポートを使う場合があります。システムプロキシを有効にする前に、クライアントに表示される待ち受けアドレスを確認し、ブラウザーが待ち受けていないポートを参照しないようにしてください。
4. 通信の取り込みと振り分けを個別に確認します。macOSのシステムプロキシが影響するのは、主にプロキシ設定に従うアプリです。TUNは仮想インターフェース経由で、ルーティングされた通信を受け取ります。iOSでは通常、システムVPN構成を使って通信を取り込みます。サブスクリプションを変換しても、これらの権限が付与されるわけではありません。
5. リモート更新を一度実行します。初回の読み込み後に手動更新し、ローカルのオーバーライドが残っていること、ノードの絞り込みによって一覧が空になっていないこと、ポリシーの参照先が無効になっていないことを確認してください。

サブスクリプション形式に関するよくある質問