ClashのサブスクリプションURLをインポートする方法：URL・Base64・YAMLの違い

URLと取得内容を見分ける

Clashのサブスクリプションをインポートする前に、まず確認したいのは、手元にあるものがダウンロード用URLなのかノード情報そのものなのか、そしてURLから取得できるのが完全な設定ファイルなのかノード一覧だけなのか、という点です。「URLにはアクセスできるのにクライアントでインポートできない」という問題は、ここでつまずいていることが少なくありません。

URLは場所を示すもので、YAMLとBase64は内容の形式やエンコード方式です。これらは同じ種類の概念ではありません。https://で始まるサブスクリプションURLからは、Clash用YAML、Base64でエンコードされたノード一覧、アカウントのログインページなどが返される可能性があります。拡張子やURLの長さ、ブラウザーで開けるかどうかだけでは、クライアントとの互換性は判断できません。

完全なYAML設定とノード一覧の違い

完全な設定はノードの一覧だけではない

そのまま使えるClash設定には、接続情報に加えて、トラフィックをどのようにコアへ渡すか、ルールをどのポリシーグループに割り当てるか、ルールに一致しない場合にどの経路を使うかを定義する必要があります。代表的なフィールドにはmixed-port、mode、proxy-groups、rules、dnsがあります。コアによって対応するフィールドは異なるため、設定にフィールドが含まれていても、すべてのクライアントで認識されるとは限りません。

以下はフィールドを確認するためのYAML例で、プロキシノードを含むサブスクリプションではありません。7890は待ち受けポートの例であり、使用中のクライアントも同じポートとは限りません。MATCH,DIRECTは、このルールに到達したリクエストを直接接続します。

mixed-port: 7890
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

インポート時は元ファイルの階層構造と空白によるインデントを保ち、ウェブページに表示されたリッチテキストをそのまま設定として使わないでください。YAMLのインデントにはTabではなく半角スペースを使います。パーサーが示す行番号は調査の手がかりです。実際のエラーは直前の行にある場合もあります。たとえば、引用符の閉じ忘れ、コロンの後の区切り不足、リスト項目のインデントずれなどです。

YAMLでも、provider用ファイルの場合がある

URLによっては、トップレベルにproxies:とノード一覧だけを含む内容が返されます。これは通常、proxy-providersで使うもので、ポリシーグループや振り分けルールを含む完全な設定とは異なります。メイン設定でproviderを定義し、ポリシーグループからuseで参照する必要があります。完全な設定としてインポートすると、解析は成功しても、想定したポリシーグループや振り分けが使えないことがあります。

そのため、サービス提供元に「Clash設定」と「ノードプロバイダー」の2つの選択肢がある場合、初めての方は前者を選びましょう。後者を使うのは、自分でメイン設定を管理する場合です。フィールドの意味は、当サイトの設定フィールドのドキュメントで確認できます。ファイル拡張子だけで用途を判断しないでください。

各プラットフォームでサブスクリプションURLをインポートする方法

ここでは、よく使われるクライアントの画面に沿って説明します。メニュー名はバージョンによって異なる場合があります。表記が見つからない場合は、ノード一覧の検索欄ではなく、「サブスクリプション」「設定」またはProfilesの画面を探してください。初回インポート前に、現在使えている設定を残しておき、古い設定を削除してから試すことは避けましょう。

Windows・macOS：Clash Verge Revの場合

1. サービス提供元のサブスクリプション画面でClash用、またはmihomo対応と明記された形式を選び、HTTPSのサブスクリプションURL全体をコピーします。アカウント管理画面のURLとは異なるので注意してください。
2. Clash Verge Revの「サブスクリプション」画面を開き、URL入力欄に貼り付けて「インポート」をクリックします。画面に「新規作成」がある場合は、リモートを選び、名前とURLを入力します。
3. リモート設定のダウンロードが完了したら、その設定を選択します。一覧に追加されただけでは、現在使用中の設定になっていない場合があります。
4. 「プロキシ」画面を開き、想定したポリシーグループが表示されていることを確認して、グループ内の接続先を選びます。ルールに基づいて通信を振り分ける場合は、動作モードを「ルール」にします。
5. 必要に応じてシステムプロキシまたはTUNを有効にし、接続ログを確認します。初回の動作確認では、DNS、ルール、TUNの設定を同時に変更しないでください。どの変更が反映されたのか分かりにくくなります。

