Clashのサブスクリプション形式を解説：YAML・Base64・プロキシリンクと変換方法

1. 返された内容を確認して、読み込み方法を選ぶ

Clashクライアントでは通常、使用中のコアに対応したYAML設定が必要です。Base64形式のプロキシ一覧や個別のプロトコルリンクは、完全な設定ファイルではありません。ファイル名に「サブスクリプション」と付いていたり、拡張子が .yaml だったりしても、読み込めるとは限りません。形式を決めるのは、サーバーが返すテキストの構造と、クライアントが対応する解析・変換機能を備えているかどうかです。

サブスクリプションURLはコンテンツを取得するための入口であり、決まった形式を指すものではありません。同じURLでも、リクエストパラメーターや User-Agent に応じて返される内容が変わることがあります。ブラウザーにはプロキシリンクが表示され、クライアントにはYAMLが返る場合もあれば、その逆もあります。そのため、「ブラウザーでURLを開けること」と「Clashクライアントで設定を読み込めること」は別々に確認してください。

2. Clash YAMLの基本：ノード、プロキシグループ、ルールの役割

YAMLはシリアライズ形式で、Clashの設定はコアが定める項目の集合です。YAMLとして正しくても、Clashの設定として有効とは限りません。たとえば、message 項目だけのAPIレスポンスはYAMLとして解析できても、利用可能なプロキシ設定は含まれていません。

• proxies：プロトコルの種類、サーバー、ポート、認証パラメーターなどを含むノード定義。
• proxy-providers：ファイルやリモートURLからノード一覧を読み込むプロキシプロバイダー。
• proxy-groups：手動選択、遅延テスト、フォールバックなどの選択方法を定義するプロキシグループ。
• rules：通信を上から順に照合し、DIRECT、REJECT、または定義済みのポリシーに振り分けるルール。
• dns、tun：名前解決や通信の取り込みに関する設定。すべてのノードサブスクリプションに含まれるわけではありません。

項目を確認するための最小構成例

以下は直接接続するルールの設定例です。mixed-port: 7890 はHTTPとSOCKSで共用する待ち受けポートを表します。リモートノードはなく、システムプロキシやTUNも有効になりません。完全な設定とノード一覧の違いを示すための例です。クライアントの画面設定でポートなどが上書きされる場合があるため、実際の値は稼働中の設定で確認してください。

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

proxies: []

proxy-groups:
  - name: LOCAL
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,LOCAL

ここでの MATCH,LOCAL は、定義済みの LOCAL プロキシグループを参照しています。よく使われる MATCH,PROXY も、設定内に PROXY という名前のノードまたはプロキシグループが必要です。自動で用意される組み込みの出口ではありません。ルールだけをコピーしてプロキシグループを含めないと、参照エラーになります。

完全な設定ファイルとプロバイダーファイルは混同しない

ノードプロバイダーファイルは通常 proxies: を中心に構成され、ノード一覧だけを提供します。ルールプロバイダーファイルでは通常 payload: を使います。どちらもメイン設定から参照するもので、プロキシグループや振り分けルールを含む完全なサブスクリプションとして直接使うことはできません。特に、ルールプロバイダーのURLをノード用サブスクリプションの入力欄に設定しないでください。

3. Base64とプロトコルリンク：デコードと変換は別の処理

Base64はエンコード方式であり、暗号化方式でもプロキシプロトコルでもありません。従来型のサブスクリプションでは、複数のプロトコルリンクを1行ずつ並べ、テキスト全体をBase64でエンコードすることがあります。デコードして得られるのはノード情報であり、プロキシグループやDNS、ルールが自動で追加されるわけではありません。

また、プロトコルリンク自体にBase64が使われることもあります。よくあるVMess共有リンクでは、ノードパラメーターを記述したJSONをエンコードし、vmess:// の後ろに付けます。Shadowsocksのリンクにも複数のエンコード形式があります。「サブスクリプション全体のエンコード」と「個別のプロトコルリンク内のエンコード」を混同せず、見慣れたテキストになるまで何度もデコードすることも避けてください。

1. 外側の形式を確認：すでに ss:// などのリンクが1行ずつ並んでいる場合、全体をBase64デコードする必要はありません。
2. ローカルでデコード：エンコードされたノード一覧だと確認できたら、信頼できるローカルツールで内容を確認します。URLセーフ文字やパディングの欠落にも注意してください。
3. 項目を確認：プロトコル、ポート、トランスポート方式、TLSパラメーターを確認します。「ノード名が表示された」だけで判断しないでください。
4. 設定を生成：解析できたノードを変換先のコアの項目に割り当て、プロキシグループとルールを追加します。ここまで行うのがサブスクリプション変換です。

4. サブスクリプション変換：対象コア、テンプレート、認証情報のリスク

変換ツールは通常、ソースの取得、ノードパラメーターの解析、出力形式への変換という3つの処理を行います。ルールテンプレートも適用すると、プロキシグループや振り分けルール、さらにはリモートルールセットへの参照が追加されることがあります。そのため、同じノード一覧でも、使用するテンプレートによって最終的な通信経路が大きく変わります。

サービス提供元が用意した対応形式を優先する

サブスクリプション管理ページに「Clash」「Clash Meta」「mihomo」の選択肢がある場合は、実際に使用するコアに合ったものを選びましょう。Clash Metaは現在mihomoという名称です。旧Clashコアとmihomoでは、対応する項目やプロトコルの範囲が異なります。変換ツールの画面では古い名称が使われている場合もあるため、出力項目と対象コアのドキュメントを確認してください。

