ClashサブスクリプションURLのインポート方法：URLからの導入手順と主な形式の違い

Clashの「サブスクリプションをインポート」は、URLを保存するだけの操作ではありません。クライアントがURLへアクセスし、リモートから返された設定内容をダウンロードして、現在のコアで解析できる形式かを判定し、結果をローカル設定として保存します。インポート後は通常、その設定を選択し、プロキシノードを指定して、システムプロキシまたはTUNモードを有効にする必要があります。そこで初めて通信がClashを経由します。

インポートでつまずく原因の多くは、コピーしたものがサブスクリプションURLではない、サーバーの返却内容がクライアント未対応の形式、または設定のダウンロードは完了したものの現在の設定として選択されていない、の3点です。まず標準的なURLインポートを行い、その後YAML、Base64ノードリスト、単一の共有リンクを見分けていきます。

インポート前にサブスクリプションURLであることを確認する

リモート更新に使えるサブスクリプションは通常、https://で始まる1行のURLです。例：

https://sub.example.com/api/client/subscribe?token=abc123&target=clash

WebページのURL、購入ページ、管理画面のログインURLとサブスクリプションURLは別物です。ブラウザーで開いたときにアカウント管理画面、プラン情報、ログインフォームが表示されるなら、コピーしたのは通常のWebページである可能性が高いでしょう。正しい入口には「Clashサブスクリプション」「Clash Meta」「サブスクリプションURLをコピー」「汎用サブスクリプション」などと表示されています。サービス提供元が複数のボタンを用意している場合は、Clash、Mihomo、Clash Metaと明記された形式を優先してください。

コピー後に確認する4項目

プロトコルが完全：URLには https:// または http:// が含まれている必要があります。ドメインとパスだけでは使えません。
余計な文字がない：URLの前後に「サブスクリプションURL：」、引用符、空白、改行が付いていないことを確認します。スマートフォンで長押しコピーすると、説明文まで選択しやすいため注意してください。
クエリパラメータが残っている：?以降のtokenやtargetなどのパラメータが、認証や返却形式を決める場合があります。手動で短くすると401、403、形式エラーの原因になります。
URLの有効期限内である：サブスクリプションの再発行、アカウント移行、プラン変更後は、古いURLがすぐ無効になることがあります。その場合はサービスページで新しいURLをコピーしてください。

共有リンクは別の種類のデータです。ss://、trojan://、vmess://、vless://、hysteria2://で始まる文字列は、通常1つのノードだけを表し、定期更新できるHTTPサブスクリプションURLではありません。一部のクライアントでは単一ノードを直接インポートできますが、「クリップボードからインポート」または「ノードを追加」を使い、サブスクリプションURL欄には入力しないでください。

ClashサブスクリプションURLの標準インポート手順

クライアントによってメニュー名は多少異なりますが、操作の順序は共通しています。設定管理画面を開き、URLを貼り付け、設定をダウンロードし、有効化してからノードと通信状態を確認します。以下はMihomoコアを使う一般的なデスクトップ版およびAndroid版クライアントに対応しています。

デスクトップ版：Clash Verge Rev系クライアント

クライアントを起動し、左側の「サブスクリプション」ページを開きます。
ページ上部のサブスクリプションURL入力欄に完全なURLを貼り付けます。
「インポート」をクリックするかEnterキーを押し、リモート設定のダウンロードが完了するまで待ちます。通常のネットワーク環境なら1～10秒ほどで完了します。
インポート後、設定カードにノード数、更新日時、更新ボタンが表示されているか確認します。
設定カードをクリックして、現在有効なサブスクリプションにします。バージョンによっては選択状態や「現在の設定」と表示されます。
「プロキシ」ページを開き、プロキシグループで遅延の適切なノードを選択します。先に遅延テストを実行しても構いません。
「設定」→「システムプロキシ」を開き、システムプロキシを有効にします。システムプロキシに従わないアプリも制御する場合は、その後TUNモードを設定してください。

Android：Clash Meta for Android系クライアント

