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

URLは取得先、YAMLとBase64はコンテンツの形式

Clashのサブスクリプションをインポートできないときは、まず「URLにアクセスできるか」と「取得した内容を解析できるか」を切り分けましょう。URLはリモートリソースのアドレス、YAMLは設定の記述形式、Base64はエンコード方式です。それぞれ異なるレイヤーに属するため、互いに排他的な3種類のサブスクリプションとして単純に分類することはできません。HTTPSのサブスクリプションURLからは、完全なYAMLやBase64でエンコードされたノード一覧が返ることもあれば、ログインページが返ることもあります。

mihomoカーネルを使うクライアントでは、サービス提供元がClash Metaまたはmihomo向けと明記したサブスクリプションを優先してください。その名称は対応対象の目安にすぎず、実際に使えるかどうかはレスポンスのフィールドとローカルカーネルの対応状況によります。クライアントにURLを保存できても、レスポンスの内容を解析できるとは限りません。

受け取る内容	一般的な内容	インポート先と制限
サブスクリプションURL	プロトコル、サーバーアドレス、パス、認証トークン	リモート設定の追加画面に貼り付け、クライアントから実際のコンテンツを取得
完全なYAML設定	ノードまたはノードプロバイダー、プロキシグループ、ルール、必要に応じてDNS設定	設定ファイルとして読み込めますが、フィールドやポリシーの参照関係を確認する必要があります
ノードプロバイダー用YAML	多くの場合、トップレベルに`proxies:`を置いたノード一覧です	通常は`proxy-providers`から参照します。完全なメイン設定とは異なります
Base64形式のノード一覧	エンコードされた複数行のノードURI（例：`ss://`、`vmess://`）	クライアントがその形式の解析に対応している必要があります。非対応の場合は、対象カーネルが読み込める設定形式に変換します

インポート前にURLと対応カーネルを確認

クライアントのカーネルを確認します。「バージョン情報」または「設定」にあるカーネル情報で、mihomoを使用しているか確認してください。GUIクライアントとカーネルのバージョンは別なので、互換性の問題を報告するときは両方を記録しましょう。
サービス管理画面から専用URLをコピーします。Clash、Clash Meta、mihomo向けと明記されたURLを選び、プランページやログインページ、ブラウザーのアドレスバーに表示されたURLは使わないでください。
クエリパラメーターを残します。?以降のトークンや形式指定のパラメーターは、認証やコンテンツの選択に使われる場合があります。ドメインとパスだけに切り詰めないでください。
コピー時に付いた余分な文字を取り除きます。先頭と末尾の空白、改行、日本語の引用符を削除してください。URL内のパーセントエンコード、大文字・小文字、パラメーターの順序はむやみに変更しないでください。

サブスクリプションURLには通常、.yamlの拡張子がありません。サーバーはパス、クエリパラメーター、リクエストヘッダーに応じて返す形式を決めるため、ファイル名だけでは対応状況を判断できません。ブラウザーで管理画面を開けても、クライアントがサブスクリプションAPIにアクセスするときに同じログイン状態が使えるとは限りません。

URLが漏えいした場合は、サービス管理画面でサブスクリプショントークンを再発行し、クライアントの古いURLを新しいものに差し替えてください。チャット履歴やローカル設定を削除するだけでは、すでにコピーされた認証情報を無効化できません。

クライアントにURLを貼り付けて設定を有効化

クライアントによってボタン名は異なりますが、手順は「リモート設定を追加」「コンテンツを取得」「設定を選択」「ポリシーを選択」の4段階です。ここでは一般的な「設定」画面から操作します。画面に「サブスクリプション」や「Profiles」と表示されている場合は、ノードの貼り付け欄ではなく、対応するリモート設定の一覧を開いてください。

初回インポートの手順