変換しても旧コアに新しいプロトコルへの対応が追加されるわけではありません。ノードが対象コアで非対応のプロトコルやトランスポートパラメーターを使っていると、変換ツールがエラーを出したり、ノードを除外したり、項目を破棄したりする場合があります。出力ファイルの拡張子を .yaml に変えても、互換性の問題は解決しません。

公開変換サービスから見える情報

• パス、クエリパラメーター、アクセストークンを含む元のサブスクリプションURL。
• 取得したサーバーアドレス、ポート、パスワード、UUIDなどのノード認証情報。
• サブスクリプションの返却内容に含まれるプラン情報と、変換リクエストに関するアクセス記録。

HTTPSは通信経路を保護しますが、変換サービス自体による入力内容の閲覧は防げません。変換が必要な場合は、信頼できるローカルツールまたはセルフホスト型サービスを優先してください。Webページをローカルに保存しただけでは変換処理もローカルで行われるとは限りません。リモートのバックエンドへリクエストを送信していないか確認しましょう。

変換後に必ず確認する項目

元の内容と照らし合わせて、ノード数、プロトコルの種類、TLSの servername、WebSocketの ws-opts、gRPCの grpc-opts、認証情報が保持されているかを確認してください。接続エラーを解消するために skip-cert-verify を一律で有効にしてはいけません。また、テンプレートによって見覚えのない rule-providers、DNS上流、外部制御設定が追加されていないかも確認します。変換成功は出力が生成されたことを示すだけで、設定が意図どおりとは限りません。

5. Clashクライアントへの読み込みと動作確認

「リモート設定の読み込み」と「個別ノードの追加」を区別してください。多くのClash GUIクライアントでは設定単位で管理するため、任意のプロトコルリンクを直接読み込めるとは限りません。以下ではClash Verge Revの「サブスクリプション」画面を例に説明します。他の製品では「設定」など別の名称が使われ、ボタン名もバージョンによって異なる場合があります。

1. 現在の設定をバックアップ：既存のサブスクリプションURL、ローカルの上書き設定、使用中のプロキシグループの選択を保存します。新しい設定を試すときは古い設定を残しておくと、元に戻せます。
2. リモート設定を追加：「サブスクリプション」を開き、サービス提供元のClashまたはmihomo用URLをURL欄に入力して「インポート」を実行し、追加した設定を選択します。
3. ローカルファイルを読み込む：YAMLファイルがある場合は、クライアントのローカル設定用インポート機能を使います。ディスク上のファイルパスをリモートURL欄に貼り付けないでください。
4. 解析結果を確認：「プロキシ」を開き、プロキシグループとノードが表示されているか確認します。次にログを確認し、設定の読み込み失敗、プロバイダーのダウンロード失敗、ノードの接続失敗を切り分けます。
5. 通信を確認：実際の待ち受けポートを確認してから、システムプロキシを有効にしてブラウザーで接続をテストします。稼働ポートが 7890 の場合、アプリの接続先はサブスクリプションサーバーではなく、ローカルの 127.0.0.1:7890 です。

システムプロキシとTUNは、通信をコアに取り込む方法を決めるもので、Base64形式のノード一覧をYAMLに変換する機能ではありません。読み込みに失敗したときにTUNを何度も切り替えると、原因の切り分けが難しくなります。まず設定を正常に読み込み、その後に通信の取り込み範囲、DNS、ルーティングの問題を確認しましょう。

長期的に使うルールは、クライアントが対応する上書き機能に追加してください。リモートサブスクリプションからダウンロードしたファイルを直接編集しても、次回更新時にサービス提供元の内容へ戻ることがあります。リストをマージする上書きでは、クライアントが追加、先頭への挿入、置換のどれを行うかも確認してください。最終的な MATCH ルールがカスタムルールより前に置かれるのを防げます。

6. 読み込みエラー：発生したレイヤーごとに確認

YAMLのインデントと項目の型

YAMLのインデントにはスペースを使い、Tabは使わないでください。リスト項目には - を残し、マッピングでは通常、コロンの後にスペースを入れます。パスワードや名前にコロン、シャープ記号などが含まれる場合は、YAMLの規則に従って引用符で囲んでください。認証情報は文字列として指定するのがおすすめです。数字だけの値や特殊なテキストが別の型として解析されるのを防げます。

ブラウザーではダウンロードできるのに、クライアントで更新できない

リダイレクト、証明書、リクエストヘッダーの違いを確認し、サブスクリプションの更新に直接接続とプロキシ経由のどちらが使われているか調べます。プロキシ経由でしかサブスクリプションにアクセスできない一方、現在の設定に利用可能なノードがない場合、まだ確立していない接続に更新が依存してしまうことがあります。まずサービス提供元のローカルYAMLで初回読み込みを行い、その後リモート更新の経路を確認してください。

新しいプロトコルを読み込むと非対応と表示される

クライアントの「バージョン情報」でクライアントのバージョンとコアのバージョンを確認してください。両者は別の番号です。プロトコル名、コアのバージョン、エラー内容を正確に記録してから互換性を調べます。インストーラー名にClashとあるだけで、すべての項目に互換性があると判断しないでください。旧Clash向けの設定、mihomoの拡張項目、クライアント独自の上書きスクリプトは、それぞれ分けて確認する必要があります。

手順は「レスポンスの確認 → 形式の判定 → 対象コアとの互換性確認 → 設定の読み込み → 接続確認」の順に進めます。対応するYAMLを入手できた場合、変換は不要です。変換する場合は、項目の欠落を比較できるように元データと変換設定を保存してください。