Linuxで同じクライアントを使う場合、サブスクリプションのインポート手順は同じです。異なるのは主に、システムプロキシやTUNに必要な権限、サービスのインストール方法です。サブスクリプションをダウンロードできることと、システムの通信がプロキシを通ることは別々に確認してください。

Android：設定のインポートとVPNの起動を区別する

旧版のClash for Androidでは、「設定」→「＋」→「URLからインポート」が一般的な手順です。名前とURLを入力して保存し、設定一覧に戻ったら、追加した設定を選んでからメイン画面に戻り、起動します。初回起動時にシステムのVPN許可が表示されたら、対象の通信を処理するために許可してください。このプロジェクトはすでにメンテナンスが終了しています。新しいプロトコルや設定フィールドを使う場合は、互換性を事前に確認しましょう。

FlClashなど、現在もメンテナンスされているクライアントでは、「設定」画面から追加またはURLインポートの項目を探します。手順は同様に「URLを追加 → ダウンロード → 設定を選択 → 起動」です。AndroidのVPNアイコンが表示されても、サブスクリプションが正しく読み込まれた証拠にはなりません。VPNサービスが動作中であることを示すだけです。

iOS：クライアントが対応する形式を確認する

iOSクライアントには、共通のClashインポートメニューがあるわけではありません。まずアプリの説明を確認し、完全なClash YAML、ノードサブスクリプション、単一ノードURIのどれに対応しているかを確かめてから、「サブスクリプションを追加」または「設定をインポート」を使います。同じプロキシプロトコルに対応していても、同じ設定ファイルを読み込めるとは限りません。

サブスクリプション画面に「クライアントで開く」ボタンがある場合も、アプリを開いた後にインポート名と接続先URLを確認してください。システムの共有メニューにアプリが表示されても、そのアプリが現在の内容を解析できるとは限りません。クライアントを変更する場合は、まずクライアントのダウンロードページで対応プラットフォームとコアの種類を確認できます。

Base64形式や単一ノードの扱い方

Base64をデコードしても振り分けルールは生成されない

Base64はエンコード方式であり、暗号化ではありません。ノード一覧をエンコードすると長い文字列に見えますが、デコードしても通常は複数行のノードURIが得られるだけです。proxy-groups、rules、DNS設定が自動で追加されるわけではありません。リストによっては末尾のパディング文字が省略されていたり、URLセーフな形式が使われていたりするため、簡易的なオンラインデコーダーではエラーになることもあります。

最も簡単なのは、サービス提供元の画面に戻り、Clashまたはmihomo用のサブスクリプション形式を選ぶことです。対応形式がない場合に限り、変換を検討しましょう。URLにformat=clashを追加して試すのは避けてください。形式を指定するパラメーターはサーバー側で決まり、すべてのサブスクリプションサービスに共通する書き方はありません。

単一ノードをインポートできても、自動更新されるとは限らない

ss://、vmess://、trojan://などのURLには、通常、サーバー、ポート、認証情報、通信パラメーターが含まれます。インポートするクライアントは、該当するプロトコルとURIのパラメーター形式の両方に対応している必要があります。新しいプロトコルの中にはmihomoなどのコアが必要なものもあり、古いClashコアではプロトコル名を変えるだけで互換性を得ることはできません。

手動でインポートしたノードは、通常その時点の情報を保存したものです。サーバー側でポートや認証情報、通信パラメーターが変更されても、サブスクリプション画面から取得したノードだからといって自動更新されるわけではありません。自動更新が必要な場合は、リモートサブスクリプションを登録し、クライアントの更新機能を使ってください。

