Clash YAMLサブスクリプションとBase64ノードリンク：形式の違いと変換方法

まず、サブスクリプションURL・応答形式・設定ファイルを区別する

サブスクリプションURLは、コンテンツを取得するための入口にすぎません。https://で始まるURLでも、完全なClash設定が返る場合もあれば、Base64でエンコードされたノード一覧が返る場合もあります。URLに「clash」が含まれているか、ファイル名が.yamlで終わっているかだけでは判断せず、応答本文を確認してください。

リクエストパラメーターやクライアント識別情報、アカウント設定によって、異なる形式を返すサービスもあります。そのため、同じURLでもブラウザーとクライアントで取得内容が異なることがあります。原因を調べる際は、実際に使ったインポート方法、応答本文の種類、クライアントのコアを記録しましょう。ファイル拡張子を何度も変更しても解決にはなりません。

Clash YAMLにはノード以外にプロキシグループとルールも含まれる

完全な設定では、proxiesが接続情報、proxy-groupsが選択方法、rulesがトラフィックの振り分け先を定義します。ノードだけを抽出する変換ツールでは、後者2つが失われます。DNS、待ち受けポート、TUNの設定も、単一ノードURIでは完全に表現できません。

最小構成の例

以下は、一般的なTrojanノードをメイン設定に記述する例です。ドメインとパスワードは構造の説明用であり、実際の接続には使えません。7890はローカルの混合プロキシポート、443はリモートノードのポートです。両者を取り違えないでください。

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

proxies:
  - name: "demo-trojan"
    type: trojan
    server: edge.example.com
    port: 443
    password: "demo-password"
    sni: edge.example.com
    udp: true

proxy-groups:
  - name: "手動選択"
    type: select
    proxies:
      - "demo-trojan"
      - DIRECT

rules:
  - MATCH,手動選択

ここでのMATCH,手動選択はフォールバックルールであり、地域やドメインごとの振り分け設定ではありません。プロキシグループでDIRECTを選ぶと、そのグループに一致する接続は直接アクセスします。例のノードを選んだ場合は、そのノード経由で接続します。

• nameは参照用の名前です。ノード名を変更した場合は、プロキシグループ内の古い名前もあわせて修正してください。
• serverは接続先、sniはTLSハンドシェイクで使うサーバー名です。実際の環境では、両者が異なる場合があります。
• udp: trueを指定すると、そのノードで該当するUDP転送を利用できます。ただし、サーバー側や現在の接続方式がすべてのUDP通信に対応しているとは限りません。

Base64はデコードしてもテキストに戻るだけ。Clashの項目は生成されない

Base64はエンコード方式であり、プロキシプロトコルでも暗号化でもありません。複数行のノードリンクを1つのテキストにまとめられますが、プロキシグループやDNS、ルールが自動で追加されるわけではありません。Base64をデコードしてconfig.yamlとして保存しても、中身がURIの一覧なら、Clashの設定パーサーはメイン設定として読み込めません。

外側と中身の2段階で確認する

1. まず、外側の本文を確認します。proxies:などの構造がそのまま見える場合は、YAMLとして確認し、無理にデコードしないでください。
2. 本文がエンコードされたような文字列なら、ローカルのツールでデコードし、結果が読めるテキストか確認します。
3. デコード結果がss://やtrojan://などで始まる行の一覧なら、通常はノードリストです。各プロトコルの解析と項目のマッピングが必要です。
4. 結果がHTMLのエラーページ、ログイン案内、JSON形式のエラーなら、まずサブスクリプションへのアクセス問題を解決してください。ノード変換を続ける段階ではありません。

たとえば、aGVsbG8=をデコードするとhelloになります。これはエンコード前の文字列に戻せることを示すだけで、有効なサブスクリプションである証拠にはなりません。標準Base64では通常、+、/、末尾の=を使います。URLセーフ形式では-と_を使い、実装によってはパディングを省略することもあります。デコーダーは実際の形式に合わせて処理し、元のノード情報を不用意に置き換えないでください。

サブスクリプション全体のエンコードと、ノード内部のエンコードも区別しましょう。たとえば、一部のShadowsocks URIでは、ユーザー情報の部分にもBase64が使われます。外側をデコードしてss://が得られても、対応するURI仕様に従って解析する必要があります。URI全体を機械的にもう一度デコードしないでください。

単一ノードURIからYAMLへ：接続情報を項目ごとにマッピング

以下のURIは、前述のTrojanの例と同じ基本的な接続情報を表します。「手動選択」プロキシグループもMATCHルールも含まれていません。末尾のフラグメントはノード名です。実際の名前に空白、日本語、特殊文字が含まれる場合は、エクスポーターがURIの規則に従ってエンコードする必要があります。

trojan://[email protected]:443?security=tls&sni=edge.example.com#demo-trojan

プロトコルごとに項目の対応関係が異なる

Shadowsocksでは通常、cipherとpasswordが必要です。VMessではUUID、トランスポート層、TLSの設定がよく使われます。VLESSやHysteria2などでは、変換先のコアが対応しているかも確認が必要です。オリジナルのClashとClash Meta（mihomo）では、対応プロトコルが異なります。「Clash共通」とせず、変換先のコアを明確にしてください。

WebSocketのパスやHostヘッダー、gRPCのサービス名は、実際の接続に必要なパラメーターです。たとえば、mihomoの設定ではnetwork: ws、ws-opts.path、ws-opts.headers.Hostがよく使われます。変換時にサーバー、ポート、パスワードしか残らないと、ノード一覧に表示されてもハンドシェイクに失敗することがあります。

