サブスク形式入門：Clashのサブスクと各種リンク形式を相互変換する方法

サブスクURL、ノードリンク、設定ファイルをまず区別する

「サブスク」は単一のファイル形式ではありません。クライアントに貼り付けるのは通常HTTPS URLで、クライアントがそのURLへアクセスすると、サーバーからBase64テキスト、Clash YAML、JSONなどが返されます。URLは取得先にすぎず、クライアントが解析できるかどうかを決めるのはレスポンス本文の形式です。そのため、同じサブスクURLでもブラウザーでは単なる文字列に見え、クライアントによっては「形式に対応していません」「設定の解析に失敗しました」と表示されたり、読み込み後にノードが表示されなかったりします。

もう一つ混同しやすいのが単一ノードリンクです。ss://、trojan://、vmess://、vless://で始まる内容は、通常1つのプロキシノードだけを表します。一方、サブスク本文では数十件のノードリンクが1つのリストにまとめられている場合があります。Clashのネイティブ設定にはさらにプロキシグループ、ルール、DNS、待受ポートなどの項目が加わるため、単なるノード一覧ではなく、プロキシコアを直接動かせる完全な設定ファイルです。

Clash YAMLと主要ノードリンクに保存される情報

Clash設定は4種類の情報で構成される

基本的なClash設定には、待受設定、ノード、プロキシグループ、ルールが同時に保存されます。従来のClashでよく使われるローカル混合ポートは7890、コントロールポートは9090ですが、これらは一般的な初期値にすぎず、クライアント側で変更されている場合もあります。ノードはproxies、選択・自動速度測定・フェイルオーバーの設定はproxy-groups、ドメインやネットワーク範囲の処理順はrulesに記述されます。

mixed-port: 7890
mode: rule
proxies:
  - name: "Tokyo-01"
    type: trojan
    server: edge.example.net
    port: 443
    password: "example-password"
    sni: edge.example.net
proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "Tokyo-01"
      - DIRECT
rules:
  - DOMAIN-SUFFIX,example.org,ノード選択
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

この例から、「Clashをノードリンクへ変換」すると通常は情報が失われる理由が分かります。Trojan URIにはサーバー、ポート、パスワード、SNIなどの接続パラメータを記述できますが、proxy-groupsやrules全体を保存する共通の場所はありません。変換ツールが単一ノードURIだけを出力すると、プロキシグループの選択ロジック、自動速度測定の間隔、ルールの順序はすべて破棄されます。

ノードURI同士も同じものではない

• Shadowsocks：ss://では主に暗号方式、パスワード、ホスト、ポートを表し、プラグインのパラメータは通常クエリ文字列に記述します。
• Trojan：trojan://では主にパスワード、サーバー、ポート、TLSホスト名、任意のトランスポートパラメータを表します。
• VMess：一般的な共有形式では、JSONをエンコードしてvmess://の後ろに置きます。生成ツールによって項目名や初期値の扱いが異なる場合があります。
• VLESS：vless://では、クエリパラメータにsecurity、type、sni、flowなどを指定することがよくあります。
• Hysteria2とTUIC：クライアントコアのバージョンや項目の対応状況に依存します。旧版のClashコアでは完全に認識できないことが多く、mihomoのほうが対応範囲は広いです。

変換時はプロトコル名だけでなく、トランスポート層、TLS、Reality、WebSocketパス、gRPCサービス名、UDP、クライアントフィンガープリントなどのパラメータも確認してください。同じプロトコルでも拡張項目が異なれば、「読み込みには成功」しても実際の接続はタイムアウトすることがあります。

サブスク変換サービスの実際の処理フロー

サブスク変換は単に拡張子を書き換える処理ではありません。まず元のサブスクを取得し、YAML、JSON、Base64のノード一覧、または複数のプレーンテキストURIのどれかを判定します。次に、入力を内部のノードオブジェクトへ統一的に解析し、フィルタリング、名前変更、並べ替えを行い、最後に対象クライアントの項目規則に従って再シリアライズします。完全なClash設定を出力する場合は、プロキシグループとルールのテンプレートも適用します。

