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

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

Clashのサブスクリプションを読み込めなくても、すぐにクライアントを変える必要はありません。同じHTTPS URLでも、そのまま使えるYAML設定が返る場合もあれば、Base64文字列やログインページが返る場合もあります。URLの拡張子だけでは形式を判断できません。.yamlが付いていないエンドポイントからYAMLが返ることもあれば、拡張子が付いていても認証切れでエラーが返ることがあります。

サブスクリプションは3つの層に分けて考えると判断しやすくなります。サブスクリプションURLは取得先、Base64はテキストのエンコード方式、YAMLやURIはデータの記述形式です。また、YAMLには完全な設定とノードのみのデータがあります。ノード一覧を完全な設定としてインポートしてしまうのは、よくあるエラーの原因です。

確認できた内容	一般的に考えられるもの	次に行うこと
`proxies:`、`proxy-groups:`、`rules:`	完全なClash設定の可能性	ノード、グループ参照、コアとの互換性を確認する
`proxies:`とノード項目のみ	ノード一覧またはproviderデータ	ノードプロバイダー経由で読み込むか、完全な設定に統合する
複数行の`ss://`、`trojan://`などのリンク	URI形式のノード一覧	ノードのインポートに対応した画面を使うか、形式を変換する
英数字と少数の記号が連続した文字列	Base64でエンコードされたデータの可能性	ローカルでデコードし、結果の形式を確認する
`<html>`、ログイン案内、JSONエラー	WebページまたはAPIのエラーレスポンス	サブスクリプションの有効期限、認証、アクセス制限を確認する

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

YAMLはデータのシリアライズ形式であり、Clash専用ではありません。YAMLパーサーで読み込めることが分かるのは、構文が正しいという点だけです。クライアントはさらに、項目やノードのプロトコル、参照関係も検証します。mihomoベースのクライアントで実際に使える機能は、稼働中のコアによって決まります。画面にClashと表示されているかどうかだけでは判断できません。

最小構成の例

以下の例では、ローカルのプロキシ入口、Shadowsocksノード、選択用グループ、ルールの関係を示します。node.example.invalidは予約済みの例示用ドメインで、パスワードも説明用の値です。実際の接続には使えません。ポート7890はこの例で明示的に設定したローカルの混合プロキシポートであり、すべてのクライアントで使われるとは限りません。

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

proxies:
  - name: "Demo SS"
    type: ss
    server: node.example.invalid
    port: 443
    cipher: aes-128-gcm
    password: "demo-pass"

proxy-groups:
  - name: "手動で選択"
    type: select
    proxies:
      - "Demo SS"
      - DIRECT

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

proxies：サーバーアドレス、プロトコル、ポート、認証情報を設定します。
proxy-groups：ノードや他のポリシーをまとめ、ユーザーが選択したり自動で振り分けたりできるようにします。
rules：上から順に通信を照合します。上の例では、最後のMATCHが残りの接続を受け持ちます。
mixed-port：HTTPとSOCKSのプロキシ入口を提供します。クライアント側の上書き設定で値が変更される場合があるため、実際に適用されている設定を確認してください。

この例は構成を説明するもので、DNS、TUN、LANアクセスのポリシーは含みません。汎用的なネットワーク最適化設定ではなく、DNSリクエストの実際の経路を判断する材料にもなりません。実際の設定をインポートする前に、サービス提供元が指定するトランスポート層や認証項目を維持してください。

YAMLで特につまずきやすい3つのポイント

インデント：スペースを使い、Tabは使わないでください。上の例ではリスト項目を2スペース、ノード属性を4スペース字下げしています。
文字列：特殊記号を含むパスワードやノード名は、引用符で囲むことをおすすめします。引用符で囲まれていない#は位置によってコメントの開始と解釈され、以降の内容が切り捨てられることがあります。
参照：ノード名とプロキシグループ名は完全に一致させてください。Demo SSをDemo-SSに変更した場合、グループ内の参照も合わせて変更する必要があります。

