Clash サブスクリプションURL導入ガイド:形式の識別と変換方法

サブスクリプションURLは一種類ではない

多くの人はサブスクリプションURLを受け取ったらそのままクライアントに貼り付けてしまい、結果としてインポートに失敗するかノードリストが空になる。問題の原因はクライアント自体ではなく、リンクの形式がクライアントの想定と合っていないことがほとんどだ。サブスクリプションURLは大きく3種類に分かれるので、まず種類を見分けてから作業に取りかかれば、確認の手間を大幅に減らせる。

1つ目はClashネイティブ設定の直接リンクだ。このURLにリクエストすると、proxies、proxy-groups、rulesなどのフィールドを含むYAMLテキストがそのまま返される。実質的には完全なClash設定ファイルで、サーバー側で必要に応じて生成されているだけだ。この形式はClashやClash Meta(mihomoコア)系クライアントにとって最も扱いやすく、変換なしでそのままインポートして使える。

2つ目は汎用共有プロトコルの集約リンクだ。返される内容はvmess://、ss://、trojan://、ssr://などの複数のノードリンクをつなぎ合わせ、まとめてBase64エンコードしたものになる。この形式はもともとV2rayNやShadowrocketなどのクライアント向けに設計された汎用交換フォーマットで、Clashコア自体はこれを直接解釈できず、まずYAMLに変換する必要がある。

3つ目はサブスクリプション変換サービスが生成する中継リンクだ。ユーザーが元のサブスクリプションURLをオンライン変換バックエンドに渡すと、バックエンドが新しいURLを発行し、そのURLにアクセスするとClashが読めるYAMLが返される。使い勝手は1つ目と同じで「直接インポート」できるが、変換サーバーを一段経由している点が異なり、更新の可否もその変換サーバーが正常に稼働しているかどうかに依存する。

リンクの種類をすぐ見分ける方法

受け取ったリンクがどの種類か分からない場合、最も簡単な方法はリンクをブラウザのアドレスバーに貼り付けて直接アクセスし、返ってくる生のテキストを確認することだ。次の基準で判断できる。

返された内容がproxies:、proxy-groups:、rules:で始まる、またはこれらのキーを含み、読みやすいキーバリュー構造になっている——これはClashネイティブのYAMLなのでそのまま使える。
返された内容が一見雑然とした英数字の羅列で、長さが4の倍数、末尾に1〜2個の=がある——高い確率でBase64エンコードされたノードリストなので、変換が必要になる。
返された内容にvmess://、ss://、trojan://のプレフィックスが目視でそのまま多数見える——これは未エンコードの汎用共有リンク集約なので、同様に変換が必要になる。
レスポンスヘッダーのContent-Typeがtext/yamlやapplication/x-yamlであれば、Clash直接リンクとほぼ確定できる。text/plainの場合は内容を見て判断する必要がある。

ブラウザでの確認が難しい場合は、リンクを直接クライアントに貼り付けて一度試してみるのもよい。多くのクライアントはインポートに失敗すると「設定を解析できません」「形式に対応していません」といったメッセージを表示するので、これを二次確認の手がかりにできる。

各クライアントの導入手順

プラットフォームごとにクライアントの画面デザインは大きく異なるが、サブスクリプションを導入する操作の流れはほぼ共通しており、「URLを貼り付け → 名前を付ける → 保存してダウンロード」の3ステップになる。

Windows / macOSデスクトップクライアント

設定管理またはサブスクリプション管理画面で新規追加のボタンを見つけ、サブスクリプションURLを貼り付け、識別しやすい名前を入力する。確定するとクライアントは即座にリクエストを送って内容を取得する。クライアントが更新間隔のカスタム設定に対応している場合は、12〜24時間ごとに更新するよう設定しておくと、手動更新の失念によるノード情報の期限切れを防げる。

Androidクライアント

Android版は通常メイン画面の設定またはサブスクリプション一覧に追加ボタンがあり、URLの貼り付けまたはサブスクリプションQRコードのスキャンの両方に対応している。QRコード読み取りはパソコンからスマートフォンに共有する場面に適しており、長いURLを手入力する際の入力ミスを避けられる。

iOSクライアント

iOS版はシステムの共有メニューまたはアプリ内貼り付けの2つの経路が中心で、一部のクライアントはSafari拡張機能を通じてページ内のサブスクリプションURLを直接認識してワンタップで導入できるものもあり、手動でのコピー&ペーストを省略できる。

ヒントサブスクリプション名にはプロバイダーの略称と日付を含めておくと、複数のサブスクリプションを同時に管理する際に素早く区別でき、誤削除や誤更新を防げる。

汎用共有形式をClash設定に変換する方法

受け取ったのがvmess:///ss://系の集約リンクだと確認できた場合、一般的な対処方法は2つある。