1. 元データを取得：サブスクURLへHTTPリクエストを送り、リダイレクト、圧縮レスポンス、文字コードを処理します。
2. 入力形式を判定：URLのファイル名だけで判断せず、レスポンスヘッダー、テキスト構造、プロトコルの接頭辞を確認します。
3. ノードパラメータを解析：サーバー、ポート、認証、TLS、トランスポート層の項目を統一された構造に整理します。
4. フィルタリングを実行：ノード名、地域キーワード、正規表現に基づいて項目を残したり除外したりします。
5. テンプレートを適用：プロキシグループ、速度測定グループ、ルールプロバイダー、デフォルトのフォールバックルールを生成します。
6. 対象形式を出力：Clash YAML、単一リンクの一覧、その他のクライアントが読み込める構造を生成します。

変換後にノード数が変わる理由

件数が減っても、必ずしもネットワーク障害とは限りません。変換ツールが未対応プロトコル、必須項目が不足したノード、名前が重複する項目を意図的に除外することがあります。たとえば元のサブスクに86件あり、そのうち8件が対象コアの未対応プロトコル、3件にポートがなく、重複除去で2件が統合された結果、73件が出力されるのは説明可能な結果です。より確実な確認方法は、変換ログの「読み込み・スキップ・出力」の3つの数値を比較することです。

件数が増えるのは、テンプレートの展開やサブスクの統合でよく起こります。2つの元サブスクにそれぞれ40件と35件のノードがある場合、統合後は75件になることがあります。ただし、同じノードが「手動選択」「自動速度測定」「フェイルオーバー」の3グループに同時に入るため、プロキシグループ内の参照数はさらに多くなります。グループの参照数を実際のノード数として数えないでください。

クライアントのUser-Agentがレスポンス内容に影響する

一部のサブスクサービスは、リクエストのUser-Agentに応じて異なる形式を返します。クライアントがClashとして申告するとYAMLが返り、通常のブラウザーからアクセスするとBase64テキストや管理画面が返ることがあります。そのため、ブラウザーで見た内容とクライアントが実際にダウンロードした内容が異なるのは珍しくありません。調査時はブラウザー画面だけで判断せず、クライアントログでレスポンスステータスと解析エラーを確認してください。

他形式からClash設定へ変換する

ノードリンクしかない場合はプロキシグループとルールを補う

ss://、trojan://、vless://のリンク群をClash YAMLへ変換する場合、最初に生成されるのはproxiesだけです。設定にproxy-groupsがなければ、画面上でグループを選択できません。rulesがなければ、ルールモードでのトラフィックの行き先も決まりません。最低限使えるテンプレートには通常、手動選択グループ、LAN向けの直接接続ルール、最後のMATCHルールを1つずつ含めます。

ルールの順序は具体的なものから広いものへ保つ必要があります。DOMAIN,api.example.com,DIRECTはDOMAIN-SUFFIX,example.com,ノード選択より前に置き、MATCHは必ず最後に置きます。変換ツールがルールを並べ替えると、本来直接接続すべきドメインが先にサフィックスルールへ一致することがあります。

対象コアが従来のClashかmihomoかを確認する

「Clash形式」にも機能差があります。従来のClashで一般的な項目が、mihomoの全機能を表すとは限りません。mihomoではルールプロバイダー、DNS、TUN、Sniffer、新しいプロトコル関連の項目が追加・拡張されています。mihomo設定を旧コアへ読み込むと、未知のプロキシタイプや項目で直接エラーになったり、一部の任意項目が無視されたりする場合があります。

Clash YAMLを他形式へ書き出すと失われる情報

完全なYAMLを単一リンクの一覧へ書き出す場合、最初に失われるのはグローバル設定です。mixed-port: 7890、LANアクセスの許可、動作モード、外部コントローラー、DNS、TUNの設定は、単一ノードURIには含められません。次に失われるのがノード間の構成関係で、選択グループ、ロードバランシンググループ、自動速度測定グループと、そのテストURL・間隔・許容値などが該当します。