Base64のノードリスト：まずデコードしてからインポート

一般に「Base64形式のサブスクリプション」と呼ばれるものは、複数のURIリンクを改行で連結し、そのテキスト全体をBase64でエンコードしたものです。デコードして得られるのはノード一覧であり、ルールやプロキシグループ、DNS設定が新たに追加されるわけではありません。サービスによっては別の内容をエンコードしていることもあるため、最終的にはデコード結果を確認してください。

標準Base64では+や/がよく使われ、末尾に=が付く場合があります。URLセーフ形式では-と_を使います。末尾のパディングが省略されるAPIもあります。イコール記号がないからといってBase64ではないと決めつけず、HTTPSのサブスクリプションURL全体をデコードしないでください。

デコード結果をローカルで確認する

パソコンにPython 3がインストールされている場合、サブスクリプションから返されたエンコード済みの本文をsubscription.txtに保存し、そのファイルがあるディレクトリで以下のコマンドを実行できます。スクリプトはローカルファイルを読み取り、結果をdecoded.txtに出力します。内容をアップロードすることはありません。出力ファイルにも機密情報が含まれるため、使用後は適切に削除してください。

python3 - <<'PY'
from pathlib import Path
import base64
import binascii

raw = Path("subscription.txt").read_text(encoding="utf-8-sig")
encoded = "".join(raw.split())
encoded += "=" * (-len(encoded) % 4)

try:
    decoded = base64.b64decode(
        encoded, altchars=b"-_", validate=True
    ).decode("utf-8")
except (binascii.Error, UnicodeDecodeError, ValueError) as error:
    raise SystemExit("デコードに失敗しました：入力がBase64テキストか確認してください") from error

Path("decoded.txt").write_text(decoded, encoding="utf-8")
print("decoded.txt に書き込みました。ローカルで確認してください")
PY

このコマンドはUnix系シェルのヒアドキュメント構文を使っており、macOSやLinuxなどで実行できます。Windowsでは、Pythonコード部分をスクリプトとして保存してから実行してください。デコードに失敗した場合は、Webページの内容を誤って保存していないか、コピーが途中で切れていないか、ファイルの外側に付いた引用符までコピーしていないかを確認します。

URIリンク：1つのリンクで1つのノードを記述

URIは通常、ss://、vmess://、vless://、trojan://のようにプロトコル名で始まります。それぞれ内部のエンコード方式は異なります。一般的なVMess共有リンクではJSONをエンコードしてURLに含めますが、ほかのプロトコルではユーザー情報、ホスト、ポート、クエリパラメーターを組み合わせて接続情報を記述します。

Shadowsocksの例：認証情報部分だけをエンコード

ss://[email protected]:443#Demo%20SS

この例では、YWVzLTEyOC1nY206ZGVtby1wYXNzをデコードするとaes-128-gcm:demo-passになります。node.example.invalid:443はサーバーとポート、#Demo%20SSはパーセントエンコードされた表示名です。これは前述の例示用ノードに対応しますが、プロキシグループやルールは含まれていません。

パーセントエンコードはBase64とは別物：%20は空白を表します。URIの各要素としてデコードし、Base64として処理しないでください。
名前と接続設定は別：リンク末尾のコメントは通常、表示名にだけ影響します。一方、クエリパラメーターのトランスポート設定は接続の可否に影響する場合があります。
IPv6アドレスでは角括弧に注意：URIのホスト部分では、通常[IPv6アドレス]:ポートの形式を使います。コロンごとに単純分割することはできません。
Shadowsocksの共有形式には複数の種類があります：認証情報のエンコード方式、旧形式の全体エンコード、プラグインパラメーターなどの対応状況は異なります。変換ツールでは、どの形式かを判別する必要があります。

