まず整理したい「サブスクリプションURL」「データ形式」「プロキシプロトコル」

「サブスクリプションのインポートに失敗」と表示されても、URLが無効とは限りません。同じリンクでも、Clash用YAML、Base64でエンコードされたノード一覧、あるいはログインページが返されることがあります。クライアントは取得したデータの形式を判定し、ノードを解析してから、コアで接続を確立します。どこかで形式が合わないと、インポート失敗やノードの接続不可につながります。

原因を調べるときは、以下の3つを分けて確認しましょう。「サブスクリプションを更新」を何度も押すより効果的です。

  • サブスクリプションURL：設定を取得するためのHTTPまたはHTTPSアドレスです。URLの末尾に .yaml が付いていても、レスポンスの形式までは判断できません。
  • データ形式：ノードや設定をどのような構造で保存しているかを指します。YAML、Base64でエンコードされたURI一覧、SIP008 JSONなどがあります。
  • プロキシプロトコル：実際の接続に使うプロトコルです。Shadowsocks、VMess、Trojanなどがあり、形式を変換してもプロキシプロトコル自体は変わりません。

YAML設定とノードプロバイダーは別もの

YAMLは設定を記述する形式であり、プロキシプロトコルではありません。Clash系の完全な設定には通常、proxies、proxy-groups、rulesなどの項目があります。また、proxy-providersで外部のノード一覧を参照することもできます。サーバーアドレスやパスワードに加え、プロキシグループの選択、ルールの順序、DNS、待ち受けポートなども設定できます。

完全な設定ファイルならルーティングルールも設定できる

以下は構造を見分けるための例です。ドメイン名とパスワードは説明用で、接続には使えません。mixed-port: 7890はローカルの混合プロキシ待ち受けポートを示し、リモートサーバーのポートではありません。

mixed-port: 7890
allow-lan: false
mode: rule
proxies:
  - name: "サンプル SS ノード"
    type: ss
    server: node.example.com
    port: 443
    cipher: aes-128-gcm
    password: "demo-password"
proxy-groups:
  - name: "出口選択"
    type: select
    proxies:
      - "サンプル SS ノード"
      - DIRECT
rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,出口選択

ここでの443はリモート側のポートの例です。ルールは上から順に照合されます。example.orgとそのサブドメインへの接続は直接接続し、それ以外は「出口選択」グループで経路を決めます。インポート後にノードしか表示されず、対応するプロキシグループやルールがない場合は、完全な設定ではなく「ノードのインポート」として読み込まれていないか確認してください。

proxiesだけのファイルはプロバイダー用かもしれない

ノードプロバイダーのファイルでは、トップレベルのproxies:にノード一覧を保存し、メイン設定のproxy-providersから読み込みます。さらにプロキシグループのuseで参照します。完全なルーティング設定は含まれないため、「YAMLだから」という理由だけで、そのまま切り替えられる完全な設定と判断しないでください。

反対に、ノード一覧だけを受け付ける画面へ完全な設定をそのまま入れるのも適切ではありません。ローカルルールを維持しながらプロバイダーのノードだけを更新するには、クライアントが対応するプロバイダー機能やオーバーライド機能を使いましょう。更新のたびにリモート設定全体を手作業で直す必要はありません。詳しくはプロトコルガイドを確認してください。

Base64はノードリンク一覧をエンコードしたもの

「Base64サブスクリプション」と呼ばれるものは、複数のノードURIを1行ずつ並べたテキスト全体をBase64でエンコードしているのが一般的です。デコードすると、ss://、vmess://、trojan://などで始まるリンクが現れます。サブスクリプションによっては、エンコードせずにリンクをそのまま返すものもあります。

  • Base64は暗号化ではありません：内容を入手した人は、通常、サーバーアドレスや認証情報、ノード名を復元できます。
  • ノード情報の中にもエンコードが使われることがあります：URIの認証部分やペイロード自体がBase64でエンコードされている場合があります。サブスクリプション全体をデコードしても、すべての項目が平文になるとは限りません。
  • 拡張項目の対応状況は実装によって異なります：トランスポート層、TLS、プラグインのパラメーター、新しいプロトコル項目などを保持するには、インポーターとコアの両方が対応している必要があります。