相互変換の前に、ノードだけか設定全体かを決める

Base64またはURIのリストをClash YAMLに変換する

1. 元データをバックアップする。サブスクリプションの原文と、現在使える設定を保存します。トークンを含むサブスクリプションURLは機密情報です。スクリーンショットや公開ログ、問い合わせに添付するファイルに含めないでください。
2. 出力先を確認する。ツールが実際に対応しているClashまたはmihomoの出力先を選び、ノードのプロトコルがそのコアでサポートされているか確認します。
3. ノードを復元して解析する。外側がBase64の場合のみデコードし、各URIのプロトコル、アドレス、認証情報、TLS、トランスポートの設定を確認します。
4. 出力形式を決める。既存設定のノードだけを差し替えるなら、ノード一覧またはプロバイダー用リソースを生成します。単独でインポートするなら、プロキシグループとルールを含むメイン設定を生成します。
5. テンプレートの変更を確認する。変換テンプレートによっては、DNS、ルールプロバイダー、TUNの項目が追加されます。項目ごとに確認し、追加された設定を元のサブスクリプション由来の内容と混同しないでください。

クライアントの「リンクからインポート」が、すべての応答形式に対応しているとは限りません。完全なYAMLが必要な入口、ノードURIをインポートできる入口、別途変換サービスを使う入口があります。現在使っているクライアントの案内に従って選択してください。リンクの名前を変えても、応答本文の形式は変わりません。

Clash YAMLをURIまたはBase64に変換する

1. proxiesから実際のノードを抽出します。メイン設定がproxy-providersを参照している場合は、対応するプロバイダーのリソースを取得してください。プロバイダーのURLをノードアドレスとして扱うことはできません。
2. 各プロトコルのURI仕様に従って接続情報をシリアライズします。変換先のクライアントが対応していない項目は、明示的に記録し、黙って破棄しないでください。
3. 1行に1つのURIを記述します。Base64形式のサブスクリプションを求められる場合に限り、リスト全体を指定の形式でエンコードします。
4. 受信側で再度インポートし、ノード数と主要な項目を確認してから接続テストを行います。

この逆方向の変換では、通常、情報が失われます。proxy-groups、rules、dns、tun、ローカルの待ち受けポートは、ノードURIにエクスポートしても一緒には移行されません。ノードに接続できても、元の設定と同じ通信になるとは限りません。受信側でルーティングポリシーを別途設定してください。

変換後の確認：構文から実際の通信まで

「インポート成功」は、ある入口がファイルを受け付けたことを示すだけです。すべての項目が保持されたことや、すべての接続先に通信できることまでは保証しません。まず設定の構造を確認し、その後にネットワークの問題を切り分けましょう。

手順1：変換先のコアで設定を検証する

mihomoのコマンドラインコアをインストール済みの場合は、設定ファイルのあるディレクトリで次の検証を実行できます。このコマンドは設定を読み込んで検査するもので、プロキシサービスを継続的に起動するものではありません。設定が相対パスのリソースに依存する場合は、必要なファイルも用意し、出力にリソースの読み込みエラーがないか確認してください。

mihomo -t -f ./config.yaml

YAMLのインデント、重複するノード名、プロキシグループからの参照、未対応のプロトコル項目を重点的に確認します。パスワードは引用符で囲むと、#がコメントとして扱われたり、値が別のYAML型として解釈されたりするのを防げます。インデントにはタブではなくスペースを使ってください。

手順2：ノード名だけでなく項目ごとに照合する

• 件数：元のリストと変換後のリストの件数を比べます。フィルタリングや重複削除が行われた項目には、明確な理由が必要です。
• 接続情報：server、port、認証情報、暗号化方式、TLSの設定を照合します。
• トランスポート：WebSocketのパスやHost、gRPCのサービス名など、プロトコル固有のオプションを確認します。
• 参照関係：プロキシグループが既存のノードを参照し、ルールが既存のグループを参照していることを確認します。グループ名の空白や大文字・小文字も一致させてください。
• ローカルの接続先：この例のアプリは、リモートノードの443番ポートではなく、ローカルの127.0.0.1:7890に接続します。

手順3：TCP、DNS、UDPを分けて確認する

まずノードを1つ選び、プロキシを明示的に設定したアプリからHTTPSページにアクセスして、接続ログの送信先とエラーを確認します。遅延テストに成功しても、その時点でのテスト通信が完了したことを示すだけです。動画、ゲーム、すべてのサイトが使える保証にはなりません。名前解決に失敗する場合はDNS設定を確認します。TLSハンドシェイクでエラーが出る場合は、証明書の検証を無効にするのではなく、SNI、システム時刻、証明書を確認してください。

HTTPプロキシではアクセスできるのにゲームが直接接続する場合は、通信の取り込み方法に問題がある可能性があります。ノード形式を変換しても、TUNが自動的に有効になったり、すべてのアプリの通信がプロキシを経由したりするわけではありません。全通信の制御やUDP転送が必要な場合は、TUN、ルーティング、クライアントの権限を別途確認してください。これは実行時の設定に関する問題であり、Base64のエンコード層とは関係ありません。

よくある質問と形式の選び方

選ぶ基準は2つです。ノード、プロキシグループ、ルーティングルールをまとめて移行するなら、変換先のコアに対応した完全なYAMLを使います。ノードだけを共有するなら、受信側が対応しているURIまたはノードリストを使います。各項目の詳しい説明は設定リファレンスを、クライアントの選び方は選び方ガイドをご覧ください。