「設定」ページを開き、右上のプラスボタンをタップします。
「URLからインポート」または「新しい設定」→「URL」を選択します。
設定名に「日常用サブスクリプション」などを入力し、URL欄に完全なリンクを貼り付けます。
自動更新間隔は、まず 1440 分に設定すると、1日1回の更新になります。サービス提供元に指定がある場合は、その案内に従って変更してください。
保存してダウンロードを待ち、設定一覧に戻って作成した設定をタップします。
ホーム画面に戻ってサービスを起動し、プロキシグループでノードを選択します。Androidでは初回起動時にVPN接続の許可が表示されるため、システムで承認してください。

インポート後の簡易チェック

インポート完了後は、次の結果から各手順が有効になっているか確認できます。

設定ページにサブスクリプション名と最終更新日時が表示され、解析エラーが出ていない。
プロキシページに PROXY、ノード選択、自動選択などのプロキシグループと、その中のノードが表示されている。
遅延テストで85 ms、210 msなど具体的な数値が返り、常にタイムアウトになっていない。
ログページに接続記録があり、適用されたルール、宛先アドレス、最終的なポリシーが表示されている。
更新ボタンで、URLを再度貼り付けなくても設定を取得できる。

Clash標準YAMLとは

Clash標準設定は、構造化されたYAMLファイルです。完全な設定には通常、待受ポート、動作モード、DNS、ノード、プロキシグループ、ルールなどのフィールドが含まれます。Mihomoはこの基本構造を引き継ぎ、さらに多くのプロトコルと設定機能を追加しています。Clash対応のリモートサブスクリプションが完全なYAMLを返す場合、クライアントですぐに解析できることが一般的です。

mixed-port: 7890
mode: rule
allow-lan: false

proxies:
  - name: Example-Trojan
    type: trojan
    server: edge.example.com
    port: 443
    password: demo-password
    sni: edge.example.com

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - Example-Trojan
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

この例には、完全な設定の主な構成が含まれています。mixed-port: 7890はHTTPとSOCKSの通信で共通利用するローカル混合ポート、mode: ruleはルールによる振り分け、proxiesはノードの保存先、proxy-groupsはユーザーが選べるポリシーの構成、rulesは接続を直接接続とプロキシのどちらへ送るかを決めます。

完全な設定YAMLとプロキシプロバイダーYAMLの違い

拡張子が .yaml だからといって、すべてのファイルをメイン設定として直接使えるわけではありません。プロキシプロバイダー用ファイルには payload だけが含まれる場合があり、通常はメイン設定の proxy-providers から参照します。

payload:
  - name: Example-SS
    type: ss
    server: node.example.com
    port: 8388
    cipher: aes-128-gcm
    password: demo-password

このproviderファイルを通常の設定インポート欄に直接入れると、proxies、proxy-groups、rulesが不足していると表示されることがあります。インポートできても、選択可能なプロキシグループがない場合があります。これは完全なメイン設定ではなく、proxy-providers、プロキシグループ、ルールを含むメインYAMLから呼び出して使うファイルです。

コンテンツの種類	よくある先頭部分またはフィールド	Clash設定として直接使えるか
完全なClash YAML	`mixed-port`、`proxies`、`proxy-groups`	通常は可能
プロキシプロバイダーYAML	`payload:`	通常はメイン設定からの参照が必要
ルールプロバイダーYAML	`payload:`の後にドメインまたはルールが続く	メイン設定として単独では使えない
Webページのエラー内容	`<html>`、ログイン案内、エラーページ	不可

Base64ノードリストを認識できない理由

汎用サブスクリプションでは、複数のノード共有リンクを行ごとに並べ、全体をBase64でエンコードすることがあります。デコード後の内容は次のようになります。

ss://[email protected]:8388#Example-SS
trojan://[email protected]:443?security=tls#Example-Trojan
vmess://encoded-json-data

この内容はClash YAMLではなく、proxy-groupsとrulesもありません。サブスクリプション変換に対応したクライアントなら、インポート時にノードリストを内部設定へ自動変換できる場合があります。一方、Clash YAMLのみ対応するクライアントでは、YAML解析エラーや設定形式エラーが表示されたり、インポート後にプロキシグループが表示されなかったりします。

まずサービス提供元のClash形式を選ぶ

