1. サブスクリプションURL・エンコード・設定形式
「サブスクリプションリンク」は、コンテンツを取得するための入口であり、決まったファイル形式を指すものではありません。同じHTTPS URLでも、リクエストのパラメーターやクライアントの識別情報に応じて、ノード共有リンクの一覧、ClashのYAML設定、あるいは他クライアント専用の設定が返されることがあります。URLの末尾に .yaml が付いているかどうかだけでは、そのままインポートできるか判断できません。
見分けるには、3つの層を区別する必要があります。URLはコンテンツの取得先、Base64はバイト列をテキストに変換するエンコード方式、設定形式はノード・プロキシグループ・ルールを記述するものです。Base64は暗号化でもプロキシプロトコルでもありません。サブスクリプションをデコードしても元のテキストに戻るだけで、ルールが新たに補われることはありません。
| 主なコンテンツ | 見分けるポイント | 通常含まれる情報 | インポート時の注意 |
|---|---|---|---|
| ノードURI一覧 | ss://、vmess://、trojan:// などのリンクが複数行並ぶ | ノードのアドレス、認証情報、一部の通信パラメーター | クライアントのインポート機能または変換ツールで解析 |
| Base64形式のノードサブスクリプション | 外側は長いエンコード文字列で、デコードするとURI一覧になる | 通常はノード情報のみ | 完全なYAML設定としてはそのまま使えない |
| ClashのYAML設定 | proxies、proxy-groups、rules などのキー | ノード、プロキシグループ、ルール、任意の実行パラメーター | カーネルとの互換性を確認する必要がある |
| プロキシプロバイダーファイル | トップレベルの主な項目が proxies リスト | proxy-providers から参照するノード一覧 | 通常はメイン設定と組み合わせて使う |
| 他クライアントの設定 | 専用のセクション構成またはJSON形式 | そのクライアント用のノードとルーティング設定 | 拡張子を変えるだけではインポートできない |
2. Base64形式のノードリンクに含まれる情報
一般的なノードサブスクリプションでは、複数の共有リンクを1行ずつ並べ、全体をBase64でエンコードします。プロトコルによっては、共有リンクの内部でもBase64を使うため、サブスクリプション全体のエンコードとプロトコル内部のエンコードが重なる場合があります。1回デコードして vmess:// や ss:// が見えても、ノードのパラメーターがすべて展開されたとは限りません。
共有リンクに含まれる主な項目
- 接続情報：サーバー、ポート、パスワードまたはUUID、プロトコルで必要な暗号化方式。
- 通信設定：TLS、SNI、WebSocketのパスとHost、gRPCのサービス名など。含まれる項目はプロトコルや共有形式によって異なります。
- 表示情報：ノード名はURIのフラグメントに含まれ、パーセントエンコードされていることがあります。
たとえば、2つのノードがどちらも 443 番ポートに接続するとします。一方は通常のTLSを使い、もう一方は特定のWebSocketパスも必要です。変換ツールがサーバー、ポート、パスワードしか残さなければ、後者はハンドシェイクに失敗する可能性があります。ポートが同じでも接続パラメーターが同じとは限らず、443 だけでTLSが有効だと判断することもできません。
ノード共有リンクには通常、DNSポリシー、ルールの順序、TUNルーティング、自動プロキシグループの設定までは含まれません。こうしたサブスクリプションをClash設定に変換すると、変換ツールがテンプレートを適用することがあります。そのため、新しい設定に「自動選択」や「地域別グループ」が含まれていても、それは元のサブスクリプションではなくテンプレート由来の可能性があります。
コンテンツを安全に確認する
信頼できるクライアントの設定プレビューやローカルエディターでレスポンスを確認してください。デコードが必要な場合はローカルツールを使い、内容全体を公開端末のログに残さないようにします。デコード後に得られるパスワード、UUID、サブスクリプショントークンも機密情報です。問題を調べる際は、認証情報を削除した構造とエラー行番号だけを共有してください。
3. 完全なYAML設定とノードプロバイダーの違い
YAMLはデータの記述形式であり、ファイルが完全な設定であることを意味しません。Clash系の設定では通常、proxies でノードを定義し、proxy-groups で選択方法をまとめ、rules で接続先を決めます。以下のサンプル設定で、3つの項目の参照関係を確認できます。例のドメイン名とパスワードは実際の接続には使えません。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies:
- name: サンプルノード
type: trojan
server: edge.example.com
port: 443
password: example-password
sni: edge.example.com
skip-cert-verify: false
proxy-groups:
- name: 手動選択
type: select
proxies:
- サンプルノード
- DIRECT
rules:
- DOMAIN-SUFFIX,example.org,DIRECT
- MATCH,手動選択ここでの 7890 は、ローカルのHTTP/SOCKS混合プロキシの待ち受けポートであり、リモートノードのポートではありません。最後の MATCH は、先行するルールに一致しなかった接続を「手動選択」に渡します。変換時にグループ名を変更しても、ルール側の参照を更新しなければ、設定の読み込みに失敗することがあります。
proxy-providersにはメイン設定が必要
プロキシプロバイダーを使うと、ノードの更新とメイン設定を分けられます。mihomoで一般的なYAML形式のプロバイダーファイルは、トップレベルに proxies: を置きます。メイン設定で proxy-providers を宣言し、プロキシグループから use で参照します。ノード一覧だけのファイルは、ルールやプロキシグループを備えたメイン設定とは別物です。
クライアントによっては、ノードだけのコンテンツをインポートする際に既定のグループを自動追加できます。ただし、これはインポート機能であり、すべてのクライアントが対応するとは限りません。リモート設定を選ぶ前に、完全な設定が必要なのか、ノードプロバイダーが必要なのかを確認してください。独自ルールを維持するには、メイン設定とプロバイダーを組み合わせるか、クライアント対応のオーバーライド機能を使う方法があります。サブスクリプション更新で上書きされるファイルを何度も手動編集するのは避けましょう。
4. サブスクリプション変換で失われやすい項目
変換は通常、「元データの解析 → 中間ノードデータの生成 → 出力形式への変換」の順に進みます。どの段階でも認識できない項目は、無視されたり、別の名前に変わったり、既定値に置き換わったりする可能性があります。YAMLを生成できても、それだけでは出力先のカーネルが元のパラメーターで接続できるとは限りません。
| 確認項目 | よくある変化 | 確認方法 |
|---|---|---|
| TLSと通信パラメーター | SNI、ALPN、WebSocketのHostやパスが欠落 | 元のノードと項目ごとに照合し、証明書検証を無効にして対処しない |
| 新しいプロトコルと拡張機能 | 変換ツールが認識できない、または出力先のカーネルが非対応 | 入力側のパーサー、出力先、実行カーネルをそれぞれ確認 |
| プロキシグループとルール | 出力先のテンプレートで再構成され、グループ名や順序が変わる | ルールの宛先が存在するか、MATCHが想定位置にあるか確認 |
| DNSとTUN | 元の設定にある実行時の設定が引き継がれていない | サブスクリプションの原文だけでなく、最終的に適用される設定を確認 |
| サブスクリプションの付加情報 | 通信量や有効期限などのレスポンスヘッダー情報が引き継がれない | 管理画面の表示情報とノードの接続パラメーターを区別する |
Clash、Clash Premium、Clash Meta（現mihomo）では、対応する項目の範囲が完全には一致しません。変換ツールの「Clash」出力は、旧カーネル向けの互換形式である場合もあります。mihomoを使う場合は、必要なプロトコルや項目に明確に対応した出力先を選んでください。ファイル名にMetaが含まれるかどうかだけでは互換性を判断できず、GUIクライアントのバージョンだけからカーネルの対応状況を推測するのも避けましょう。
5. サブスクリプションの変換とインポート手順
- まずはネイティブ形式を選ぶ。プロバイダーが現在のカーネルに対応したClashまたはmihomo設定を提供している場合は、まずそれを直接使いましょう。中間の解析処理を減らせます。正常なYAML設定に、さらに変換を重ねる必要はありません。
- 取得した内容を確認する。レスポンスがノードテキスト、YAML、ログインページ、エラーページのどれなのか確認してください。HTTPリクエストが成功しても、設定が返されたとは限りません。
<!DOCTYPE html>で始まる内容は、通常サブスクリプションとして読み込めません。 - 信頼できる変換環境を選ぶ。変換が必要なら、ローカルで実行するツールか、信頼できるプロバイダーが提供する変換機能を優先してください。オンライン変換サービスに、元のサブスクリプショントークンやノードの認証情報が渡る可能性があります。
- 対象のカーネルとテンプレートを決める。必要なプロトコルを出力できるか確認してから、ルール用テンプレートを選びます。ノード一覧だけが必要な場合は、メイン設定を置き換えるのではなく、出力がプロキシプロバイダー用か確認してください。
- 新しい設定でテストする。現在使えている設定を残し、変換結果は別の設定としてインポートしてください。まず設定の検証結果を確認してからカーネルを起動します。エラーが出た場合はログをもとに原因を調べ、唯一使えるファイルを直接上書きしないでください。
- 最終的に適用される内容を確認する。クライアントが全体設定のオーバーライド、マージ、スクリプト処理を行う場合があります。ダウンロードしたYAMLの原文だけでなく、処理後のグループ名、ルール、DNS、ポートを確認してください。
変換URLに含める元のサブスクリプションURLは、通常パラメーターとしてエンコードする必要があります。元URLに & や # が含まれていると、直接つないだ際にトークンが途中で切れたり、一部が別のパラメーターとして扱われたりすることがあります。ツールの入力欄や標準のURLエンコード機能を使い、URL全体を何度も手動でエンコードしないでください。生成したURLを公開の掲示板に貼るのも避けましょう。
6. インポート後に確認する4項目
1. ノード数と主要パラメーター
元のサブスクリプションにノードが12個あるのに、変換結果が9個しかない場合は、まずプロトコルの対応状況、地域フィルター、重複除去の設定を確認します。次に、使えるノードを少なくとも1つ選び、サーバー、リモートポート、SNI、通信パラメーターを照合してください。ノード数が一致しても、すべての項目が保持されたとは限りません。名前の変更が、名前で絞り込むルールに影響する場合もあります。
2. 設定構文と参照先
YAMLのインデントにはスペースを使い、Tabは使いません。proxy not found のようなエラーが出たら、グループ内の参照とルールの宛先を確認してください。解析エラーの場合は、ログに示された行とその1行前から、インデント、コロン、引用符を確認します。ノード名に特殊文字が含まれる場合は、適切にYAMLの引用符で囲むと誤解釈を防げます。
3. レイテンシ・実際の通信・ルールの適用
レイテンシテストの成功は、そのテストリクエストに応答があったことを示すだけで、すべてのサイトにアクセスできるとは限りません。まずシステムプロキシを使ってブラウザーの通信を確認し、次に接続パネルでルール、プロキシグループ、最終的なノードを確認します。基本的な接続が正常と分かってから、システムプロキシに従わないアプリを経由させる必要があればTUNを設定してください。ルーティング、DNS、形式の問題を一度に混同しないようにしましょう。
4. サブスクリプション更新による上書き
サブスクリプションを手動で一度更新し、独自ルールが残っているか、ノードプロバイダーが更新されたか、プロキシグループからノードを選べるか確認します。HTTPプロバイダーの interval: 3600 は更新間隔を秒単位で指定し、1時間ごとの更新を意味します。GUIクライアントのサブスクリプション更新周期は別の設定である場合があるため、ノードのヘルスチェック間隔と混同しないでください。
7. 形式の選び方とよくある質問
Base64をデコードしても、そのままインポートできないのはなぜですか？
デコードで元に戻るのはコンテンツだけで、Clash設定が組み立てられるわけではありません。ノードURI一覧を取得したら、共有リンクのインポートに対応したクライアントで読み込むか、対象カーネルが読み込めるノード定義に変換する必要があります。拡張子を .yaml に変えても、内部の構造は変わりません。
他クライアントのJSONをClashに変換できますか？
変換ツールがその形式の具体的な構造に対応しているかによります。たとえばsing-boxのJSONには、アウトバウンドだけでなく、独自のDNSやルーティング設定が含まれる場合があります。ノードのパラメーターを変換できても、ルーティングの意味まで一対一で移せるとは限りません。ノードの移行とルールの再構築は分けて確認してください。「JSON対応」を、あらゆるクライアント設定に対応しているという意味に捉えないようにしましょう。
長期利用には完全な設定とノードプロバイダーのどちらが向いていますか？
プロバイダーの既定ルールをそのまま使いたい場合は、ネイティブの完全な設定が手軽です。独自の振り分けルールを長期的に管理する場合は、メイン設定とノードプロバイダーを組み合わせると、更新を分けやすくなります。Base64形式のノードサブスクリプションしかない場合は、変換先を明確にして変換を検討してください。どの方法でも、元の入口を保存し、カーネルの対応範囲を確認したうえで、実際の通信とルールの適用状況を最終確認しましょう。