Clash サブスクリプションURL導入ガイド:3つの導入方法と対応フォーマット解説

サブスクリプションURLとは、リモートの設定ファイルを指すHTTP/HTTPSアドレスのことです。クライアントが定期的にこのアドレスへリクエストを送ると、サーバー側からYAMLまたはBase64エンコードされたノードとルールのセットが返されます。このURLはプロキシサービス提供者のユーザーセンターで生成されることが多く、形式はhttps://example.com/api/v1/sub?token=xxxxのようになっています。クエリパラメータに識別トークンが含まれているため他人への転送は避けるべきで、URLを持っていることはアカウントのノード利用権限を持っていることと同義です。

URLを取得した後、ブラウザで直接開く必要はありません——ブラウザでアクセスすると文字化けやファイルダウンロードが発生するだけですが、これは正常な挙動です。レスポンス内容はクライアントプログラムが解析するためのものであり、人間が読むためのWebページではないからです。正しい使い方は、URLをそのままClash系クライアント(Clash Verge、Clash for Windows系の後継、Clash Meta(mihomo)コアを使うフロントエンドなど)に渡し、リクエスト・解析・設定の書き込みまでの全工程をクライアントに任せることです。

URL導入は最も一般的な方法で、以降の更新はクライアントの自動更新に任せられ、手動でファイルを差し替える必要がない点が利点です。手順は以下の通りです。

1. クライアントの「サブスクリプション」または「Profiles」管理画面を開く。
2. 「新規作成」「インポート」といったボタンをクリックし、入力欄にサブスクリプションURLを貼り付ける。
3. 識別しやすいように、サービス名とプラン名を組み合わせた任意のメモ名を入力する(省略可)。
4. 確定するとクライアントが即座にリクエストを送り、リモート設定を取得してローカルキャッシュを生成する。
5. サブスクリプション一覧で該当項目を選択し「有効化」または「選択」をクリックすれば、ルールとノードが反映される。

クリップボード導入は、ブラウザ拡張機能やチャットツール、QRコードの読み取り結果などから設定テキストやURLをコピーしたものの、クライアント画面への切り替えが面倒な場面に向いています。多くのデスクトップクライアントはサブスクリプション画面に「クリップボードから導入」ボタンを用意しており、動作の流れは次の通りです。

1. まずサブスクリプションURLまたは完全なYAML設定テキストをシステムのクリップボードにコピーする。
2. クライアントに戻り「クリップボードから導入」をクリックすると、プログラムがクリップボードの内容がURLか設定本文かを自動判別する。
3. URLと判定された場合はURL導入と同じ扱いになる。設定本文と判定された場合はそのままローカルサブスクリプションとして保存され、以後リモート更新はできなくなる。

モバイル端末のクライアント(Androidの Clash Meta 系アプリなど)にも同様の入口が用意されており、特に他のアプリの「共有」機能から直接インポート画面に遷移できるため、手入力によるミスを減らせます。

ローカルファイル導入は、オフライン環境や、サービス提供者がオンラインURLではなくダウンロード形式のファイルのみを提供している場合に使用します。対応する拡張子は通常.yaml、.ymlで、古い形式では.txtやBase64テキストとして配布されているケースもあります。手順は以下の通りです。

1. 設定ファイルをダウンロードしローカルディスクに保存し、保存先のパスを覚えておく。
2. クライアントのサブスクリプション画面で「ローカルファイルを導入」または「設定を開く」を選択する。
3. システムのファイル選択画面から該当ファイルを指定して確定する。
4. クライアントがファイル内容を読み込み、YAML構造に従ってノード、プロキシグループ、ルールの各フィールドを解析する。

URL導入

日常利用の第一候補。自動更新に対応するが、サブスクリプションドメインへの通信が必要

クリップボード導入

他アプリとの連携がしやすいが、判定結果はクリップボード内容の種類に依存する

ローカルファイル導入

オフラインでも利用可能だが更新は手動での再インポートが必要。緊急時のバックアップ設定に向く