Base64はあくまで外側のエンコード形式で、通常Clashのrulesやproxy-groupsは含まれません。これをClash設定に変換したときに追加される「自動選択」「フォールバック」やルーティングルールは、多くの場合、変換テンプレートによるもので、元のノード一覧から復元されたものではありません。

SIP008はShadowsocks向けの構造化サーバー一覧

SIP008はShadowsocksエコシステムで使われるオンライン設定の配信仕様で、JSON形式でサーバー一覧を表します。あらゆるプロキシプロトコルを含む汎用サブスクリプション規格ではなく、Clashのプロキシグループやドメインルールを表現するものでもありません。一般的なSIP008 v1のドキュメントにはversionとserversがあり、各サーバーの項目にアドレス、ポート、暗号方式、パスワード、備考などを記載します。

{
  "version": 1,
  "servers": [
    {
      "id": "c71e2e80-925f-4cf6-a437-ef9b79e9cb17",
      "remarks": "サンプル SS ノード",
      "server": "node.example.com",
      "server_port": 443,
      "method": "aes-128-gcm",
      "password": "demo-password"
    }
  ]
}

Clashのノード形式に変換する場合、通常はserver_portをportに、methodをcipherに、remarksをnameに対応させ、さらにtype: ssを追加します。これは項目のマッピングであり、プロトコル変換ではありません。

項目にpluginやplugin_optsが含まれる場合は、変換先のコアがそのプラグインとパラメーターの記述方法に対応しているかも確認してください。変換ツールがYAMLを出力できても、プラグインのハンドシェイクまで互換性があるとは限りません。接続には、サーバーが該当する方式に対応し、クライアント側の設定も正しい必要があります。

Clash系クライアントが直接インポートできる形式

「コアが設定を読み込むこと」と「GUIクライアントが変換を補助すること」は分けて考えましょう。Clashやmihomoでは、Clash形式のYAML設定が主な入力形式です。一部のGUIクライアントには、共有リンクのインポート、サブスクリプションの判別、テンプレートとの合成機能があります。あるクライアントがBase64に対応していても、すべてのClashクライアントが対応するとは限りません。

取得したデータ 適したインポート方法 確認する項目
Clashの完全なYAML設定 設定ファイルまたはリモート設定としてインポート コアがプロトコルと設定項目に対応しているか
YAML形式のノードプロバイダー メイン設定のproxy-providers プロキシグループのuseでプロバイダーを参照しているか
Base64または平文のURI一覧 クライアントが明示的に対応するノードインポート、または信頼できる変換手順 プロキシグループ、ルール、DNSの補完が必要か
SIP008 JSON SIP008に明示的に対応するインポートまたは変換機能 SSの暗号方式とプラグインパラメーターに互換性があるか

クライアントによってメニューの名称は異なります。「設定ファイルをインポート」「リモート設定を追加」「ノードをインポート」の用途を見分け、ノード共有リンクをHTTPSのサブスクリプションURL専用欄に貼り付けないようにしましょう。初めて設定する場合は、まずクイックスタートガイドに沿って設定をインポートし、その後で形式の互換性を確認してください。

サブスクリプション変換で失われる情報：ノード以外が特に消えやすい

「変換成功」と表示されても、出力ファイルが生成されたという意味であり、元の設定が完全に複製されたとは限りません。まず元の形式が必要な情報を持っているか確認し、次に変換ツールがその情報を保持しているかを確認しましょう。

完全なYAMLからノードリンクへ変換する場合

  • ルールとその順序：DOMAIN-SUFFIX、IP-CIDR、MATCHなどのルールは、通常、個々のノードURIには含まれません。
  • プロキシグループの構成：select、url-test、fallbackの階層や、速度テスト用URL、実行間隔などの設定は、通常保持できません。
  • ローカルの動作設定：DNS、TUN、待ち受けアドレス、混合ポート、コントロールAPIなどの設定は、ノード共有データには含まれません。
  • 外部参照：ルールセットやノードプロバイダー、その更新設定は、エクスポート時に無視されたり、その時点で展開されたノードのスナップショットだけが残ったりする場合があります。

ノード一覧から完全なYAMLへ変換する場合

変換ツールは、ノードをどのグループに入れるか、どのドメインを直接接続にするか、最終的な接続先をどこにするかを別途決める必要があります。結果はテンプレートによって異なります。同じノード一覧から作成した2つの設定でも、ルールが異なれば同じサイトへの接続経路が変わることがあります。原因はノードではなく、ルールの違いかもしれません。

