サブスクリプションURL・ノード一覧・Clash YAMLをまず見分ける
「サブスクリプションURL」はまずURLであり、決まったファイル形式ではありません。クライアントがURLへアクセスして初めて、サーバーから実際の内容が返されます。返却内容は完全なClash YAML、ノードだけを含むYAML、Base64エンコードされた汎用ノード一覧のほか、Webページ、JSON形式のエラー、期限切れの案内の場合もあります。直接インポートできるかどうかは、最終的に返された内容をクライアントが処理できるかで決まります。
ClashおよびClash Meta（現在はmihomoと呼ばれることが一般的）のカーネルでは、設定の入口はYAMLが基本です。完全な設定には通常、ポート、動作モード、ノード、プロキシグループ、ルール、DNSなどの項目が含まれます。一部のGUIクライアントはインポート前に汎用サブスクリプションを判別し、内蔵の変換機能を呼び出します。一方、カーネルが設定ファイルを直接読み込む場合は、解析可能なYAMLが必要です。
よくある3種類の結果における主な違い
| 種類 | 冒頭または構造上の特徴 | 一般的な処理方法 |
|---|---|---|
| Clash YAML | proxies:、proxy-groups:、rules: |
リモート設定としてインポートするか、YAMLファイルとして保存 |
| Base64ノード一覧 | 英字・数字・+・/・=が連続し、本文の改行が少ない |
まずデコードしてプロトコルを確認し、Clash YAMLへ変換 |
| 汎用URI一覧 | ss://、vmess://、trojan://、hysteria2:// |
対応するプロトコルを扱えるクライアントにインポートするか、目的の形式へ変換 |
ClashクライアントにサブスクリプションURLをインポートする
インポート前にシステム時刻が正しいことを確認し、リンクへHTTPSで正常にアクセスできることを確認します。システム時刻が数分ずれるとTLS証明書の検証に失敗する場合があります。また、コピーしたURLに余分な空白、改行、日本語の句読点が含まれているとリクエストに失敗します。URLは https:// から始まり、末尾に句点を付けないでください。
Clash Verge Revのリモート設定画面
Clash Verge Rev 2.3.1の画面を例にすると、「サブスクリプション」→「新規作成」と進み、種類を「Remote」に設定してURL入力欄へアドレスを貼り付け、確定します。インポート完了後、設定カードで有効化します。バージョンによっては新規作成の入口がプラスボタンになっていますが、リモート設定、URL、更新間隔という3項目の意味は同じです。
- 「サブスクリプション」ページを開き、「新規作成」またはプラスボタンを選択します。
- リモート設定の種類を選び、完全なHTTPSアドレスを貼り付けます。
- 名前には「日常用ルール設定」など用途を入力し、トークンを名前に使わないでください。
- 保存後、ダウンロードとYAMLの解析が完了するまで待ち、その設定を現在の設定にします。
- 「プロキシ」ページでプロキシグループの方針を選び、最後に「設定」→「システム設定」でシステムプロキシを有効にします。
Clash for Windowsの旧画面における操作経路
旧環境を引き続き使用している場合、Clash for Windows 0.20.39では「Profiles」→上部のURL入力欄→「Download」と進みます。ダウンロードに成功したら、該当する設定カードをクリックして現在の設定にします。このクライアントはすでに更新が停止しているため、この手順は既存インストールの確認を主な目的とします。新規導入では、現在も保守されているmihomoカーネル採用クライアントを優先してください。
インポート後は「ダウンロード成功」だけで判断しない
- 設定カードに更新時刻が表示されているか確認します。履歴一覧に表示されているだけでは不十分です。
- 「プロキシ」ページに、「ノード選択」「自動選択」「フェイルオーバー」など、想定したプロキシグループが表示されているか確認します。
- 現在のモードを確認します。ルール設定では通常、GlobalモードではなくRuleモードを使用します。
- ローカルのリスニングポートを確認します。一般的な混合ポートは
7890ですが、実際の値は設定内のmixed-portを基準にしてください。 - システムプロキシを有効にしたら、システムのHTTP・HTTPSプロキシが
127.0.0.1とクライアントの実際のポートを指していることを確認します。
返却内容からサブスクリプション形式を判別する
ブラウザでサブスクリプションURLを直接開くと、ファイルがダウンロードされる場合もあれば、長い文字列が表示される場合もあります。最も確実な判断材料は、ファイル拡張子ではなくHTTPステータス、レスポンスヘッダー、レスポンス本文です。サーバーが .txt のパスを使っていても標準YAMLを返すことがあり、逆に config.yaml という名前のURLがログインページを返すこともあります。
curlでステータスとレスポンスヘッダーを確認する
curl -L --compressed -D headers.txt \
-o subscription.txt \
"https://sub.example.net/profile?token=demo-token"-L は301、302、307、308リダイレクトに追従し、--compressed はgzipやBrotliなど、curlが対応する圧縮レスポンスの展開を許可します。-D はレスポンスヘッダーを別ファイルに書き出します。最終ステータスが 200 であることを確認してから、Content-Type を確認します。YAMLのレスポンスには text/yaml、application/yaml、通常の text/plain が使われることがあるため、MIMEタイプだけでは補助的な判断にとどまります。
完全なClash YAMLの構造
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies:
- name: Example-Trojan
type: trojan
server: edge.example.net
port: 443
password: sample-credential
sni: edge.example.net
proxy-groups:
- name: ノード選択
type: select
proxies:
- Example-Trojan
- DIRECT
rules:
- DOMAIN-SUFFIX,example.org,ノード選択
- GEOIP,CN,DIRECT
- MATCH,ノード選択インデントとフィールドが正しければ、この内容はUTF-8の config.yaml として保存できます。YAMLは空白で階層を表すため、インデントにTabを使うことはできません。名前にコロン、シャープ記号、前後の空白が含まれる場合は、引用符で囲むことを推奨します。設定を解析できても、ノードのパラメータが有効とは限りません。プロトコルの種類、ポート、TLS、SNI、認証情報は、引き続きサーバー側と一致させる必要があります。
ノードだけを含むprovider YAML
別によくある返却内容として、トップレベルに proxies: だけがあり、rules: と proxy-groups: がない形式があります。これは通常プロキシプロバイダーファイルで、完全な設定の proxy-providers から参照する用途に適しています。単独でメイン設定として起動できるとは限りません。
proxy-providers:
remote-nodes:
type: http
url: "https://sub.example.net/provider.yaml?token=demo-token"
path: ./providers/remote-nodes.yaml
interval: 21600
health-check:
enable: true
interval: 600
url: https://www.gstatic.com/generate_204
proxy-groups:
- name: 自動選択
type: url-test
use:
- remote-nodes
url: https://www.gstatic.com/generate_204
interval: 300ここでの interval: 21600 は21600秒、つまり6時間ごとにproviderを更新するという意味です。ヘルスチェックは600秒ごと、プロキシグループの速度測定は300秒ごとに実行されます。この3つの間隔はそれぞれ独立しており、速度測定に成功したからといってサブスクリプションが更新済みとは限りません。
Base64と汎用ノードサブスクリプションの処理方法
Base64はエンコード方式であり、プロキシプロトコルではありません。複数行のURIを、転送しやすい1つのテキストにまとめるためによく使われます。典型的な本文は大文字・小文字の英字、数字、プラス、スラッシュ、末尾のイコールで構成されます。URLセーフBase64ではハイフンやアンダースコアが使われることもあります。文字の見た目だけでは形式を完全に特定できないため、デコードして内容を確認する必要があります。
オフラインでデコードしてURIを判別する
macOSまたはLinuxでは、まずレスポンスファイルをコピーしてから次のコマンドを実行します。GNU coreutilsでは通常 base64 -d を使い、macOSの標準ツールでは -D も使用できます。現在の環境でオプションが異なる場合は、先に base64 --help を実行して確認してください。
base64 -d subscription.txt > decoded.txt
head -n 8 decoded.txtデコード結果は通常、1行につき1つのノードURIになります。たとえば ss://、trojan://、vmess:// などです。VMess URIでは、本文がさらにBase64エンコードされたJSONになっている場合もあります。ファイル全体を繰り返しデコードするのではなく、まず第1層の結果に読み取り可能なプロトコルの接頭辞が現れているか確認してください。
Base64サブスクリプションをClashカーネルへ直接渡せないことがある理由
Clashの設定ローダーが読み込むのはYAML構造であり、汎用Base64リストは複数のノードURIにすぎません。GUIクライアントに「汎用サブスクリプションのインポート」や内蔵変換機能があれば、URIを proxies 項目へ自動変換できる場合があります。一方、mihomoバイナリを直接実行し、-f で設定を指定する場合は、先にClashまたはmihomo形式のYAMLを取得してください。
- サービス提供元が「Clash」「Mihomo」「Clash Meta」形式をそれぞれ提供している場合は、該当する入口を優先してください。
- 変換が必要な場合は、サービス提供元の形式変換機能またはローカルの変換ツールを優先してください。
- 変換先はカーネルの対応状況に合わせます。VLESS、Reality、Hysteria 2などの項目を含む場合は、mihomo互換形式を選択してください。
- 変換後はノード数、プロキシグループ、ルール、DNSを確認します。ファイルが生成されたかどうかだけで判断しないでください。
更新間隔・キャッシュ・サブスクリプションの期限切れへの対処
サブスクリプションを毎分更新する必要はありません。リモート設定には通常、完全なルールとノード一覧が含まれるため、頻繁なリクエストはサーバーの負荷を高め、レート制限にかかる可能性もあります。日常利用では6〜24時間ごとに設定し、ノードの変化が多い場合は1時間まで短縮できます。ただし、自動更新間隔を数十秒に設定することは推奨しません。
よく使う間隔の換算
| 更新頻度 | 秒数 | 用途 |
|---|---|---|
| 1時間ごと | 3600 |
ノード変更が多い一時的な設定 |
| 6時間ごと | 21600 |
通常のリモートprovider |
| 12時間ごと | 43200 |
ルールやノードの変更が少ない設定 |
| 24時間ごと | 86400 |
安定した完全構成のサブスクリプション |
手動更新後も古いノードが表示される
- 一覧にある別の同名設定ではなく、現在有効な設定を更新しているか確認します。
- クライアントログでリクエスト時刻、HTTPステータス、解析エラーを確認します。
- サブスクリプションURLに対するブラウザキャッシュの影響を避け、curlで
Cache-Control: no-cacheリクエストヘッダーを追加して比較します。 - サーバー側でCDNが古い内容をキャッシュしていないか確認します。レスポンスヘッダーの
Ageは判断の補助に使えます。 proxy-providersを使用している場合は、メイン設定の更新時刻だけでなくproviderファイルの更新時刻も確認します。- 更新に成功したらプロキシグループを再選択します。削除されたノードが古いセッションで一時的に使われ続ける場合があります。
HTTPステータス別の切り分け方
401または403：トークンが無効、権限不足、アクセス元の制限、または必要なリクエストヘッダーを満たしていません。404：パスが変更されたか、アドレスをコピーする際に一部のパラメータが失われています。429：リクエストが多すぎます。更新間隔を延ばし、制限が解除されるまで待ちます。500、502、503：サーバーまたは上流側で一時的な障害が発生しています。現在の設定を残して、しばらくしてから再試行します。200でも解析に失敗する場合：レスポンスがログインページ、エラーJSON、Base64テキスト、または互換性のないYAMLである可能性があります。
YAML解析エラーとインポート後に接続できない場合
サブスクリプションのインポートエラーは、「ダウンロード段階」「解析段階」「実行段階」に分けて対処します。ダウンロード段階ではHTTPとTLS、解析段階ではYAMLの行番号とフィールド型、実行段階ではノードのハンドシェイク、DNS、ルーティングルール、システムプロキシを確認します。3種類の問題を混同すると、実際の障害箇所を特定できないままサブスクリプションURLを何度も変更することになります。
よくあるYAMLエラー
- インデントエラー：リスト項目前の空白レベルが一致していないか、Tabが混在しています。
- 重複キー：同じ階層に
rules:やdns:が2つあります。後の項目が前の項目を上書きする場合や、厳密な解析でエラーになる場合があります。 - コロンの未引用：ノード名に「地域:回線」のようなコロンが含まれる場合、引用符を付けないとキーと値の構造として解釈される可能性があります。
- フィールド型エラー：
portは数値である必要がありますが、変換できない文字列になっています。真偽値にはtrueまたはfalseを使用します。 - カーネルの非互換：設定にmihomoの拡張フィールドが含まれているのに、クライアントが古いClashカーネルを使用しています。
インポートは正常だがブラウザでWebページを開けない
- 現在のプロキシグループで使用可能なノードが選択されているか確認します。空のグループや期限切れのノードになっていないことも確認してください。
- システムプロキシのリスニングアドレスとポートが一致しているか確認します。
mixed-port: 7890の設定なら、システムプロキシは通常127.0.0.1:7890を指定します。 - Ruleモードで、リクエストがどのルールに一致したか確認します。末尾の
MATCHポリシーは、前のルールに一致しなかった通信に影響します。 - DNS設定を確認します。
fake-ipを有効にしている場合は、対象アプリの通信が実際にカーネルを経由し、名前解決経路と接続経路が分離していないことを確認してください。 - システムプロキシに従わないアプリを制御する必要がある場合だけTUNを有効にします。有効化後に完全に通信できなくなった場合は、TUNスタック、ルート設定の権限、DNSハイジャックの設定を確認します。
サブスクリプションを安全にインポートする設定手順
初回設定では、サービス側が直接提供するClashまたはmihomo YAMLを優先します。インポート後は、直近まで使用できたローカル設定を1つ残しておくと、リモート更新に失敗した際にすぐ戻せます。クライアントが設定の統合に対応している場合は、個人ルール、DNS、スクリプトをローカルの上書きレイヤーに置き、サブスクリプション更新のたびに手動変更が上書きされるのを防ぎます。
- サブスクリプションURLはクライアント設定にのみ使用し、公開同期リポジトリには保存しません。
- 完全な設定とproviderファイルを分けて管理し、それぞれの更新間隔を明確にします。
- ノード名は一意にし、同名でもパラメータが異なるノードがプロキシグループで選ばれないようにします。
- ルールを変更したら設定を再読み込みし、接続ログで適用されたポリシーを確認します。
- カーネルのバージョンを変更した後は、まず設定構文を検証してからシステムプロキシまたはTUNを有効にします。
サブスクリプション形式を判断する鍵は、リンクが何に見えるかではなく、最終的に何を返すかです。YAMLはそのまま設定処理に進められます。Base64は先にデコードして判別し、汎用URI一覧は互換性のあるクライアントまたは信頼できる変換手順で目的のYAMLを生成します。ダウンロード、解析、有効化、通信の取り込みという4段階で確認すれば、インポートに関する問題の大半を正確に切り分けられます。