「コロンを見つけたら分割する」といった処理を安易に使わないでください。パスワードには特殊文字が含まれることがあり、IPv6アドレスにはコロンがあり、WebSocketのパスにはクエリパラメーターが含まれる場合もあります。確実に変換するにはプロトコルごとに解析する必要があり、すべてのリンクに同じ文字列置換ルールを適用することはできません。

形式変換：引き継げる情報と失われる情報

形式変換の要点は、拡張子を変えることではなく、項目を対応付けることです。元の形式にデータが含まれ、変換先の形式とコアの両方が対応している場合に限り、そのデータを完全に引き継げる可能性があります。まず変換先が「ノード一覧」「providerデータ」「完全な設定」のどれなのかを決めてから、方法を選びましょう。

変換方向	実際の処理	主な制約
Base64 → URIリスト	外側のテキストをデコード	ルールやプロキシグループは追加されない
URIリスト → Base64	行ごとに整理して全体をエンコード	外側の形式が変わるだけで、互換性は向上しない
URIリスト → Clash YAML	ノードを解析し、グループとルールを追加	振り分け動作はテンプレート次第で、プロトコル項目を完全に対応付けられない場合がある
完全なYAML → URIリスト	リンク形式に変換できるノードをエクスポート	通常、ルール、DNS、TUN、プロキシグループは失われる
完全なYAML → providerファイル	ノードを抽出し、provider形式で出力	ノードをどう参照するか、メイン設定に定義が必要

変換後に以下の項目を一つずつ確認

基本接続情報：サーバー、ポート、パスワードまたはUUID、プロトコル。ポートは元の値を維持し、すべてのノードを443に変更しないでください。
暗号化とTLS：Shadowsocksの暗号化方式、TLSの有効・無効、SNI、ALPN、証明書の検証設定。テストを通すためだけに、証明書検証を安易に無効化しないでください。
トランスポート層：WebSocketのパスとHost、gRPCのservice nameなど。同じアドレスとパスワードでも、トランスポート層が異なれば接続できない場合があります。
プロトコル拡張：Realityの公開鍵とshort ID、VLESSのflowなどの項目は、変換ツールとコアの両方が対応している必要があります。
名前と参照：ノード名が重複する場合は適切に処理し、名前を変更したらプロキシグループ内の参照も更新してください。ノード一覧だけを変更して参照先の名前が古いままにならないようにします。

オリジナル版Clashとmihomoでは、対応できる機能が異なります。変換先のコアが対応していないプロトコルは、「Clash形式に変換」しても使えるようにはなりません。新しいプロトコルを使う場合は、変換テンプレートを何度も切り替えるより、使用中のコアのバージョンと該当項目のドキュメントを確認しましょう。

インポート方法：完全な設定とノードプロバイダーを分けて扱う

完全なYAML：設定としてインポートして有効化

多くのクライアントでは、完全な設定を「設定」または「Profiles」画面から追加します。メニュー名はクライアントごとに異なるため、「URLから設定をインポート」または「ローカル設定をインポート」を選び、「ノードを追加」と間違えないようにしてください。インポート後は設定を有効にし、実行ログも確認します。リストにファイルが表示されても、現在の設定として使われているとは限りません。

ノードのみ：providerまたは管理された統合を使う

mihomoのプロキシプロバイダーを使うと、ノードの取得元とメイン設定を分けて管理できます。クライアント間の移行を考慮する場合は、proxies:を含むことが明確なYAML providerファイルを優先してください。それ以外の入力形式が使えるかどうかは、使用中のコアのバージョンで確認します。以下の例では、ローカルのノードファイルを参照し、useでノードをプロキシグループに追加しています。

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/nodes.yaml

proxy-groups:
  - name: "サブスクリプションのノード"
    type: select
    use:
      - local-nodes

rules:
  - MATCH,サブスクリプションのノード