サブスクリプションページに「汎用サブスクリプション」「Clash」「Clash Meta」「Surge」などの選択肢がある場合は、ClashまたはClash Metaのリンクを優先してコピーしてください。サブスクリプション側で目的の形式が直接生成されるため、ノードのプロトコル、プロキシグループ、ルールも現在のコアに合わせやすくなります。

汎用Base64リンクしかない場合は、クライアントがその形式に明確に対応しているか確認してください。URLの拡張子だけで判断してはいけません。多くのサブスクリプションURLには .yaml がなく、クエリパラメータ、リクエストヘッダー、サーバー設定によって返却内容が決まります。ブラウザーでダウンロードしたファイル名が subscribe でも、実際には有効なYAMLの場合があります。

単一ノードの共有リンクはBase64サブスクリプションではない

vmess://以降の本体は通常それ自体がBase64でエンコードされていますが、表しているのは1つのVMessノードです。一方、Base64サブスクリプション全体は、エンコード前に複数行の共有リンクを含みます。両者ではインポート入口が異なる場合があります。単一リンクなら、まずクライアントの「クリップボードからインポート」を探してください。長期的に自動更新したい場合は、サービス提供元からHTTPSサブスクリプションURLを取得します。

URLインポートに失敗したときのエラー別チェック

「インポートに失敗した」と表示されても、ネットワーク接続の失敗と形式解析の失敗では対処がまったく異なります。まずクライアントに表示されたステータスコード、エラーメッセージ、発生時刻を記録し、次の表と照らし合わせてください。

症状または状態	主な原因	優先して行う対処
タイムアウト、接続失敗	サブスクリプションのドメインに到達できない、DNS異常、現在のネットワークによる制限	ネットワークを切り替え、システム時刻とDNSを確認して再試行する
HTTP 401または403	トークンの期限切れ、アカウント状態の異常、リクエスト制限	サービスページでサブスクリプションを再コピーし、アカウント状態を確認する
HTTP 404	パスが無効、古いサブスクリプションがリセットされた	URLを手動で編集せず、新しい完全なURLを取得する
YAML解析エラー	Base64、HTMLページ、またはインデントが壊れたYAMLが返されている	Clash形式を選択し、レスポンスのコンテンツタイプを確認する
インポート成功だがノードが空	ルールセット、providerファイル、または空のサブスクリプションをインポートしている	`proxies`とプロキシグループが存在するか確認する
ノードはあるが接続できない	ノードが利用できない、システム時刻がずれている、ポリシーが選択されていない	時刻を合わせ、別のノードをテストしてプロキシグループを確認する

ブラウザーで基本状態を確認する

サブスクリプションURLをブラウザーのアドレスバーに貼り付けると、URLへ到達できるか確認できます。ブラウザーがテキストファイルを直接ダウンロードするなら、少なくともサーバーから応答は返っています。ログインページ、プランページ、認証ページへ移動する場合、クライアントが受け取っているのも設定ではなくHTMLかもしれません。ブラウザーで開けても、形式が正しいとは限りません。サーバーがクライアントのリクエストヘッダーによって返却内容を変える場合があるためです。

コマンドラインでHTTPステータスを確認する

ターミナルに慣れている場合は、レスポンスヘッダーだけを確認できます。コマンドを実行する前に、共有画面、ターミナル履歴の同期、公開ログなどへ実際のトークンが表示されないよう注意してください。

curl -I -L --max-time 15 "https://sub.example.com/api/client/subscribe?token=abc123&target=clash"

-Iはレスポンスヘッダーだけを取得し、-Lはリダイレクトに追従し、--max-time 15は最大待機時間を15秒に制限します。結果の 200 はリクエストが正常に返ったことを示します。301または302の後にログインページへ移動する場合は、認証またはURLに問題があることが多いでしょう。404はパスが存在しないことを示します。一部のサブスクリプションサービスはHEADリクエストに応答しないため、このコマンドが失敗しても、クライアントの通常のGETリクエストは使える場合があります。

YAMLのインデントとフィールドを確認する

設定を手動で保存または編集するとき、YAMLはインデントに非常に敏感です。リスト項目のハイフン、コロンの後の空白、同じ階層のインデントを統一してください。Tab文字も解析エラーの原因になるため、通常は半角スペース2つでインデントします。サービス側で生成されたリモートサブスクリプションは、ノード名を変更するためにダウンロードファイルを大きく置換することはおすすめしません。次回のリモート更新でローカルの変更が上書きされるためです。