ルールもノードURIへ自然に付加することはできません。ドメイン分岐、IPネットワーク範囲、プロセス名ルール、ルールプロバイダー、最終フォールバック方針は、対象クライアント側で再設定する必要があります。変換先がsing-box JSONのような別の完全設定形式であれば、変換ツールが構造の対応付けを試みることはできますが、両者のルーティング意味は項目単位で一致しないため、手動確認が必要です。

名前と文字エンコードも変わることがある

• URLフラグメント内のスペース、日本語、記号にはパーセントエンコードが必要で、誤ったエンコードは名前の途中切れを招きます。
• Base64には標準文字セットとURLセーフ文字セットがあり、パディングの扱いを誤るとレコード全体をデコードできなくなります。
• 同名ノードはClashのプロキシグループ内で区別しにくいため、変換ツールが通常は連番を付加します。これに伴い、グループ内の参照名も変わります。
• YAMLでコロン、シャープ記号、前後の空白を含む名前には引用符を付けてください。付けないと構文として解釈される可能性があります。

自前のサブスク変換サービスを構築する方法

自前で構築する主な目的は、管理下の環境内でサブスクを解析することです。配置先はローカルPC、家庭内サーバー、プライベートクラウドなどを選べます。どの実装でも、「変換API」と「管理画面」は分けて考えるべきです。前者は元URLと出力形式を処理し、後者はテンプレート、フィルタールール、実行ログを管理します。

ローカル実行は個人での管理に向いている

ローカルサービスは、たとえば127.0.0.1:25500のようにループバックアドレスだけで待ち受け、同じLAN内の他の端末から直接アクセスできないようにできます。クライアントのサブスクURLをローカルAPIへ向け、変換プログラムがリモートのサブスクを取得します。公開サイトへ元のサブスクを送らずに済みますが、PCがスリープしたりサービスが停止したりすると、クライアントの自動更新は失敗します。

サーバー配置ではアクセス範囲を制限する

サーバー方式は複数端末での更新に便利ですが、HTTPS、API認証、リクエストサイズ制限、アクセスログのローテーションを有効にしてください。変換APIで任意のURLを受け付ける場合は、内部ネットワークのアドレスへアクセスする踏み台にされない対策も必要です。少なくともループバックアドレス、リンクローカルアドレス、プライベートネットワーク範囲を拒否し、リダイレクト後の最終アドレスも制限します。

キャッシュ方針にも注意が必要です。上流のサブスクが6時間ごとに更新されるなら、変換キャッシュを15～60分に設定すると、クライアント起動のたびに同じリクエストを繰り返さずに済みます。ただし、キャッシュファイルには完全なノード認証情報が含まれるため、保存権限と期限切れデータの削除を同時に設定してください。ログに完全なクエリ文字列を記録せず、リクエスト時刻、出力形式、ステータスコード、マスキング済みのタスクIDだけを残します。

テンプレートはバージョン管理する

変換サービスを更新すると、デフォルトのプロキシグループ名や項目の挙動が変わる場合があります。clash-template-2026-05.yamlのようにテンプレートへ明確なバージョンを付け、変更のたびにテスト設定で検証してから本番テンプレートを置き換えてください。ノードサブスクとルールテンプレートを分けて保存すれば、上流の更新でローカルの分流ロジックが上書きされるのを防げます。

変換後に行う5段階の検証