ノード名も確認しましょう。名前の変更、重複の削除、地域別のグループ分けによって、既存ルールの参照先が無効になることがあります。URIエンコードされた名前は、変換時に正しくデコードする必要もあります。インポート時に「プロキシが存在しない」と表示されたら、すぐにすべてのルールを削除せず、proxy-groupsとrulesで参照されている名前を照合してください。

変換してもサーバーにない機能は追加できない

Shadowsocksの項目をTrojanなど別のプロトコル用の項目に書き換えても、元のサーバーがそのプロトコルに対応するわけではありません。同様に、TLSのサーバー名、トランスポートのパス、必須の認証情報が元データにない場合、変換ツールがそれを推測することもできません。ファイルを保存できるまで適当なパラメーターを追加するのではなく、正しい形式のサブスクリプションを取得し直してください。

サブスクリプションの形式判定・変換手順

  1. 元の配布元を記録：サブスクリプションの形式に関する説明と取得日時を記録し、現在使える設定をバックアップします。動作中の設定が保存された唯一のファイルなら、上書きして試さないでください。
  2. レスポンスの内容を確認：ダウンロードが成功したか確認します。<!DOCTYPE html>やログインフォームで始まるレスポンスはWebページであり、プロキシ設定としては使えません。HTTP 200でも同様のケースがあります。
  3. ファイル名ではなく構造を見る：トップレベルにproxies:などがあればYAMLの可能性があります。versionとserversを含むJSONならSIP008かもしれません。長いエンコード文字列の場合は、ローカルでデコードして構造を確認します。
  4. ネイティブ形式を優先：プロバイダーが使用中のコアに対応するClash形式またはmihomo形式を提供している場合は、そちらを取得してください。適切な形式がない場合に限り、信頼できるローカルツールまたは自分で管理する変換ツールを検討します。
  5. 更新経路を維持：YAMLを一度エクスポートしても、それはスナップショットであり、元のURLの更新は自動反映されません。リモート変換URLを使う場合は、変換サービスが継続して利用できることが前提となり、元のサブスクリプションがそのサービスに渡る可能性もあります。
  6. インポート後に項目を照合：元と変換後のノード数、プロトコルの種類、プロキシグループ、最終的なフォールバックルールを比べます。そのうえで、直接接続されるはずの宛先と、プロキシ経由になるはずの宛先を1つずつテストしてください。

たとえば元の一覧に12件あり、変換後に9件しかない場合は、残りの3件が非対応プロトコル、項目不足、重複の除外、名前の競合などでスキップされていないか確認します。この数字は確認手順の例であり、変換時に通常発生する件数減少の目安ではありません。理由が分からないままノード数の減少を受け入れないようにしましょう。

インポート失敗・更新失敗の原因をエラーの層ごとに確認

YAMLの構文エラーが表示される

まずエラー行の前後で、インデント、コロン、引用符を確認してください。YAMLのインデントにはスペースを使い、Tabで代用することはできません。例では特殊文字が構文として解釈されないよう、パスワードを引用符で囲んでいます。レスポンスが実際にはJSONやHTMLなら、YAMLのインデントを直しても解決しません。サブスクリプションの取得先を確認してください。

設定はインポートできるが、ノードがない・接続できない

ファイルがプロバイダー用の内容だけではないか、メイン設定から参照されているかを確認します。ノードがあるのに接続できない場合は、コアのログに「未対応のプロキシタイプ」「不明な暗号方式」「プラグインパラメーターのエラー」などがないか確認してください。形式が正しいことと接続できることは別です。接続にはサーバーの稼働状況、ネットワーク経路、アカウントの有効性も関係します。

編集したルールが更新後に元に戻る

リモート設定を更新すると、通常はダウンロードした内容で設定が置き換わります。リモート設定をローカルで直接編集すると、次回の更新で変更が上書きされることがあります。長期的に維持するルールは、クライアントが対応するオーバーライド、マージ、独立したメイン設定の仕組みに追加し、最終的な読み込み順も確認してください。ルールは上から順に照合されるため、カスタムルールをMATCHの後ろに追加しても、通常は意図した結果になりません。