自動更新間隔とローカル設定の選び方

リモートサブスクリプションはノードの変更を同期したい場合に適しており、ローカルYAMLはルール、DNS、プロキシグループのテストに向いています。両者を同じ自動更新設定に混在させると、更新後にローカルの変更が消えることがあります。まず、設定を誰が管理するのかを明確にしてください。

更新間隔を短くしすぎない

一般的な自動更新間隔は1440分、つまり24時間です。ノードの変更が多い場合は360分または720分に設定できます。1～5分に設定すると重複リクエストが大量に発生し、サーバー側でアクセス頻度を制限される可能性があります。最新ノードが一時的に必要な場合は、「更新」を1回クリックする方が適切です。

1440分：日常利用に適しており、更新頻度も安定します。
720分：1日2回更新します。ノードの変更が比較的多いサブスクリプションに適しています。
360分：6時間ごとに更新します。サービス提供元がこの頻度を許可しているか確認してください。
手動更新：長期間固定する設定に適しており、必要なときだけ更新します。

サブスクリプション更新にプロキシは必要か

一部のクライアントには「プロキシ経由で更新」や「システムプロキシを使ってサブスクリプションを更新」という項目があります。サブスクリプションのドメインへ現在のネットワークから直接接続できるなら、まずは直接接続のまま更新すると経路がシンプルです。直接接続がタイムアウトし、現在のプロキシノードが利用できる場合に限り、プロキシ経由の更新を試してください。更新に、現在使用中で無効になった同じ設定が必要だと、更新できない循環状態になることがあります。その場合はネットワークを切り替えるか、別の利用可能な設定を先に有効にします。

復元できる設定を1つ残しておく

DNS、TUN、複雑なルールを変更する前に、現在動作している設定をエクスポートするか、基本的なローカル設定を1つ残しておくと安心です。新しいサブスクリプションでフィールドの互換性に問題が起きても、まずネットワークを復元してから確認を続けられます。設定を復元する際は、古い設定のノードがすでに期限切れの可能性に注意してください。バックアップの主な価値は、ポート、ルール、動作パラメータを残せることです。

インポート後に反映されない場合の最終チェックリスト

サブスクリプションに「更新成功」と表示されてもWebページを開けない場合は、次の順番で確認してください。一度に1項目だけ変更すると、問題が設定、ノード、システム側の制御のどこにあるか判断しやすくなります。

設定一覧で、古い設定や空のローカル設定ではなく、先ほどインポートしたサブスクリプションが選択されていることを確認します。
プロキシグループを開き、メインポリシーを DIRECT から、遅延テストが正常なノードへ切り替えます。
動作モードが「ルール」または「グローバル」になっていることを確認します。ルールモードで DIRECT に一致するサイトが直接接続されるのは正常です。
デスクトップ版では「設定」→「システムプロキシ」を開き、Android版ではVPNサービスが動作中であることを確認します。
ローカルポートが競合していないか確認します。一般的な混合ポートは 7890 ですが、現在の設定にある mixed-port を優先してください。
ログに対象への接続が記録されているか確認します。記録がまったくない場合は、アプリの通信がClashに入っていない可能性が高く、記録はあるものの接続がタイムアウトする場合は、ノードまたはネットワークの問題に近いと考えられます。
システムプロキシに従わないアプリだけに影響する場合は、TUNモードを検討してください。TUNをサブスクリプション形式エラーの修復方法として使ってはいけません。

サブスクリプション形式を判断するとき、最も有用な手がかりはファイル名ではなく、実際に返された内容です。完全なClash YAMLにはノード、プロキシグループ、ルールが含まれます。provider YAMLはメイン設定から参照する集合だけを含みます。Base64形式の汎用サブスクリプションは、デコードすると通常複数の共有リンクになります。HTMLが返る場合は、Webページまたはエラーページを取得しています。「URLを取得—レスポンスをダウンロード—形式を判定—設定を有効化—通信を確認」の順に確認すれば、インポートがどの段階で止まっているかをすばやく特定できます。