2026-06-17 サブスクリプション読了目安 12分

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

サブスクリプションの読み込みに失敗する原因は、形式の不一致かもしれません。ClashのYAML設定と汎用Base64サブスクリプションの違い、リンク形式の見分け方、変換サービス利用時の注意点を解説します。

まずはサブスクリプションURL、ノード一覧、完全な設定ファイルを区別する

Clashクライアントの「サブスクリプション」は、特定の1種類のファイル形式を指すものではありません。一般に入手するのはHTTPS URLで、クライアントがアクセスすると、サーバーから完全なClash YAML、ノードだけを含むプロキシプロバイダーファイル、またはBase64エンコードされた汎用ノード一覧が返されます。URLの見た目が似ていても、レスポンスの内容は大きく異なる場合があります。

完全なClash設定にはノードだけでなく、待ち受けポート、動作モード、プロキシグループ、ルールセット、DNS、TUN、トラフィック検出の設定などが含まれることがあります。一方、汎用Base64サブスクリプションは通常、ss://、trojan://、vmess://、vless://などのノードURIを伝えるだけです。ノード一覧だけでは、「海外サイトをどのグループ経由にするか」「LANアドレスを直接接続するか」「どのルールにも一致しない通信をどう処理するか」は定義されません。

3つ目によくあるのが、MihomoまたはClashのプロキシプロバイダーファイルです。これもYAMLですが、トップレベルには通常proxies:しかなく、メイン設定のproxy-providersから参照されます。完全な設定として、そのまま起動できるとは限りません。この3種類を区別して初めて、直接読み込むのか、providerとして使うのか、先に形式変換するのかを判断できます。

内容の種類	よくある冒頭またはフィールド	ルールとプロキシグループを含むか	代表的な用途
完全なClash YAML	`mixed-port:`、`proxies:`、`proxy-groups:`	通常含む	クライアントのメイン設定として読み込む
プロキシプロバイダーYAML	トップレベルは主に`proxies:`	通常含まない	`proxy-providers`から定期的に読み込む
Base64ノードサブスクリプション	英字・数字・プラス・スラッシュ、またはURLセーフ文字が連続する長い文字列	含まない	対応クライアントで読み込む、またはClash設定へ変換する
単一ノードURI	`ss://`、`trojan://`、`vmess://`	含まない	ノードを1件ずつ手動で読み込む

Clash YAML設定に含まれるもの

YAMLは読みやすい構造化テキストです。インデントで階層を表し、リスト項目は通常ハイフンで始まります。ClashとMihomoは設定を読み込む際、フィールド名、データ型、インデントの関係を解析するため、半角スペース2つ、真偽値、引用符、コロンの扱いが結果に影響することがあります。ノード名にコロン、シャープ記号、角括弧が含まれる場合は、引用符で囲むほうが安全です。

以下は要素を絞った構成例です。ポート7890とコントロールポート9090は一般的な例であり、すべてのクライアントに共通する固定の初期値ではありません。実際の待ち受けポートは、クライアントの「設定」または実行ログで確認してください。

mixed-port: 7890
allow-lan: false
mode: rule
external-controller: 127.0.0.1:9090

proxies:
  - name: "Tokyo-01"
    type: ss
    server: edge.example.net
    port: 443
    cipher: aes-128-gcm
    password: demo-password

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "Tokyo-01"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,ノード選択
  - GEOIP,LAN,DIRECT
  - MATCH,ノード選択

proxiesは利用可能なノードを定義し、proxy-groupsはノードを手動選択、遅延テスト、フェイルオーバーなどのグループにまとめます。rulesは接続先を上から順に決定します。通常、前のルールに一致しなかった通信はMATCHで処理します。ノードしかなく、プロキシグループやルールがない場合、クライアントが追加テンプレートで補完できることもありますが、これはクライアントまたは変換ツールによる二次処理です。

完全な設定とproviderファイルの違い

プロキシプロバイダーファイルの役割はより限定的です。メイン設定がダウンロードURL、更新間隔、ヘルスチェックを定義し、リモートファイルはノードだけを提供します。interval: 86400は86400秒、つまり24時間ごとに更新する設定です。ヘルスチェックは600秒ごとにテストURLへアクセスします。

proxy-providers:
  airport-main:
    type: http
    url: "https://sub.example.net/clash-provider.yaml"
    path: ./providers/airport-main.yaml
    interval: 86400
    health-check:
      enable: true
      interval: 600
      url: "https://www.gstatic.com/generate_204"

proxies:しかないproviderファイルをメイン設定として直接読み込むと、クライアントがプロキシグループの不足を通知したり、読み込み後に想定した振り分け先が表示されなかったりします。逆に、DNS、TUN、ルールを含む完全な設定をprovider用の場所に入れるのも、providerのデータ構造には適合しません。