「設定」を開き、サブスクリプションURLの入力欄にURL全体を貼り付けます。入力欄がない場合は「新規作成」を選び、種類を「リモート」に設定してください。
「日常用サブスクリプション」など、見分けやすい名前を付けて「インポート」または「保存」をクリックします。ダウンロードが完了するまで待ち、続けて何度も実行しないでください。
設定カードに更新日時が表示されていることを確認します。カードをクリックするか「この設定を使用」を選んで、現在の設定として有効にしてください。一覧にダウンロードされただけでは、自動で有効にならない場合があります。
「プロキシ」画面を開き、プロキシグループとノード一覧が表示されているか確認します。使うノードを選び、まず遅延テストを実行してから実際にアクセスしてください。
必要に応じてシステムプロキシを有効にします。システムプロキシに従わない通信も制御したい場合に限り、TUNモードと必要な権限を別途設定してください。

「インポート成功」「設定が有効」「通信がプロキシを経由」は、それぞれ別に確認する項目です。インポート成功は、ファイルを取得して所定の処理ができたことを示すだけで、ノードへの接続を保証するものではありません。システムプロキシやTUNモードは通信を取り込み、ルールとプロキシグループはその後の振り分けを担います。TUNを有効にしても、サブスクリプション形式の誤りは解決しません。

インポート後に確認するフィールド

proxiesまたはproxy-providers：ノードの参照先があり、名前が正しく表示されているか。
proxy-groups：ルールから参照されるポリシーグループが存在し、グループ内に選択肢があるか。
rules：想定した振り分けルールが含まれ、最後に残りの通信を処理するポリシーがあるか。
ローカルの待ち受けポート：クライアントに現在表示されている値を使います。他の手順書にある7890をそのまま設定しないでください。

完全なYAML設定とノード一覧を見分ける

YAMLは構造を記述する形式であり、内容が完全であることを保証しません。proxies:だけを含むファイルは、メイン設定から参照するノード用データの場合もあれば、クライアント側でプロキシグループやルールを補う必要がある場合もあります。必ずしも構文エラーではありませんが、メイン設定としてそのまま使うと、必要なプロキシの選択肢や振り分け動作が不足することがあります。

以下は、設定の階層を示す最小構成の例です。DIRECTポリシーのみでリモートノードは含まれていないため、フィールドの確認用として参照してください。実際に使えるプロキシサブスクリプションではありません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: 出口選択
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,出口選択

mixed-port: 7890はHTTPとSOCKSでローカルの接続口を共用し、mode: ruleはルールに従って通信を振り分ける設定です。最後のルールは残りの接続を「出口選択」に渡します。ここではグループ名とルール内の名前を一致させる必要があります。実際のクライアントでは実行時の設定がポートやモードを上書きする場合もあるため、最終的に適用された設定も確認してください。

リモートリソースをproxy-providersで使う場合、メイン設定にプロバイダーを定義し、プロキシグループからuseで参照する必要があります。プロバイダーの更新とProfile全体の更新は、異なる階層の操作です。完全なメイン設定のURLをノードプロバイダー欄に入力しないでください。また、任意のBase64一覧を現在のカーネルがそのままプロバイダーとして読み込めるとは限りません。

Base64をデコードしても完全な設定にはならない

一般的なBase64形式のサブスクリプションをデコードすると、複数行のノードURIが得られます。各行にはノードのプロトコル、サーバー、ポート、認証パラメーターが記述されていますが、通常はrules、DNS、プロキシグループは含まれません。デコードでテキストを復元できても、Clashに必要な設定構造が自動生成されるわけではありません。

もうひとつ混同しやすいのは、vmess://ノードURI自体にBase64エンコードされた内容が含まれる場合があることです。これは「サブスクリプション全体がBase64でエンコードされている」状態とは別の階層です。テキスト全体を何度もデコードしても、サブスクリプション形式に沿った解析の代わりにはなりません。サービス提供元からmihomo専用URLを取得し直すのが確実です。

自動更新を設定し、独自ルールを維持する

初回インポート後に動作を確認してから、自動更新を有効にします。設定カードの「編集」や「設定」から、「自動更新」「更新間隔」などの項目を探してください。単位が分の場合は360で6時間ごとの更新です。秒と明記されている場合、同じ間隔には21600を指定します。単位を混同しないでください。