1つ目はサブスクリプション変換サービスを利用する方法だ。元のサブスクリプションURLをパラメータとして変換バックエンドに渡すと、バックエンドが各ノード情報を解析してClashが認識できるYAMLを再生成し、その生成結果へのアクセスアドレスを新しいサブスクリプションURLとしてクライアントに渡す。この方法はほとんど手動操作が不要だが、変換サーバーが長期的に稼働していることが前提であり、サービスが停止したり制限がかかったりすると、サブスクリプションも連動して使えなくなる。

2つ目はローカルでの手動変換だ。Base64の内容をデコードして平文のノードリストに戻し、Clashのproxiesフィールドの構造に従って1件ずつ書き換える。Shadowsocksノードを例にすると、最も簡単なClashプロキシ項目はおおむね以下のようになる。

proxies:
  - name: "サンプルノード-01"
    type: ss
    server: example.example.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"
    udp: true

手動変換のメリットは第三者サーバーに依存しないことだが、デメリットはノード数が増えるとミスやフィールドの書き漏れが起きやすいことで、基本的にはノード数が少なく長期的な安定性を重視する場面にのみ推奨される。日常的にはネイティブなClash直接リンクか、安定した変換サービスを優先して選ぶべきだ。

ここでClash Meta(mihomoコア)について特に触れておきたい。初期のClashコアと比べてプロトコル対応範囲が広く、Hysteria、TUIC、VLESSなどの新しいプロトコルのノードをネイティブで認識できるため、多くの場合追加の変換なしで直接インポートできる。もし一部のノードが古いコアのクライアントでどうしても認識できない場合は、まずクライアントがMetaコアを使用しているかどうかを確認するとよい。

インポート後にノードリストが空になる場合の確認順序

リンクの種類の判定に誤りがなく、変換もきちんと行ったにもかかわらずノードリストが空のままという場合は、次の順序で1つずつ確認していけば、ほぼ原因を特定できる。

リンク自体が有効かどうかを確認する。 ブラウザで直接一度アクセスし、404や空白ページではなく正常に内容が返ってくるかを確認する。プロバイダー側の契約期限切れやトラフィック使い切りでも、サブスクリプションのエンドポイントが直接失効する。
User-Agent制限がかかっていないか確認する。 一部のサブスクリプションサーバーはリクエストヘッダーからクライアントの種類を判別し、ブラウザやホワイトリスト外のクライアントからのリクエストを拒否する。この場合ブラウザでリンクが開けないことはサブスクリプション自体の失効を意味しないので、クライアント内での更新結果を基準に判断すべきだ。
設定形式のバージョンを確認する。 サブスクリプション内容にクライアントがまだ対応していない新しいフィールドやプロキシ種別が使われている場合、解析時にその部分がまるごとスキップされる。クライアントのバージョンを更新すればたいてい解決する。
システムプロキシのループを確認する。 デバイスで既にグローバルプロキシやTUNモードが有効になっている場合、サブスクリプションを取得するリクエスト自体もプロキシを経由することになり、その時プロキシノードが利用できない状態だとサブスクリプション更新のリクエストも一緒に失敗する。一度プロキシを無効にしてから手動でサブスクリプションを更新し直して確認するとよい。
更新タイムスタンプを確認する。 クライアントには通常サブスクリプションの最終更新時刻が表示される。時刻が変わっていない場合、更新リクエストが実際には送信に成功していないことを意味するので、更新ボタンを何度も押すのではなく、前の4つの手順に戻って1つずつ確認する必要がある。

注意サブスクリプションURLには通常、個人専用の認証パラメータが含まれているため、不用意に転送したり公開の変換ツールページに貼り付けたりしないこと。他人にトラフィックを消費されるリスクがある。

サブスクリプションを長期的に使える状態に保つ習慣

サブスクリプションのインポートに成功したのはあくまで最初の一歩で、長く使い続けるにはいくつかの点に気を配る必要がある。1つは各サブスクリプションに適切な自動更新周期を設定し、ノード情報が古いままにならないようにすること。2つ目はサブスクリプションURLの原文をローカルのメモにバックアップしておき、設定を誤って削除しても復元できるようにすること。3つ目は複数台のデバイスを併用する場合、各デバイスの更新タイミングを少しずらしておき、同時刻の並行リクエストがサブスクリプションサーバーに負荷をかけないようにすること。4つ目はノードが全て使えなくなった場合、まずサブスクリプションが期限切れになっていないか確認し、その上でプロバイダーの変更が必要かを検討する、クライアント自体の不具合を先に疑わないこと。

これらを習慣にしておけば、サブスクリプション関連の問題はたいてい数分以内に自分で解決できるようになり、毎回一から調べ直す必要がなくなる。