Base64サブスクリプションは何をエンコードしているのか

Base64は暗号化ではなく、テキストエンコードです。元のノードURIを限られた文字だけで構成されるテキストに変換し、API経由で扱いやすくします。デコード後は通常、1行につき1ノードとなり、各行をクライアントが対応するプロトコルとして解析します。Base64には標準の文字セットだけでなく、プラスとスラッシュをハイフンとアンダースコアに置き換えたURLセーフ版もあります。

ss://[email protected]:443#Tokyo-01
trojan://[email protected]:443?security=tls#Singapore-02
vless://[email protected]:443?security=tls&type=ws#Los-Angeles-03

これらのURIにはサーバー、ポート、認証情報、通信方式、備考などが記述されますが、Clashのプロキシグループやルールまで統一的に含めることはできません。実行可能な設定を生成するには、変換ツールがテンプレートを追加する必要があります。たとえば、すべてのノードを「ノード選択」という名前のselectグループに入れ、DIRECTと最終的なMATCHルールを追加します。

デコードしても内容が読めないことがある理由

外側のBase64をデコードすると複数行のURIが得られ、その中のvmess://の後ろに、独立したBase64形式のJSONが続いている場合があります。
サーバーがレスポンスをgzip圧縮していることもあります。ブラウザーやcurl --compressedは通常自動的に処理しますが、圧縮された生バイトを直接コピーすると文字化けすることがあります。
レスポンスがエラーページの場合もあります。ログイン切れ、アクセス頻度の制限、トークンの期限切れなどにより、サーバーがサブスクリプションではなくHTMLを返すことがあります。
サブスクリプションがURLセーフBase64を使い、末尾のパディング文字=を省略している場合があります。そのため、一部の厳密なデコードツールではエラーになります。
ノードのプロトコルや拡張パラメータが旧バージョンのClashコアの対応範囲を超えている場合、形式のデコードには成功しても、クライアントが読み込みを拒否することがあります。

手元のサブスクリプション形式を4段階で見分ける

ステップ1：まずクライアントのエラー箇所を確認する

「ダウンロード失敗」と「解析失敗」は同じ問題ではありません。前者は通常、DNS、TLS、ネットワーク接続、HTTPステータスコード、サブスクリプショントークンの段階で発生します。後者はレスポンスを取得できたものの、対象形式として読み取れないことを示します。ログにHTTP 401や403が表示される場合は、まずサブスクリプションURLを更新してください。yaml: line 18、mapping values are not allowed、proxy 2: unsupported typeなどが表示される場合に、内容とコアの互換性を確認します。

ステップ2：リンクの文字列だけで判断せず、レスポンスを保存する

ターミナルからテスト用サブスクリプションをファイルに保存できます。実際のサブスクリプションURLにはアクセス用トークンが含まれることが多いため、公開スクリーンショット、オンラインフォーラム、共有コマンド履歴には貼り付けないでください。以下ではサンプルドメインとデモ用トークンを使います。

curl -L --compressed \
  'https://sub.example.net/api/v1/client/subscribe?token=demo-token' \
  -o subscription.txt

wc -c subscription.txt
head -c 160 subscription.txt