URL導入したサブスクリプションには、クライアント上に「更新間隔」という項目があり、単位は時間で一般的な初期値は24時間です。間隔を短く設定しすぎるとサブスクリプションサーバーへのリクエスト頻度が上がり、サービス提供者によっては高頻度アクセスに対して速度制限やブロックを行う場合があるため、初期値のままか6時間以上を保つことを推奨します。設定方法は多くの場合、サブスクリプション項目の「編集」ダイアログ内にあるintervalまたは「自動更新周期」の入力欄に数値を入力して保存するだけで、クライアントの再起動は不要です。

次の自動更新まで待ちたくない場合、ほとんどのクライアントはサブスクリプション項目の横に丸い矢印アイコンの「今すぐ更新」ボタンを用意しています。クリックするとリモートへの再リクエストが発生し、数秒程度でノードリストが更新されます。更新に失敗する場合、よくある原因はURLの期限切れ、サブスクリプションドメインへの通信不可、あるいはシステムプロキシのオン/オフ状態とサブスクリプションドメインのポリシーの衝突などです。まずシステムプロキシを一時的に無効にしてから再度更新を試してください。

多くのサブスクリプションサーバーはHTTPレスポンスヘッダーにSubscription-Userinfoというフィールドを付加しており、内容はupload=xxx; download=xxx; total=xxx; expire=xxxのような形式です。クライアントはこのフィールドを解析し、サブスクリプション項目上に使用済み通信量・合計通信量・有効期限を追加設定なしで表示します。表示位置は通常サブスクリプション一覧の該当項目の右側または詳細展開部分で、プログレスバーや「使用量/合計」というテキストで示されます。

注意すべき点として、このデータはサブスクリプションサーバーがそのレスポンスを返した時点のスナップショットであり、リアルタイムの値ではありません。他の端末で大量に通信量を消費した直後であれば、ローカル表示の数値は次回のサブスクリプション更新まで同期されません。あるサブスクリプションで通信量情報が一切表示されない場合、多くはサービス提供者側がレスポンスヘッダーにこのフィールドを返していないためで、この場合はサービス提供者自身のユーザーセンターで実際の使用量を確認する必要があり、クライアント画面上でこのデータを補うことはできません。

• 残りの通信量が少なくなってきた場合は、ノードが使用中に突然利用できなくなる前に、早めに切り替えや更新を計画することを推奨します。
• 有効期限のフィールドと通信量のフィールドは互いに独立しているため、通信量が十分残っていても期限が切れればサブスクリプションは無効になります。
• ローカルファイル導入で作成した設定はHTTPレスポンスヘッダーを経由しないため、通常この種の情報は付随しません。

Clash系クライアントが受け付けるサブスクリプションの内容フォーマットは主に2種類です。

• ネイティブYAML形式:proxies、proxy-groups、rulesなどのフィールドで構成されます。Clash Meta(mihomoコア)はこれをベースに、Hysteria2、TUIC、WireGuardなど、より多くのプロトコルフィールドやルールタイプを拡張しています。古いバージョンのコアが拡張フィールドを認識できない場合はスキップまたはエラーとなり、導入後にノード数が明らかに少ないと感じたら、コアのバージョンが古いことが多いです。
• Base64エンコードのノードリスト:初期のV2Ray/Shadowsocksの共有URLをまとめたものによく見られる形式です。一部のクライアントは自動的に識別してClashのルールセットへ変換できますが、変換サービスを使って標準的なYAMLに変換した上で導入する必要がある場合もあり、このタイプのURLをそのままClashのサブスクリプションとして扱うと解析に失敗することがあります。

proxies:
  - name: "サンプルノード-HK-01"
    type: trojan
    server: example.node.tld
    port: 443
    password: "サンプルパスワード"
    sni: example.node.tld
    udp: true

上記は最小構成のTrojanノードフィールドの例です。実際のサブスクリプションファイルではこうした項目が複数繰り返され、proxy-groupsでノードをグループ化し、rulesによってどのドメインやIP帯がどのグループを通るかが決まります。導入前にこれらのフィールドを手動で編集する必要はなく、クライアントが自動解析しますが、独自の設定を組んだり異常なノードをデバッグする場合には1行ずつ確認が必要になります。