まず「更新」を手動で実行し、サブスクリプションURLが有効で、更新日時が変わることを確認します。
6時間ごとなど、適切な間隔を設定します。サービス提供元に更新頻度の制限がある場合は、その指示に従ってください。
「起動時に更新」や失敗時の再試行に対応しているか確認します。クライアントを終了している間は、通常、内部の定期処理は実行されません。スリープ中も更新が遅れることがあります。
更新後、選択中のノード、プロキシグループ、ルールを確認します。ノード名が変わったり削除されたりすると、以前の選択を維持できない場合があります。

リモートサブスクリプションから取得したYAMLのルールを、その場で長期間編集しないでください。次回の更新で編集内容が上書きされる可能性があります。クライアントにオーバーライド、マージ、スクリプト機能がある場合は、独自設定を適切な場所に追加し、更新後も有効な設定に反映されることを確認してください。マージの順序はクライアントごとに異なります。エディターにルールが表示されているだけで、適用済みとは判断できません。

サブスクリプションをインポートできない場合のエラー別対処法

メッセージ・症状	まず確認する項目	対処手順
HTTP 401または403	トークンの失効、アクセス権限、サービス側の制限	管理画面からURLをコピーし直します。アカウントの状態を確認し、必要に応じてサービス提供元に拒否の理由を問い合わせてください。
HTTP 429	更新リクエストが多すぎる	連続した再試行をやめ、サービス提供元の制限に従って待ってから、自動更新の間隔を長くします。
HTTP 200だが解析に失敗する	レスポンスがHTMLのログイン画面、JSON形式のエラー、またはノード一覧の可能性があります	ローカルでレスポンスの冒頭を確認し、ステータスコードだけでなく、想定した形式の内容を取得できているか確かめます。
YAMLの行番号エラー	インデント、タブ、コロン、または途中で切れた内容	エラー行とその直前の行を確認します。インデントにはスペースを使い、元のファイルを再ダウンロードして比較してください。
未対応のプロキシタイプまたはフィールド	設定の対象とローカルカーネルが一致していない	カーネルのバージョンを確認し、対応するURLに切り替えるか、その機能に対応したクライアントとカーネルへアップグレードします。
ダウンロードのタイムアウトまたはTLSエラー	DNS、ネットワーク経路、システム時刻、証明書の信頼設定	まずシステム時刻を合わせ、接続ログとネットワークを確認します。証明書検証を無効にしたまま使い続けて回避しないでください。

形式が対応していない場合の対処順

まずサービスページに戻り、適切な形式のURLを探します。次に、クライアントにノード一覧のインポート機能が明記されているか確認し、変換は最後の手段にしてください。変換ツールが処理できるのは、実装で対応しているプロトコルとフィールドに限られます。元データにない通信パラメーター、TLS設定、ルールが自動で補われることはありません。

サービス提供元の変換機能か、ローカルで実行する信頼できるツールを優先してください。トークン付きURLを公開変換サービスに送ることは、そのサービスにサブスクリプションの閲覧権限を渡すのと同じです。変換後もプロキシタイプ、通信設定、プロキシグループ、ルールを確認してください。ファイルを保存できただけでは、互換性があるとは判断できません。

インポート後に確認する3項目

更新経路を確認します。手動更新を一度実行して、成功した時刻を記録します。失敗した場合は古い設定を残し、まずサブスクリプション取得時のエラーを解決してください。使えている設定を、何度も削除して作り直す必要はありません。
ポリシーの経路を確認します。プロキシグループとノードを明示的に選び、対象のWebサイトを開いて、接続ログで一致したルール、ポリシー、接続結果を確認します。遅延テストに数値が表示されても、すべてのサイトにアクセスできるとは限りません。
通信の取り込み口を確認します。対象アプリがシステムプロキシに従うか確認し、必要な場合にTUNを設定します。出口情報はログとあわせて判断してください。直結ルールに一致した1件のリクエストだけで、設定全体が機能していないとは判断できません。

この3項目を確認してから、定期更新や独自ルールを設定しましょう。サブスクリプションの取得、設定の解析、ノードへの接続、システム通信の取り込みを分けて確認すれば、「インポートできたのにインターネットにつながらない」といった問題の原因を絞り込みやすくなります。通信の取り込み方法やポートについては使い方ガイド、ルールの変更についてはカスタムルールの説明を参照してください。