-Lはリダイレクトに追従し、--compressedはサーバーから圧縮された内容を受け取れるようにします。ファイルが数十バイトしかなく、冒頭が<html、{"error"、ログイン案内などの場合、問題はClashの形式ではなくAPIレスポンスにある可能性が高いです。正常なサブスクリプションは数KBから数百KBまで幅があり、統一された長さの基準はありません。

ステップ3：見えるフィールドを確認する

proxies:、proxy-groups:、rules:があれば、通常は完全なClash YAMLです。
トップレベルにproxies:とノード配列しかなければ、通常はprovider YAMLです。
ss://、trojan://、vless://などが複数行にわたって直接現れる場合は、平文のノード一覧です。
本文がBase64文字列の長い1ブロックになっている場合は、デコードしてから前の3項目に沿って判断します。
Webページのタイトル、認証コード画面、ログインフォーム、JSON形式のエラーオブジェクトが表示される場合、サーバーはサブスクリプションデータを返していません。

ステップ4：対象コアを確認する

Clash Premium、Clash Meta、そして後継のMihomoは、完全に同じ設定対象ではありません。Mihomoはより多くのプロトコルフィールド、ルール機能、DNSオプション、TUNパラメータに対応しています。変換時に単に「Clash」という広い対象だけを選ぶと、旧コア向けの控えめな形式が生成されたり、旧クライアントが認識できないフィールドが含まれたりします。Mihomoコアを使うクライアントでは、MihomoまたはClash Metaと明記された出力先を優先してください。

Base64とYAMLを相互変換する方法

方法1：クライアント標準の互換読み込みを使う

一部のデスクトップクライアントは、サブスクリプションの追加時に汎用URI一覧を認識し、ローカル設定を自動生成します。Mihomoコアを採用したクライアントでは、通常「サブスクリプション」または「設定」画面からリモートURLを追加し、クライアントにレスポンスを解析させます。入口は「サブスクリプション」→「新しいサブスクリプション」や「設定」→「URLから読み込む」などと表示されることがあります。読み込み後は、単に「更新成功」と表示されたかだけでなく、設定の詳細を開いてプロキシグループと最終ルールが生成されているか確認してください。

自動互換はすぐ使える点が便利ですが、生成方法はクライアントによって異なります。すべてのノードを手動選択グループに入れるクライアントもあれば、自動遅延テストグループを追加するクライアントもあります。別のクライアントへ移行すると、グループ名、ルール、DNS設定が一致しない場合があります。

方法2：サブスクリプション変換サービスを使う

変換サービスは通常、元のサブスクリプション、出力形式、テンプレートパラメータを受け取り、元データをダウンロードしてノードを解析し、ClashまたはMihomoのYAMLを出力します。一般的には、出力先にMihomoを選び、サブスクリプションURLを入力し、リモート設定テンプレートを指定して、新しいサブスクリプションURLを生成します。以後クライアントがアクセスするのは変換後のURLであり、元のBase64を直接読み込むわけではありません。

テンプレートが最終設定の品質を左右します。少なくとも次の項目を確認してください。

プロキシグループに必要なノードがすべて含まれているか、参照されているのに定義されていないグループ名がないか。
ルールの末尾に、MATCH,ノード選択など妥当なフォールバック項目があるか。
LAN、一般的なプライベートアドレス、ローカルホストのアドレスが、想定どおり直接接続になっているか。
DNS設定が現在のネットワーク環境に合っているか、到達できない上流DNSを誤って使っていないか。
TUN、スニッフィング、IPv6の設定が現在のOSに適しているか。テンプレートから機械的に引き継いでいないか。
出力先が、実際にクライアントで使われているMihomoまたは対応するClashコアになっているか。

方法3：ローカルでデコードして設定テンプレートを適用する

Base64の内容を確認したいだけなら、サブスクリプションを第三者のWebサイトに渡さず、ローカルでデコードできます。以下のPython 3コマンドはファイルを読み込み、不足しているBase64のパディングを補ってdecoded.txtへ出力します。これはデコードだけを行い、URIをClashのノードオブジェクトへ変換するものではありません。

python3 -c "import base64,pathlib; p=pathlib.Path('subscription.txt').read_text().strip(); p += '=' * (-len(p) % 4); pathlib.Path('decoded.txt').write_bytes(base64.urlsafe_b64decode(p))"

head -n 5 decoded.txt

完全な変換には、各プロトコルURIを個別に解析し、TLS、WebSocket、gRPC、Reality、UDP、証明書検証などのパラメータを正しく対応付ける必要があります。手作業でいくつかのフィールドをコピーすると通信方式の設定を漏らしやすいため、少数ノードのデバッグには向きますが、長期運用には適しません。ノードが多い場合は、対象コアへの対応を明確にして継続的に保守されているローカル変換ツールを使うべきです。

変換後にClashまたはMihomoへ読み込む

YAMLを取得しても、現在使えている設定をすぐに上書きしないでください。まず新しい設定として保存し、構文チェックと限定的な接続テストを行います。デスクトップクライアントの一般的な流れは「設定」→「新規作成」または「URLから読み込む」→「更新」→「現在の設定にする」です。クライアントによって名称は多少異なりますが、新しい設定の検証が終わるまで旧設定を残してください。

まずYAMLの構造を確認する

少なくともproxies、proxy-groups、rules内の名前が相互に対応していることを確認します。プロキシグループが存在しないノードを参照したり、ルールが存在しないグループを指定したりすると、起動失敗や振り分け異常の原因になります。YAMLではTabをインデントに使えません。同じ階層では半角スペース2つに統一するのがおすすめです。

次に待ち受けポートを確認する

設定にmixed-port: 7890と記述した場合、システムプロキシもローカルの127.0.0.1:7890を指す必要があります。クライアントがHTTPポート7890とSOCKSポート7891を別々に使う場合、ターミナルの環境変数には対応するプロトコルを選びます。ポートが別のプロセスに使用されていると、ログにaddress already in useと表示されることがよくあります。この場合、形式を変更しても解決しません。

HTTP_PROXY=http://127.0.0.1:7890
HTTPS_PROXY=http://127.0.0.1:7890
ALL_PROXY=socks5://127.0.0.1:7891

最後にルール、DNS、TUNを検証する

プロキシ画面で利用可能なノードを1つ手動選択し、自動ポリシーグループの選択ミスを切り分けます。
接続画面を開き、テストリクエストが想定したプロキシグループに一致していることを確認します。DIRECTやREJECTになっていないかも確認してください。
ログに記録されたドメイン解決結果を確認し、DNSタイムアウトが継続していないかを調べます。
通常のシステムプロキシで検証に成功してからTUNを有効にし、同時に調べる変数を減らします。
TUNを有効にした後は、クライアントに必要なシステム権限があることを確認し、デフォルトルートとLANアクセスが正常かをチェックします。

TUNモードが解決するのは、システムプロキシを参照しないアプリの通信を取り込む問題です。無効なノード、認証情報の誤り、壊れたYAMLを修復するものではありません。変換後に通常のプロキシでも接続できない場合は、TUNを何度も切り替えるのではなく、ノードパラメータ、コアの対応状況、サブスクリプションの有効期限を確認してください。

よくある読み込み失敗と対処法

症状	優先して確認する点	対処方法
サブスクリプション更新直後にYAML解析エラーが表示される	Base64、HTML、またはインデントが壊れた内容が返されている	レスポンスを保存してファイルの冒頭を確認し、対象形式を確定してから再変換する
読み込みは成功したがプロキシ画面が空になる	providerファイルを読み込んでいる、またはプロキシグループがノードを参照していない	トップレベルのフィールドと`proxy-groups`の参照を確認する
ノードはあるがすべてタイムアウトする	ノードの失効、プロトコルフィールドの非互換、DNS、またはネットワーク制限	ノード単位のエラーログを確認し、対象コアと通信パラメータを照合する
変換後、ルールがすべて直接接続になる	テンプレートのグループ名とルールの指定先が一致していない	ルールの第3項目とプロキシグループ名が完全に同じか確認する
サブスクリプション更新で401または403が返る	トークンの失効、権限制限、またはリクエスト方式の不一致	サブスクリプションURLを再取得し、アカウント状態と必要なリクエストヘッダーを確認する
旧クライアントでunsupported proxy typeと表示される	出力に現在のコアが対応していないプロトコルまたはフィールドが含まれている	対応するMihomoクライアントへ更新するか、旧コアに合った出力先を選ぶ
変換URLが1回は使えるが、その後更新できない	一時URLの期限切れ、変換側のキャッシュ、または元トークンの変更	変換サービスの有効期限を確認し、再生成して元URLを照合する

変換を重ねない

元のサブスクリプションを変換サービスAでClash YAMLにし、その結果をサービスBへ渡して再変換すると、ノード名の変更、ポリシーグループの再構築、ルールテンプレートの上書き、パラメータの欠落が起こりやすくなります。できるだけ変換経路は1本に保ち、元のサブスクリプションを目的の変換ツールへ直接渡し、クライアントには最終URLを読み込ませてください。

サブスクリプション更新と設定の上書きを同一視しない

クライアントによっては、リモート設定をベースにローカル上書きを追加できます。ポート、DNS、ルールなどを変更できる場合もあります。リモート更新後にローカル上書きが保持されるかは、クライアントの実装次第です。変更前に、「ダウンロード済みキャッシュファイルの編集」「リモート設定のコピーの編集」「永続的な上書きの追加」を区別してください。そうしないと、次回更新時に元の内容へ戻ることがあります。

形式選びに関する実用的な結論

サブスクリプション提供元がMihomoまたはClash YAMLを直接出力できるなら、現在のコアに合ったネイティブ形式を優先してください。ノードパラメータを完全に表現でき、プロキシグループやルールも含められます。汎用Base64しかない場合に限り、クライアントの互換機能または信頼できる変換ツールでYAMLを生成します。

ルールを自分で管理する場合、比較的安定する構成は、ノードをproviderファイルに置き、ローカルのメイン設定でプロキシグループ、ルール、DNS、TUNを管理する方法です。こうすればノード更新でルールロジックが直接上書きされず、サブスクリプション更新のたびにメイン設定を再生成する必要もありません。providerの更新間隔は86400秒、ヘルスチェック間隔はノード数とネットワーク状況に応じて300〜600秒に設定できます。

トラブル対処では、問題を常に4層に分けて考えます。サブスクリプションURLへアクセスできるか、レスポンスがどの形式か、対象コアが解析できるか、実行後のルールとネットワークが正しいか、の4点です。形式変換が扱えるのは主に第2層と第3層の一部であり、ノードの有効性、ポートの待ち受け、DNS、システムプロキシの確認に代わるものではありません。