Clashのサブスクリプション形式を詳しく解説：設定タイプの判別・互換性の違い・変換の原則
Clash、Mihomo、汎用ノードサブスクリプションの構造の違いを見分け、変換前に確認すべき項目とルールを解説します。
サブスクリプション・設定・エンコードは同じ階層ではない
Clashのサブスクリプションを調べるとき、最初に探すべきなのは変換ツールではありません。まず、URL、レスポンス本文、クライアント設定の関係を整理します。サブスクリプションURLは取得先にすぎません。クライアントがこのURLへリクエストすると、サーバーは完全なYAML設定、ノードだけを含むYAML、1行ずつ並んだ共有リンク、Base64でエンコードされたテキストなどを返す場合があります。URL末尾にファイル拡張子があるかどうかだけでは、レスポンス形式を正確に判断できません。
完全なClash設定は、通信を処理する一連の実行経路を定義します。ノードに加えて、リッスンポート、プロキシグループ、ルール、ルールセット、DNS、TUN、スニッフィング、設定プロバイダーなどを含むことがあります。ノードサブスクリプションが解決するのは「どのプロキシ入口を使えるか」だけであり、ドメインをどのポリシーグループへ送るかを単独で決めたり、端末のDNSやネットワーク制御設定を置き換えたりはできません。
一般的な内容は、次の4種類に分けられます。
- 完全設定：通常は
proxies、proxy-groups、rulesを確認できます。インポートすれば、ルールモードの基本的な実行チェーンをそのまま構成できます。 - ノードプロバイダー設定：主体は
proxies配列であることが多く、メイン設定のproxy-providersから参照されます。完全な設定として単独で動作するとは限りません。 - 汎用共有リンクの一覧：各行に
ss://、trojan://、vmess://などのプロトコルURLが記載されています。直接インポートできるかは、クライアントのサブスクリプション解析機能に左右されます。 - エンコードされたテキスト：Base64はテキストの転送方式にすぎません。デコード後も、それがリンク一覧、YAML、JSON、あるいはサーバーが返したエラーページなのかを確認する必要があります。
レスポンス内容から設定タイプを判別する
形式を判断するときは、ウェブページの説明だけでなく、サブスクリプションリクエストが実際に返した本文を確認します。ブラウザーの開発者ツール、クライアントの更新ログ、レスポンスヘッダーと本文を表示できるコマンドラインツールなどが利用できます。認証が必要なサブスクリプションでは、完全なURLを公開ログ、スクリーンショット、オンライン解析ページへ貼り付けないでください。クエリパラメーターに長期間有効なアクセス認証情報が含まれている可能性があります。
返された内容が設定ではなくウェブページでないか確認する
サブスクリプションURLの無効化、認証期限切れ、アクセス頻度の制限などにより、サーバーがHTMLのログインページ、エラーページ、認証ページを返すことがあります。本文の先頭に <!doctype html> や <html> が現れる場合、YAMLとして解析を続けてはいけません。HTTPステータスが成功でも、本文が有効な設定だとは限りません。通常のウェブページでエラー内容を表示するサービスもあります。
YAMLのトップレベル項目を確認する
構造が比較的整ったClash設定には、次のような骨格が含まれます。具体的な項目はカーネルや用途によって変わりますが、プロキシグループの参照先とルールの対象は整合していなければなりません。
mixed-port: 7890
mode: rule
log-level: info
proxies:
- name: Tokyo-01
type: trojan
server: edge.example.invalid
port: 443
password: example-password
sni: edge.example.invalid
proxy-groups:
- name: PROXY
type: select
proxies:
- Tokyo-01
- DIRECT
rules:
- DOMAIN-SUFFIX,example.org,PROXY
- MATCH,DIRECTproxies でノードを定義し、proxy-groups でノードや他のポリシーグループを選択可能なポリシーとしてまとめ、rules の末尾部分でポリシーグループ、ノード名、組み込みアクションを参照します。ルールが PROXY を指定するなら、設定内に同名のポリシーグループまたは利用可能な対象が必要です。名前は大文字・小文字や空白も区別されるため、変換時に不用意に改名すると参照が切れてしまいます。
リンク一覧とエンコードされた内容を判別する
1行ずつ並んだテキストをデコードした後、プロトコル接頭辞が大量に現れるなら、通常はノードリンクのサブスクリプションです。リンクにはサーバー、ポート、認証情報、一部の通信パラメーターが含まれますが、完全なルール体系までは含まないのが一般的です。表示名がフラグメント識別子に入っているリンクもあります。パーセントエンコードや文字コードの扱いが解析ツールによって異なると、インポート後にノード名が文字化けしたり重複したりすることがあります。
「ランダムな文字列に見える」という理由だけでBase64と断定してはいけません。圧縮データ、JSON、HTML、サーバーからのメッセージを先に除外し、文字コードに合った方法でデコードします。デコードできても、改めて形式を判別する必要があり、デコード成功と設定の利用可能性を同一視してはいけません。
| 確認できる特徴 | 考えられる種類 | 次の手順 |
|---|---|---|
| proxies、proxy-groups、rulesが同時に存在する | 完全なClashまたはMihomoのYAML | カーネル項目の互換性と参照関係を確認する |
| proxies配列だけが存在する | ノードプロバイダーの内容 | メイン設定からproviderとして参照するか、ポリシーとルールを補完する |
| 各行がプロトコルURLで始まる | 汎用ノードサブスクリプション | 対応プロトコルを解析できるパーサーでノード項目を生成する |
| 本文がHTMLタグで始まる | ログインページまたはエラーページ | URL、認証、ステータスコード、リダイレクトを確認する |
| デコード後に初めてYAMLまたはリンクが現れる | エンコードでラップされたサブスクリプション | デコード後の実データを基準に判別を続ける |
Clash、Clash Meta、Mihomoの互換性の境界
「Clash形式」は、常に固定された単一バージョンを指すわけではありません。初期のClashカーネルが一般的なYAML構造を確立し、Clash Metaがそこへプロトコル、ルール、DNS、TUN、ルーティング機能を拡張し、その後のプロジェクト名としてMihomoが使われるようになりました。現在はMihomoをカーネルに採用するクライアントが多い一方、画面やサブスクリプション提供元では今も一般名としてClashが使われています。
互換性の面では、新しいカーネルほど従来の項目を多く読み込めるのが一般的です。ただし、任意のMihomo設定を旧カーネルへそのまま渡せるという意味ではありません。旧カーネルが認識しないプロキシタイプ、通信パラメーター、ルール構文、DNSオプションを1つでも使うと、起動時に項目エラーが出たり、一部の設定が無視されたりします。変換先はクライアント名だけで判断せず、実際に動作するカーネルに合わせる必要があります。
プロキシプロトコルと通信パラメーター
ノードを利用できるかどうかは、カーネルがそのプロトコルとパラメーターの組み合わせを実装しているかで決まります。2つのサブスクリプションに同じ名前のプロトコルが含まれていても、TLSフィンガープリント、Reality、HTTP/2、gRPC、QUICなどの拡張パラメーターは、項目名や対応範囲が異なる場合があります。変換ツールが認識できない項目は、「自動的に互換化」されるのではなく、削除されたり、接続できないノードへ変換されたりするのが一般的です。
ルールプロバイダーのbehavior
rule-providers はリモートファイルのURLだけでなく、behavior、形式、更新間隔、保存先も定義します。よく使われるbehaviorには domain、ipcidr、classical があります。ドメイン集合をIP CIDRの集合として直接使うことはできません。一方、classicルール集合にはタイプ接頭辞付きのルール項目を格納できます。メインルールの RULE-SET 参照名は、プロバイダー名と一致していなければなりません。
DNSとTUNは端末側の実行環境に依存する
DNSとTUNの設定は、OS、権限、ネットワークインターフェース、クライアントの実装と密接に関係します。ノードサブスクリプションのサーバー情報は端末間で移行できますが、TUNインターフェース名、ルート除外項目、DNSのリッスンアドレス、システムプロキシ設定を一括コピーすると、元の端末固有の前提まで移してしまうことがあります。デスクトップOSで使える設定がサーバーに適しているとは限らず、Androidクライアントでは画面側がVPN権限を管理し、デスクトップ向けの項目を一部無視する場合もあります。
サブスクリプション変換前に確認する6項目
変換の目的は、すべての内容を「インポートできる」だけのファイルに押し込むことではなく、元データを対象カーネルが理解できる構造へマッピングすることです。変換を始める前に、少なくとも次の6項目を確認してください。
- 対象カーネルを確認する。クライアントがMihomo、従来のClash互換カーネル、独自の解析レイヤーを持つモバイルクライアントのどれを使っているか記録します。同じサブスクリプションでも、クライアントによってインポート結果が異なる場合があります。
- 入力範囲を確認する。元データが完全な設定、ノード集合、単一の共有リンクのどれなのかを判断します。ノード集合を変換しても、通常はメイン設定側でポリシーグループ、ルール、DNSを用意する必要があります。
- プロトコルと重要項目を洗い出す。各ノードタイプの認証、TLS、SNI、通信方式、UDP対応、拡張パラメーターを確認します。変換後はノード数だけでなく、サンプルを抽出して項目を照合してください。
- 名前による参照を確認する。プロキシグループはノードや他のプロキシグループを参照し、ルールはポリシーの対象を参照します。改名、重複排除、文字の正規化を行う場合は、すべての参照を同時に更新する必要があります。
- ルールの意味を確認する。Clashは設定の上から下へ順番に照合し、ヒットすると停止するため、ルールの順序が結果に影響します。変換時にルールを並べ替えると、通信経路が変わる可能性があります。
- リモート設定とローカル設定を分ける。ノードやリモートルールは定期更新の対象にし、ポート、コントロールインターフェース、DNS、TUN、LANリッスン、認証は端末側のテンプレートで管理するほうが適しています。
ノード数が同じでも変換に失敗する理由
ノード数が示すのは、解析器が同じ数の項目を作成したことだけで、各項目のパラメーターが完全だという保証にはなりません。変換ツールがサーバーとポートだけを残し、SNI、通信パス、プロトコル拡張を欠落させることがあります。また、同名ノードに自動で接尾辞を付けた結果、既存のポリシーグループが古い名前を参照し続ける場合もあります。検証では異なるプロトコルのノードを選んで個別に確認し、接続ログのハンドシェイク段階に出るエラーも確認してください。
ルールを単純なテキスト連結にできない理由
2つのルール一覧をそのまま連結すると、順序の競合が起きることがあります。たとえば前半の広範なドメインルールが先にヒットし、後半の具体的なルールが機能しなくなる場合があります。IPルールはDNS解決を発生させることもあり、具体的な挙動はルールタイプとパラメーターに左右されます。統合時はまず優先順位を決めます。端末固有の例外ルールはより具体的な位置に置き、広範なルールと最終的なフォールバックは後方に配置し、設定全体で最終的な行き先を明確かつ制御可能に保ちます。
オンライン変換サービスに渡す認証情報の範囲
サブスクリプションURLには通常、ノード設定を読み取る権限があります。完全なURLを第三者の変換サービスへ送信することは、そのサービスにサブスクリプションレスポンスへのアクセス権を与えるのと同じです。より安全なのは、信頼できる環境でローカル変換を行うか、サブスクリプション提供元が明示した対象形式を使う方法です。中継サービスを利用する場合は、リクエスト方式、ログの取り扱い、キャッシュ動作を確認し、処理後は提供元の機能に応じてアクセス認証情報を更新してください。
検証と切り戻しができる変換フローを作る
安定した変換フローでは、リモートノード、ローカルのメイン設定、生成結果を分けて保存します。こうすればサブスクリプション更新時にデータソースだけを置き換えられ、検証済みのDNS、TUN、ルール構造まで上書きされません。
手順1：入力元のスナップショットを固定する
元のレスポンスを1回分保存し、取得時刻、レスポンス形式、使用した対象カーネルを記録します。スナップショットは、調査中に「サブスクリプション元が変化した」ことによる影響を切り分けるために使います。保存時はファイルのアクセス権を制限してください。ノードの認証情報が含まれている可能性があります。
手順2：書き換えずに解析する
まず解析器に構造化された結果を出力させ、認識されたプロトコル、ノード名、項目を確認します。この段階ではルールを追加せず、一括改名もしません。特定のノード種別を認識できない場合は、後続のテンプレートでエラーを隠すのではなく、入力元と対象のプロトコル互換性を先に解決します。
手順3：ローカルのメイン設定へマッピングする
ノードを proxy-providers または明示的な proxies データとしてメイン設定へ取り込み、ポリシーグループはローカルのメイン設定側で定義します。プロバイダーを使う場合、ポリシーグループから use でノード集合を参照できるため、サブスクリプションの変更ごとにグループ内の一覧を手作業で更新する負担を減らせます。
proxy-providers:
remote-set:
type: http
url: https://config.example.invalid/profile.yaml
interval: 21600
path: ./providers/remote-set.yaml
health-check:
enable: true
interval: 600
url: https://www.gstatic.com/generate_204
proxy-groups:
- name: PROXY
type: select
use:
- remote-set
proxies:
- DIRECTこの例は構造上の関係を示すものです。実際に使う場合、プロバイダーの返却内容が対象カーネルの要件を満たしている必要があります。ヘルスチェック先、更新間隔、保存先もネットワーク環境に合わせて調整してください。サブスクリプション元がプロバイダー形式ではなく完全な設定を返す場合、URLを proxy-providers に入れるだけでカーネルが自動的にノードを抽出すると考えてはいけません。
手順4：3つの層で検証する
- 構文層：YAMLのインデント、リストの階層、引用符、項目の型が正しいことを確認します。コロン、シャープ記号、特殊文字を含む名前は、引用符で囲むのが安全です。
- 参照層：プロキシグループが参照するノードまたはプロバイダーが存在し、ルールの対象も存在することを確認します。ルールセット名はプロバイダー名と一致していなければなりません。
- 実行層：起動後に、設定の読み込み、プロバイダー更新、DNSクエリ、ノードのハンドシェイク、ルール照合のログを確認し、直接接続とプロキシ通信をそれぞれテストします。
手順5：DNSとTUNを段階的に有効化する
まず通常のシステムプロキシまたは明示したプロキシポートでノードとルールを検証し、次に複雑なDNS設定を有効化し、最後に必要に応じてTUNをテストします。ノード形式、DNS、TUNを同時に変更すると、接続失敗の原因を特定しにくくなります。一度に追加する変数を1グループに絞り、直前の起動可能な設定を残してください。
インポート失敗とノード欠落の確認手順
サブスクリプション更新で解析エラーが表示される
まず、エラーがダウンロード段階で発生したのか、YAML解析段階で発生したのかを確認します。ダウンロード段階ではステータスコード、リダイレクト、認証、レスポンス本文を重点的に確認し、解析段階では該当行付近のインデント、コロン、リスト記号、文字コードを確認します。YAMLは空白で階層を表すため、タブやずれたインデントだけでファイル全体を読み込めなくなることがあります。
インポート後にノードが表示されない
レスポンスが本当にノード集合なのか確認します。ファイルが proxy-providers の定義だけであれば、それはノードを取得する方法を記述しているだけで、ファイル内に proxies が存在することを意味しません。ルール集合だけのファイルからノードが生成されることもありません。クライアントによっては、完全な設定のインポートとノードサブスクリプションのインポートが別の入口に分かれている点も確認してください。
ノードはあるのにポリシーグループが空になる
静的ポリシーグループの proxies リストにはノード名を記述し、プロバイダー型のポリシーグループでは use で対応するプロバイダーを参照する必要があります。変換ツールがノード名を変更したのにグループ内の参照を更新していない場合、クライアントは対象が存在しないと報告することがあります。正規表現で絞り込むポリシーグループでは、フィルター式も確認してください。条件が厳しすぎると全ノードが除外されます。
設定は起動するが、すべての接続に失敗する
まず複雑なルールを迂回し、ノードを1つ直接選んで疎通をテストします。システム時刻、サーバーの名前解決、ポートへの到達性、TLSのサーバー名、通信パラメーターを確認してください。特定のプロトコルだけが失敗する場合は、変換前後のプロトコル拡張項目を重点的に照合します。すべてのノードが同時に失敗する場合は、サブスクリプションの期限、ネットワーク出口、DNS、システムプロキシの制御状態を優先して確認します。
ルールモードで通信先が想定と異なる
ルールログを有効にし、実際にヒットしたルールを確認します。ルールファイルに「存在するはず」の項目だけを見て結果を推測しないでください。より前方のルールですでに照合が完了している可能性があります。ルール集合の更新が成功しているか、behaviorが正しいか、ポリシー対象が想定したグループを指しているかを確認し、最終フォールバックルールが前方に置かれていないことも確認します。
同じサブスクリプションでも端末によって結果が異なる
クライアントのバージョン、カーネル名、カーネルバージョン、サブスクリプションのインポート入口を比較します。インポート前に独自変換を行うクライアントもあれば、YAMLをそのままカーネルへ渡すクライアントもあります。モバイル端末では、バックグラウンド更新、VPN制御、ローカルファイルへのアクセスが制限される場合もあります。URLだけを比較せず、両端末で実際に適用された設定を出力するか、起動ログを確認してください。
Base64のサブスクリプションは、そのままClash設定として使えますか？
エンコード方式だけでは判断できません。Base64をデコードすると、1行ずつ並んだノードリンク、YAML、その他のテキストが現れる可能性があります。クライアントは、デコード後の内容形式と、その中で使われているプロトコルの両方に対応していなければなりません。
Mihomo設定を旧版Clashカーネルへ直接インポートできますか？
基本項目は互換性がある場合もありますが、Mihomoで拡張されたプロトコル、ルール、DNS、TUN項目を旧カーネルが認識できるとは限りません。旧カーネルの対応範囲に合わせて削除またはマッピングし、ルールと接続を改めて検証してください。
サブスクリプション変換後も元のルールを残す必要がありますか？
変換の目的によります。ノードデータだけが必要なら、ルールはローカルのメイン設定で一元管理できます。完全な設定を移行する場合は、ルールの順序、ルール集合、ポリシー対象の関係を維持する必要があり、ルールのテキストだけをコピーしてはいけません。
サブスクリプション更新で手動変更が上書きされるのはなぜですか？
ダウンロードしたサブスクリプションファイルを直接編集すると、次回の更新時にリモート側の内容で再書き込みされるのが一般的です。端末固有の設定は独立したメイン設定に置き、プロバイダー経由でリモートノードを参照するか、クライアントが対応するオーバーライド機能を利用してください。
形式判別の最終チェックリスト
サブスクリプションの変換後は、決めた手順で再確認できます。レスポンスがウェブのエラー画面でないことを確認し、実際の内容形式を判別し、対象カーネルを照合し、プロトコル項目を抽出確認し、ノードとポリシーグループの参照を検証し、ルール順を確認してから、DNSとTUNを個別にテストします。問題が起きたら、最初に異常が現れた階層へ戻り、変換ツールを何度も替えることは避けてください。
長期利用では、すべての項目をリモートサブスクリプションへ詰め込むより、更新頻度の高いノードデータと端末固有のローカル設定を分離するほうが安定します。これによりサブスクリプションの変更を継続的に受け取りながら、検証済みのルールチェーン、ポート、DNS、ネットワーク制御方式を維持できます。