1. 構文を検証：まずクライアントへ読み込ませますが、すぐには有効化しません。YAMLのインデント、重複名、プロキシグループの参照にエラーがないことを確認します。
2. ノード数を確認：元のノード数、スキップ数、出力数を記録し、未対応プロトコルと必須項目の不足を重点的に確認します。
3. 単一ノードをテスト：既知の利用可能なノードを1つ選んで遅延を測定し、HTTPSページへアクセスしてTLSとトランスポートパラメータが正常か確認します。80 msや200 msといった遅延値が表示されるだけでは、実際の接続テストの代わりにはなりません。
4. ルールの一致を確認：クライアントの接続ログを開き、直接接続とプロキシ接続を想定したドメインへそれぞれアクセスして、適用されたルールとプロキシグループがテンプレートの設計どおりか確認します。
5. DNSとTUNを検証：まずシステムプロキシをテストし、必要に応じてTUNを有効にします。システムプロキシは正常でTUNだけ異常な場合は、DNSのハイジャック、仮想NICの権限、ルーティングの競合を確認し、すぐにノード変換が原因だと決めつけないでください。

デスクトップクライアントでは、設定画面の名称がバージョンによって異なります。一般的には「設定」→「サブスク」でリモートファイルを更新し、「プロキシ」でプロキシグループを選択します。一部のクライアントでは更新間隔が「設定」→「パラメータ設定」にあります。更新後は、現在有効な設定が本当に新しいファイルへ切り替わっているか確認し、古いキャッシュをテストしていないことを確かめてください。

よくある変換失敗と切り分けの順番

サブスクURLは開けるのに、クライアントでは解析に失敗する

まず、レスポンスがクライアントの必要とする形式か確認します。ブラウザーに正常なWebページが表示されても、HTTPリクエストが成功したことしか分かりません。ログインページ、容量通知、HTMLエラーページが返っていれば、Clashは解析できません。次にレスポンスのステータスコード、リダイレクト後のドメイン、本文の先頭を確認します。YAMLにタブ文字が混入している、インデント階層が誤っている、引用符が閉じていないといった場合も、設定全体の読み込みに失敗します。

読み込めるが、すべてのノードがタイムアウトする

すべてがタイムアウトする場合は、ノードを1つずつ交換する前に変換パラメータを確認します。サーバーアドレス、ポート、TLSのsni、WebSocketパス、gRPCサービス名、Reality公開鍵などを点検してください。元の形式に対象形式では表現できない拡張パラメータがあると、見た目は完全でも接続できないノードが出力されることがあります。

更新後に元のルールとグループが消えた

これは通常、「ノードサブスク」を「完全な設定」としてローカルファイルへ直接上書きした場合に起こります。正しくは、リモートノードをプロキシプロバイダー経由で読み込むか、変換時にローカルテンプレートを常に適用します。変化するのはノードデータ、テンプレートが管理するのはルールとグループというように分離すれば、上流の更新でローカルの分流構成が直接書き換えられることはありません。

ノード名は正常なのに、プロキシグループが空になる

プロキシグループがノード名を静的に列挙しているのか、プロバイダーを参照しているのかを確認します。静的な名前は、空白、大文字・小文字、変換ツールが付けた連番を含めて完全一致が必要です。正規表現でフィルタリングしている場合は、名前変更後に地域名が変わっていないかも確認します。たとえば「Hong Kong」を「香港」に変更した後、Hong Kongだけに一致するフィルターは空の結果になります。

変換方式を選ぶ際の実用的な提案

サブスク提供元がClashまたはmihomo専用URLを用意しているなら、中間変換を減らすため、その形式を直接使うのが優先です。元の形式が対象クライアントと互換性がない、複数の配布元を統合したい、または独自のグループやルールが必要な場合にだけ変換手順を追加します。変換経路が長いほど、トラブル時に確認すべきキャッシュ、テンプレート、項目マッピングが増えます。

少数のノードを一時的に移行するなら、ローカルで単一リンクへ変換できます。複数のサブスクを長期利用するなら、固定テンプレートを作成し、変換ツールのバージョンを記録する方法が適しています。複数端末で自動更新するなら、認証付きのプライベートサービスを構築できます。どの方法でも、最終的な判断基準は「ファイルを生成できたか」ではなく、構文を読み込めるか、ノードパラメータが完全か、ルールが正しく一致するか、更新手順を再現性をもって検証できるかです。