変換の前後で確認するフィールド

• プロトコルと認証：ノードの種類、サーバーのポート、パスワードまたはUUIDが欠落していないか確認します。ノード名が同じというだけで、変換が成功したと判断しないでください。
• TLSパラメーター：SNI、ALPN、証明書の検証設定を確認します。変換後に「接続できるようにする」ために、証明書の検証を安易に無効にしないでください。
• 通信パラメーター：WebSocketのパスやリクエストヘッダー、gRPCのサービス名は、いずれもハンドシェイクに影響することがあります。1つでも抜けると接続に失敗する場合があります。
• 設定の構造：変換ツールが生成したポリシーグループとルールが、正しく相互参照されている必要があります。ルールが存在しないグループ名を参照していると、ノードが有効でも設定全体を読み込めないことがあります。

インポートに失敗したら、応答内容から原因を調べる

まず「リクエスト自体が失敗した」のか「リクエストは成功したが内容が違う」のかを切り分けます。前者はネットワーク、URL、証明書を確認し、後者は形式とコアの互換性を調べます。ダウンロードに失敗したときにYAMLのインデントを何度も変えたり、解析に失敗したときにノードだけを切り替えたりしないでください。

ブラウザーで開けても、クライアントがダウンロードできるとは限らない

ブラウザーにはログインCookieが保存されていても、サブスクリプションのダウンローダーにはない場合があります。また、サーバーがUser-Agentに応じて異なる内容を返すこともあります。クライアントが実際に受け取った応答を基準にしてください。ログに証明書の期限切れや証明書チェーンのエラーが出た場合は、まず端末の日時、システム証明書、サーバー証明書の状態を確認します。証明書検証を無効にする方法を、通常の解決策として使わないでください。

リクエストがタイムアウトする場合は、サブスクリプションのドメイン名を解決できるか、クライアントがサブスクリプションを更新する際に直接接続するのか、既存のプロキシを使うのかを確認します。ダウンロードにプロキシが必要な場合は、使える旧設定を残したまま、クライアントにプロキシ経由のダウンロード機能があれば利用してください。使える設定がない状態で、「新しいサブスクリプションをダウンロードして初めて使える」接続先を選ぶと、循環依存になります。

インポート後に確認する4つのポイント

1. 現在の設定を確認する。選択中の項目、最終更新時刻、読み込みログを確認し、「新しいサブスクリプションはダウンロード済みだが、古い設定が動作中」という状態を避けます。更新エラーが出た場合は古いコピーを残し、新しい設定が有効だと確認してから置き換えてください。
2. ポリシーグループの参照を確認する。「プロキシ」画面で、グループ内に想定したノードがあるか確認します。ルールモードでは、接続に適用されたルールと接続先も確認してください。グローバルモードで接続できても、ルールによる振り分けが正しいとは限りません。
3. 通信の入口を確認する。システムプロキシを使うのは、システムプロキシ設定に従うアプリが中心です。他のプログラムは使用しない場合があります。TUNで処理される範囲も、ルーティングや除外設定によって異なります。サブスクリプションを追加しただけで、すべてのアプリが自動的にプロキシを使うわけではありません。
4. 更新設定を確認する。完全なリモート設定の更新は通常クライアントが管理します。一方、proxy-providersのintervalは秒単位で、たとえば3600は1時間を表します。この2つは別の設定です。更新間隔はサービス提供元の指定も確認してください。

最後に、確認の順序を覚えておきましょう。まず応答形式を確認し、設定をインポートして有効化します。次にポリシーグループを確認し、最後にシステムプロキシまたはTUNを確認します。各段階を分けて調べれば、問題が起きたときにURL、設定、通信の入口のどこを確認すればよいか分かります。毎回クライアントの再インストールから始める必要はありません。