./providers/nodes.yamlには、前述のようなproxies:以下のノード一覧を記述します。相対パスの基準はコアの作業ディレクトリやクライアントの管理方法によって異なり、ダウンロードしたファイルの保存先とは限りません。この部分はメイン設定に統合してください。同じ名前のトップレベルキーやプロキシグループを重複して定義しないようにします。

リモートHTTP providerでは、更新URL、キャッシュパス、更新間隔も設定します。interval: 86400とした場合、単位は秒で、24時間ごとに更新されます。リモートのノード一覧とメイン設定は別々に更新されます。前者はノードを更新し、後者はルールやDNSなどの設定全体を上書きする可能性があります。

インポートエラーの対処：応答、構文、コア、実行状態の順に確認

応答内容を確認：ファイルをローカルに保存し、先頭の数行を確認します。HTTPの200はリクエストが成功したことを示すだけで、本文が設定ファイルとは限りません。401や403の場合は、まず認証とアクセス制限を確認してください。サービスによってはUser-Agentに応じて異なる形式を返すため、ブラウザーとクライアントで内容が異なる場合があります。
外側のエンコードを確認：Base64の場合は、まず一度だけデコードして結果を確認してください。やみくもに何度もデコードしたり、サブスクリプションURL、Webページ本文、エンコードされたノードリストを混同したりしないでください。
YAMLの構文を確認：「mapping」「indentation」などのエラーは、インデント、コロン、引用符が原因であることがよくあります。エラーの行番号を記録し、その前後も確認してください。認証情報を含む実際の設定を、オンラインのYAMLチェッカーに貼り付けるのは避けましょう。
項目の対応状況を確認：「unsupported proxy type」は、プロトコルとコアの対応状況が一致していない可能性を示します。まずクライアントが実際に起動しているコアを確認し、そのバージョンと対応プロトコルを調べてください。
名前の参照を確認：「proxy not found」などのエラーでは、ノード名、プロキシグループ名、provider名が一致しているかを確認します。完全な設定にノードがあっても、利用可能なプロキシグループがなければ、想定した振り分けが行われない場合があります。
実行状態を確認：設定が読み込まれたら、ローカルプロキシポート、システムプロキシ、TUNが必要に応じて有効になっているかを確認します。インポートの成功、プロキシ入口の有効化、ノードへの接続は、それぞれ別の確認項目です。

変換後に「ノードの速度テストは通るのに、Webページが開けない」場合も、すぐにエンコードの問題だと決めつけないでください。速度テストの対象は指定されたテスト通信だけです。実際のアクセスにはDNS、ルーティングルール、UDP対応、アプリのプロキシ設定も影響します。失敗した通信がどのルールに一致し、どのノードを選んだのかを確認してから、問題の箇所を特定しましょう。

形式選びの結論：まず対象クライアントでそのまま使えるデータを入手する

そのままインポートして使いたい：サービス提供元が現在のコア向けと明記している、完全なClashまたはmihomo設定を優先し、ルールとDNSの設定を確認してください。
独自のルールを使っている：provider形式のノードデータを使い、メイン設定を独立させることで、サブスクリプション更新によるローカル設定の上書きを防ぎやすくなります。
クライアント間でノードを移行したい：URIリストは個別ノードの受け渡しに便利ですが、プロトコル拡張を一つずつ確認してください。元のポリシーがすべて引き継がれるわけではありません。
Base64テキストを受け取った：まずローカルでデコードして内容を確認します。エンコードは外側の形式にすぎず、インポート方法を決めるのは内部のデータ構造です。

変換が必要な場合は、ローカルで実行できるツールか、自分で管理するサービスを優先してください。外部の変換サービスにはサブスクリプションの認証情報やノード情報が渡る可能性があり、出力に意図しないルールや設定が追加されることもあります。元データ、変換結果、正常に使えるバックアップを保存し、「構造の確認 → 項目の照合 → 有効化してテスト」の順に進めれば、問題が起きた際に戻す場所を明確にできます。